Recently, Microsoft released Internet Explorer 8, which boasted much better standards compliance than previous iterations of the browser. While it passed the Acid2 test, IE8 failed miserably in the Acid3 test, and many people criticised Microsoft for it. Microsoft Australia's Nick Hodge has stated that Microsoft purposefully decided not to support Acid3, because the test tests against draft standards.

“The concern Microsoft has is that if we burnt [draft standards] into Internet Explorer 8 and passed Acid3 with 120 percent and then deploy it on so many machines, especially in the enterprise, [we have made draft standards de-facto standards] when the W3C will then want to innovate on the [evolving] standards,” Nick Hodge, a Professional Geek for Microsoft Australia said.

How can any professional take him serious when he leveraged a fallacious analogy to justify why they still can't be current with competing browsers on their own platform?

I think it's entirely fair that they do not have to support a moving target. Sure it would be nice but I think this is a reasonable argument as to why they are currently not trying to pass 3

It isn't a reasonable argument. The standards asked for by Acid3 are five years or more old. Current and future further developments of those standards won't break lower levels, so passing Acid3 now won't be a nugatory effort as Microsoft imply.

MS is right in this respect that draft standards should not be widely used, but that doesn't mean that a rendering engine shouldn't implement them.
This helps finding bugs early on and tweaking the rendering engine to support the final standard is easy when almost every foundation is laid. MS once again wants to hold back web innovation by beginning to implement standards years after they are final.

Microsoft has MSDN to tell web developers that a set of implemented features is work in progress. Web devs may use them internally for preparing the next release of their web site, but should also be aware that changes can occur and that those features should not be used until a final standard is agreed upon.

MS is right in this respect that draft standards should not be widely used, but that doesn't mean that a rendering engine shouldn't implement them.

In the general case this is true. For IE, however, implementing something makes it a standard whether we like it or not. In the past MS hasn't worried about this, giving us the nightmare that was IE6.

I think this is a very positive sign that MS is finally treating it's position as market leader responsibly. They are conforming preciesly to the published standards of the W3C and no more. This leaves the W3C free to make ammendments to their draft standards that won't conflict with the most widely deployed implementation.

This is the exact opposite of the old, infamous "embrace, extend, extinguish" policy of the early days of the web.

[q]
I think this is a very positive sign that MS is finally treating it's position as market leader responsibly. They are conforming preciesly to the published standards of the W3C and no more. This leaves the W3C free to make ammendments to their draft standards that won't conflict with the most widely deployed implementation.

This is the exact opposite of the old, infamous "embrace, extend, extinguish" policy of the early days of the web.

I would applaud that attitude if they really followed it. The biggest gripe since the standardisation it was even worse than ignoring png until ie7 was the non implementation of SVG in IE.
As I said Microsoft was able to fork an incompatible clone of it for Silverlight, but yet they are not able to implement the proper W3C standard for the IE! The same goes for a load of other finalized standards tested in ACID3. The funny thing is that history seems to repeat itself with EcmaScript4. Everybody wants to integrate it into the browsers. Microsoft does not!

I think this is a very positive sign that MS is finally treating it's position as market leader responsibly. They are conforming preciesly to the published standards of the W3C and no more. This leaves the W3C free to make ammendments to their draft standards that won't conflict with the most widely deployed implementation.

Except there's plenty of stuff IE 8 doesn't support that's a recommended standard. DOM level 2, for example. Most notably, the event model, and everything based off it. This stuff was promoted to "recommended" status back in 2000.

There's hardly anything in Acid3 that isn't a recommended standard.

Besides, the W3C won't generally promote a standard from proposed to recommended until there are a couple of implementations of the thing out in the wild. Someone has to step up and implement them, so the bugs can be worked out. Although, from past history, Microsoft are probably the worst to do it.

The issue with IE 6 wasn't so much that it implemented incomplete standards. It was that it didn't implement even the proposed standards correctly, passed those off as finished implementations, and then wasn't updated for five years. Developers were forced to work around it, causing all kinds of havoc when Microsoft eventually did change some of this behaviour.

Compare that with the approach used by everyone else. Anything non-standard is marked with a browser-specific prefix. So are implementations of draft or proposed standards, or implementations of recommended standards that don't entirely match the behaviour expected. Anything unmarked is generally completely compatible between all those browsers (assuming they all implement it), and anything marked is a big warning sign telling developers not to rely on it, because it's behaviour may change. Or it may disappear completely.

They are conforming preciesly to the published standards of the W3C and no more. This leaves the W3C free to make ammendments to their draft standards that won't conflict with the most widely deployed implementation.

Not a bit of it. Microsoft are miles short of meeting W3C standards that have matured to the point of finality. DOM level 2 was published in 2000, and hasn't changed since. SVG 1.1 was published in January 2003, and hasn't changed since.

Microsoft are 5 or more years behind the times when it comes to "conforming preciesly to the published standards of the W3C".

Acid 3 is about bringing movies, animations and the likes to the net in a standardized manner.

As Microsoft's Silverlight tries to cannibalize the market again in a "Microsoft only" way, it is not entirely believeable that "not wanting to create a Microsoft variant again" is the true motive.

Microsoft should have done to the standards in question for ACID3, what OpenOffice and KOffice did for ODF: Implement not-yet finished proposed standards, giving feedback to the standardization organization, so they can improve the standard as it is implemented, which again can benefit the implementers.

Microsoft should have done to the standards in question for ACID3, what OpenOffice and KOffice did for ODF: Implement not-yet finished proposed standards, giving feedback to the standardization organization, so they can improve the standard as it is implemented, which again can benefit the implementers.

AFAIK, there aren't any "not-yet finished proposed standards" in Acid3. They are all five+years-old-recommended standards.

If that is not correct, and there is a level of a standard in Acid3 testing that has not been stable and had recommended status for over five years, can you say what it is?

personally I always though that ACID browser test were a dick contest anyway. But their first focus were on interoperability ( it sure does trails away from this one ) between browser, now it seem that browser vendor target their rendering engine/DOM for this test.

So what are today's standard anyway? the (first) browser war didn't helped that much because of lazy web designer / browser dev, what about this (second) browser war it seems that webkit is gaining more and more traction because of the support of not yet standard features ?

Anyway now Microsoft seem to be in the old Netscape place in this war. It is not about being standard, it's more about being future proof and regarding the deployment rate of IE7, how long would the user have to wait for a CSS 3 compliant IE 8.1/9 after the "validation" from the W3C ?

"DOM Level 2 was published in late 2000. It introduced the "getElementById" function as well as an event model and support for XML namespaces and CSS. DOM Level 3, the current release of the DOM specification, published in April 2004, added support for XPath and keyboard event handling, as well as an interface for serializing documents as XML."

Now it seems that Microsoft might be being a bit sneaky here (who would have thought?). DOM level 3 is current, and that may well still be draft, but the Acid3 test verifies compliance only up to level 2. Microsoft passes DOM level 1, but most other browsers are up to DOM level 2, and that is all that is being asked for ... only IE fails to comply. DOM level 2 isn't draft.

Similar story for SVG. The Acid3 test looks for complaince with SVG 1.1.

Many of the standards are already made. SVG 1.1, DOM level 2, DOM level 3 - already W3C Recommendations for many a year. Before taking the statement at face value, its wise to check which specs are in fact used in Acid3 and what the status is of each.

"The concern Microsoft has is that if we burnt [draft standards] into Internet Explorer 8 and passed Acid3 with 120 percent and then deploy it on so many machines, especially in the enterprise, [we have made draft standards de-facto standards] when the W3C will then want to innovate on the [evolving] standards," Hodge explained

What a crock of crud. Do what the others do, support the emerging "standards" and make changes as necessary. All this translates to is "IE is too poorly coded to allow for fluid changes so we're not even going to try"

What a crock of crud. Do what the others do, support the emerging "standards" and make changes as necessary. All this translates to is "IE is too poorly coded to allow for fluid changes so we're not even going to try"

Sure. And then, face the flak that they will receive for sure when applications and pages that were made targeting those drafted standards break as a result of the changes. Because it's Microsoft we're talking about, and you know, no matter how they play it, they cannot win.

Sure. And then, face the flak that they will receive for sure when applications and pages that were made targeting those drafted standards break as a result of the changes. Because it's Microsoft we're talking about, and you know, no matter how they play it, they cannot win.

So they choose not to play at all?

Sorry, but that's a weak excuse for not keeping technology up-to-date.

sure, I can understand with not keeping various bleeding edge standards out of the build, but items like SVG aren't bleeding edge and are a recognised standard. Not building SVG support is just lazy and bad form.

Sure. And then, face the flak that they will receive for sure when applications and pages that were made targeting those drafted standards break as a result of the changes. Because it's Microsoft we're talking about, and you know, no matter how they play it, they cannot win.

How many of these specifications are changed on whim with no considerations of browsers who have implemented them in the draft form? if you're going to make such bold claims about compatibility as the standard rapidly evolves; show me a case scenario in Firefox, Opera or Webkit where a draft standard has been adopted, the standard has changed, the browser is changed to be compatible with the new standard - and a website is broken.

"Sure. And then, face the flak that they will receive for sure when applications and pages that were made targeting those drafted standards break as a result of the changes. Because it's Microsoft we're talking about, and you know, no matter how they play it, they cannot win.

How many of these specifications are changed on whim with no considerations of browsers who have implemented them in the draft form? if you're going to make such bold claims about compatibility as the standard rapidly evolves; show me a case scenario in Firefox, Opera or Webkit where a draft standard has been adopted, the standard has changed, the browser is changed to be compatible with the new standard - and a website is broken. "

Precisely so.

Or even better ... you could ask ... "please identify any change whatsoever in any of the the web standards DOM level 2, SVG 1.1, or SMIL 2.1 since these have been first published many years ago". (These are some of the few that are required for Acid3 compliance).

We could also ask "Please identify anything in the higher (and still draft) levels of these standards (such as DOM level 3, or SVG 1.2) that in any way affects anything already standardised at a lower level."

Once these nonexistent "changes" to existing levels have been "identified" then we can perhaps move on to the nonexistent websites "broken" by draft standards (that no browser implements yet anyway).

Watch your announcement. All other browsers have more than 30% market share. Your statement about FireFox on Acid3 might be valid, but your careless reasoning has counteracted its validity.

That stat depends on your source. I've seen places saying that, and others saying IE still has 80%+ market share. Firefox and alternatives seem to be more popular in Europe, but not so much here in America.

"Watch your announcement. All other browsers have more than 30% market share. Your statement about FireFox on Acid3 might be valid, but your careless reasoning has counteracted its validity.

That stat depends on your source. I've seen places saying that, and others saying IE still has 80%+ market share. Firefox and alternatives seem to be more popular in Europe, but not so much here in America. "

So? I've seen sources that measure Firefox share alone at over 50%. Just because America is a backwards nation it doesn't mean that the whole world is behind technically.

So you see what, that is, open source software has more rapid frequency to introduce new features. While it takes years to create a new release for Windows (even for SP), and IE, it takes months for a Linux kernel and open source browser. So if IE left behind at the startup, it never catches up.

Actually.. I'd have to agree with Microsoft at this point. Its entirely valid.

Nobody should be using draft standards in their code anyway, even if browsers can use the standards. Otherwise later if the standards change, everyone will start crying "IE8 breaks standards" after changes are made to the standards, and Microsoft complies. Microsoft is in a position where people strike them down in ALL cases of operation. Hell, most mac users are still walking around telling people that "OSX doesn't bsod, and Vista BSOD's constantly". And they get away with it. Not everything MS does is right, but they best be cautious.

ACID3 is more of a marketing tool. Browsers like to make a lot of noise that they support it, but the reality is, only a few tests in ACID3 are valid (like the performance tests). Just because Safari or Opera supports ACID3 doesn't make them a good browser (I don't personally use IE8 or any of these).

What happens if the standards change? Even ACID3 will be broken then. We shouldn't encourage websites to be developed using standards which aren't set in stone, especially when there is no good reason to. There was a good reason to break standards with 802.11n (it offered genuine benefits, and the process was moving much too slow).

In this case, I'd rather Microsoft spends their time optimising IE, so that IE9's performance is finally at par, instead of WAYYY below.

Actually.. I'd have to agree with Microsoft at this point. Its entirely valid.

No, it isn't. Not valid at all. I'll explain why in a bit.

Not everything MS does is right, but they best be cautious. ACID3 is more of a marketing tool. Browsers like to make a lot of noise that they support it, but the reality is, only a few tests in ACID3 are valid (like the performance tests).

Where did you get this from? Acid3 test compliance with recommended standards. Not with draft standards ... recommended standards.

What happens if the standards change? Even ACID3 will be broken then. We shouldn't encourage websites to be developed using standards which aren't set in stone, especially when there is no good reason to.

There was a good reason to break standards with 802.11n (it offered genuine benefits, and the process was moving much too slow). In this case, I'd rather Microsoft spends their time optimising IE, so that IE9's performance is finally at par, instead of WAYYY below.

Only IE breaks these standards ... by not implementing them. Other browsers all comply to a very good level.

IE8 doesn't have a JIT Javascript compiler, so its performance is still WAYYY below par (as set by Safari, Firefox, Opera and Chrome).

I can see the gist of what is being said. But I will quote from the guy that wrote Acid 3 and the status of the current specs.

"If one were to try to write such a test suite for HTML4 and DOM2 HTML, one would find that there isn’t even one browser that fully implements those specifications, let alone two. We want to have such a high bar with HTML5 to avoid falling into the trap of saying “ok the specification is done” before we can actually prove that it is possible to implement HTML5 as written. There are things in HTML4 and DOM2 HTML that simply will never be implemented as written by browsers, for example, because implementing the feature as written would mean not rendering existing Web pages as the authors expected. If we find such problems in HTML5, we’ll change the specification — but to find such problems, we have to write big test suites and that’s going to take a long time. That’s what the last 10 years of the timetable are about."

so if Ian Hickson is saying that there isn't one browser fully implementing Dom level 2 or for that matter HTML 4.x (which is impossible because to fully implement the spec as it is currently written would contradict aspects of the same spec. other areas are not fully defined, and for that matter How a browser is expect to handle errors is not even remotely defined.

Microsoft has never shied away from "adopting" and "extending" draft and/or unofficial specifications. If this story were true, it would mean Microsoft had completely up-ended 15 years of worst practice; unlikely. What is far more likely is this: they couldn't get it to work, while at the same time: 1. maintaining what little vendor lock-in they still get due to the ignorance of the management class, and 2. not shoot their Silverlight baby in the head by providing a viable Ajax-based platform.

Microsoft is deathly afraid of Ajax; Ajax makes pretty much everything they have to offer irrelevant. So they are trying to kill it by pushing a Javascript-disabled "browser". No surprise there.

Microsoft has never shied away from "adopting" and "extending" draft and/or unofficial specifications. If this story were true, it would mean Microsoft had completely up-ended 15 years of worst practice; unlikely. What is far more likely is this: they couldn't get it to work, while at the same time: 1. maintaining what little vendor lock-in they still get due to the ignorance of the management class, and 2. not shoot their Silverlight baby in the head by providing a viable Ajax-based platform.

Microsoft is deathly afraid of Ajax; Ajax makes pretty much everything they have to offer irrelevant. So they are trying to kill it by pushing a Javascript-disabled "browser". No surprise there.

Or more correctly a browser that does 'javascript good enough' - its even more pathetic seeing the number of pathetic losers in large software companies who INSIST on using ActiveX/IE only features instead of AJAX.

I wonder instead of the EU going after Microsoft they went after these vendors instead who refuse to write software that is multiplatform and not tied to a particular piece of proprietary technology.

Microsoft Outlook Web Access was a very early AJAX application that is widely used. I've copied a quotation from Shreesh Dubey in Code Magazine that provides further insight into javascript performance http://tinyurl.com/ctcs32.

'...We worked closely with the Google Gmail product team and focused on making engineering fixes that directly resulted in improved end-user performance. As a result of these efforts, we were able to directly impact commonly used Gmail operations between 15% - 25% compared to Internet Explorer 7. We believe Gmail is quite representative of the current generation of AJAX applications in how they exercise the AJAX subsystems, so we think other AJAX applications will see similar improvements...'

[quote]
He went on to say that Microsoft learnt its lesson with Internet Explorer 6. "Our learning comes from IE6. With IE6 we adopted some non-recommended standards and interpreted them in a certain way. The end result of that has been painful web development."
[/quote]

I have no sympathy for MS on this comment, every one with an ounce of intelligence knows that MS was thinking:

"We hold the commanding market share, everyone will program against IE, if we make the way that IE does things slightly different to other browsers then it will break sites on other browsers, ensuring that people stay with IE."

Their strategy initially worked but what they never counted on was the level of resistance that came from web developers when great alternative browsers appeared and gained popularity in the enthusiest community.

At least MS can admit that they made a mistake, but I wish that they'd stop making it sound like it was an innocent mistake.

At first I completely agreed with Microsoft - that is until I did some research.

IE8 scores 20/100 on the Acid3 test. This would be no problem at all, given the excuse for failure, if it only failed in those areas which tested for compliance with a non-standard standard :-)

I would expect IE8 to pass all tests which rely on a currently finalized version of a standard. New browsers should rarely be behind in his arena. IE8 still seems to be missing support for even OLD standards ( such as SVG ).

Passing ACID2 is all well and fine, it allows you to really call yourselves "standards compliant," but it doesn't really reflect the current state of affairs.

What we need is a web standards version numbering system outside of these tests. The version should increment on a fairly rigid schedule, every year.

Web Standard Version 2009 would require the ISO version of SVG 1.1, CSS 2.1, PNG 1.2, etc... Any new major browser version being released would be expected to have support for WSV-2009.

I believe, by this standard, we could give IE8 a good WSV-2000 blessing. Maybe a bit newer even. What is the saddest of all this must be that IE8 is a major improvement in this area for Microsoft. That is really sad.

In an anarchist's world, we must all move more or less in step, in an orderly fashion, or else we will punish ourselves - which is fine if we don't care.

A standardized, and advertised, web versioning system is what the world needs now. When OEMs must choose between a WSV-2008 compliant browser (say, Firefox or Opera) or a WSV-2000 compliant browser, they will see the choice as being an easy one - and Microsoft will need to everything possible to make IE9 WSV-2009 compliant.

Obviously using the years as the compliance level is not really a good idea, Web 1.0, 1.1, 1.2.. 2.0.. etc... would work just as well!

What we need is a web standards version numbering system outside of these tests. The version should increment on a fairly rigid schedule, every year.

Web Standard Version 2009 would require the ISO version of SVG 1.1, CSS 2.1, PNG 1.2, etc... Any new major browser version being released would be expected to have support for WSV-2009.

The numbers after the W3C standards don't specify versions in the normal sense ... they specify levels.

DOM level 1 is the elementary level of the DOM standard. IE complies with this, and it is part of acid 1 tests.

DOM level 2 is the next level of the DOM standard. It specifies extra functionality over DOM 1. It does not supplant DOM level 1. Opera, Firefox, Safari and Chrome comply with this as well as DOM 1. IE8 does not. This is tested in Acid 3.

DOM level 3 is what the W3C is working on now. This is the bit in draft. It is functionality in addition to DOM level 1 and DOM level 2, it does not supplant the earlier levels.

It is a similar story for SVG. SVG 1.0 is the first level. SVG 1.1 is a higher level, with additional functions. This is tested in Acid 3. Opera, Firefox, Safari and Chrome comply with this level. IE8 does not. SVG level 1.2 is what the W3C is working on now, and this is draft.

The numbers are incremental levels of functionality in the (static) standard, they are not incremental versions of the standards. Later increments do not affect earlier increments, they just add functionality.

In other words ... Microsoft's stated excuse for not complying with Acid3 is a crock. Utter BS. Liar, liar, house on fire.

Well, what others call "levels" I call version increments :-) Though I guess that isn't true as you could then have a version 2 for Level 1.2 ( i.e., version 1 or L 1.2 was buggy ).

Anyways, I did see some mention to the "level" this "level" that, but did not connect the dots, so I must offer my thanks to you for the enlightenment.

In any event, however, I believe then a graduated compliance scale should be devised as to avoid confusion. After all, it would appear that Microsoft ( or this particular talking mouth ) did not understand this whole "level" thing much in the same way that I did not understand.

Acid3 does, however, test for compliance with standards "levels" which have not been agreed upon or finalized, so the issue remains of, in reality, a test going too far.

Maybe we need an "Acid-ISO" conformance test which tests for all current international standards, and doesn't try to jump the gun regarding which tests to include.

We need a cleaner method - one that an end-user can understand. The higher the number the better, calling it Internet 2.0 Compliant would be a great way to foster fair competition.

Well, what others call "levels" I call version increments :-) Though I guess that isn't true as you could then have a version 2 for Level 1.2 ( i.e., version 1 or L 1.2 was buggy ).

That is not it. It doesn't work like that.

IE, as do all other browser, complies with DOM level 1.

DOM level 2 was published in 2000. It hasn't changed at all since. DOM leevel 2 includes DOM level 1, plus extra functions. Your browser still needs to be compliant with DOM level 1 in order to be compliant with DOM level 2. It is like adding an extension to a house ... you still have to have the house in order to have the house plus extensions.

IE doesn't have this, it (alone) is stuck at DOM level 1.

DOM level 3 was published in 2004. AFAIK, no browsers have complied with that as yet. In order to do so, however, they won't have to throw away any of the functionality of DOM level 2.

I meant version of Level meaning a bug was discovered in the standard - not an implementation, but the standard itself. This happened before, but I can't remember which it was, and for what reason.

There are also different versions of PNG 1.2, according to WikiPedia.

I actually understand parsers & interpreters ( i.e. browsers ) exceedingly well having written quite a few implementations myself, I just haven't ever had the need to code for standards compliance - I'm a ground-up kinda guy.

The WEBKIT team know that CSS 3.1 isn't final; so, they prefix "WEBKIT-" before all non-standard and non-final standard tags. This is the recommended method of adding non-standard features to your browser.

Why can't Microsoft support the current standards in full CSS 2.1, and SVG 1.1. They could then add the "IE-" prefix to the CSS3.1 elements and SVG 1.2 elements. It is always assumed that the behavior of "Browser_Tagged" elements are subject to change in the future and you should use at your own risk. When the standard becomes finial the developers can verify that they implemented the element correctly and then remove the prefix tags.

all comments about dom versions, drafts or not drafts, etc are right but lets get real, Microsoft will throw cheap excuses for things like this until they are "really" losing market (i mean, global market... i know osnews readers prefer firefox, i read "the stats").

the last "i" has been dotted and "t" crossed for over five years, and in some cases for over eight.

DOM level 2 (as required by Acid3) was published in laate 2000. Not one letter of the standard has changed since. The fact that DOM level 3 came out in 2004 has nothing to do with a browser complying with DOM level 2 or with Acid 3.

The higher levels of these standards just add functionality on top of the lower levels, like layers on a cake.

the last "i" has been dotted and "t" crossed for over five years, and in some cases for over eight.

DOM level 2 (as required by Acid3) was published in laate 2000. Not one letter of the standard has changed since. The fact that DOM level 3 came out in 2004 has nothing to do with a browser complying with DOM level 2 or with Acid 3.

The higher levels of these standards just add functionality on top of the lower levels, like layers on a cake. "
Good post, lemur2 - thanks for that.
Yes, and organisations like Mozilla, Apple etc manage to get very good standards-compliance with their browsers (and with a fraction of the staff and funds that MS has). That makes MS' comments/excuses about "draft standards" look hollow indeed.

"The concern Microsoft has is that if we burnt [draft standards] into Internet Explorer 8 and passed Acid3 with 120 percent and then deploy it on so many machines, especially in the enterprise, [we have made draft standards de-facto standards] when the W3C will then want to innovate on the [evolving] standards..."

I totally agree with this.

"It surely is an interesting view on things, but it's also a flawed one. The standards tested by Acid3 might not be official standards just yet, but with Opera, WebKit, and Gecko all working towards supporting it, Trident could've just followed and make it the standard. This would've certainly earned Microsoft some good karma, something it could use in the browser market (what, with IE bleeding market share like a decapitated bunny)."

This is stupid. Why the heck do you want to make a draft standard the final standard without proper review? There is a REASON they are still in draft. What if a major issue was discovered. Oh, yeah, real good karma with that, right?

This kind of behaviour (just making something the defacto standard because you want/can) is the kind of thing Microsoft used to participate in with older versions of IE.

What if Microsoft implements some of the draft standard in a certain, but not technically incorrect, way and hen the final standard changes slightly? Whoops. You now have a proper (W3C) standard and one that is used by 90% of all browsers (IE). Great we are now back to square one and have solved nothing.

And no, they cannot just realise a x.1 version of IE to slightly change how they implement the standard to make it 100% compatable with the final version. That could break many many peoples websites.

Thom. This is probably the dumbest thing I've read from you. You don't even justify how it would ".earned Microsoft some good karma"

"The concern Microsoft has is that if we burnt [draft standards] into Internet Explorer 8 and passed Acid3 with 120 percent and then deploy it on so many machines, especially in the enterprise, [we have made draft standards de-facto standards] when the W3C will then want to innovate on the [evolving] standards..."

I totally agree with this.

"It surely is an interesting view on things, but it's also a flawed one. The standards tested by Acid3 might not be official standards just yet, but with Opera, WebKit, and Gecko all working towards supporting it, Trident could've just followed and make it the standard. This would've certainly earned Microsoft some good karma, something it could use in the browser market (what, with IE bleeding market share like a decapitated bunny)."

This is stupid. Why the heck do you want to make a draft standard the final standard without proper review? There is a REASON they are still in draft. What if a major issue was discovered. Oh, yeah, real good karma with that, right?

This kind of behaviour (just making something the defacto standard because you want/can) is the kind of thing Microsoft used to participate in with older versions of IE.

What if Microsoft implements some of the draft standard in a certain, but not technically incorrect, way and hen the final standard changes slightly? Whoops. You now have a proper (W3C) standard and one that is used by 90% of all browsers (IE). Great we are now back to square one and have solved nothing.

And no, they cannot just realise a x.1 version of IE to slightly change how they implement the standard to make it 100% compatable with the final version. That could break many many peoples websites.

Thom. This is probably the dumbest thing I've read from you. You don't even justify how it would ".earned Microsoft some good karma"

A metaphor might help here: it is like a multi-story building ... you can start to build the second floor (after all, those plans have been finalised for over five years now) ... even if they haven't yet finally decided on the colour of the carpet in the penthouse.

There is no way that the final colour decided for the carpet in the penthouse will "break" the work you are doing now on the second floor.

All the other "builders" in the development area have finished building their second floor, and are well started on the third floor.

End metaphor. Get it now? No-one is changing the second floor, it has been approved for construction (as it is) for five years already. Build it, for goodness sake!

Thom. This is probably the dumbest thing I've read from you. You don't even justify how it would ".earned Microsoft some good karma"

Together with the "you should've said Miller entered the contest with an exploit in hand instead of coming up with one in a few seconds" this is the second time people here are asking me to explain the bloody obvious.

"It this is the real reason, why did they bother implementing stuff in IE8 like document.querySelector from the W3C Selectors API when it's still a draft spec too?

Because compared to some of the other stuff, this is actually useful in the real world? "

What you meant to say, surely, was that "unlike other stuff, the document.querySelector from the W3C Selectors API doesn't achieve, in an open standards way, functionality which we wish to be kept as lock-in for Silverlight".

No worries, I've seen your mis-information all over this thread and was waiting for your response.

Browsers are free, no one cares about lock-in...if you don't like what a browser does (as an end user), then move on. If you don't like what it does (as a developer) then don't develop for it, or figure out ways around whatever isn't working for you.

Sometimes I wonder if the only people who jump up and down screaming "standards standards standards" are people who've never actually developed real world web apps, simply because they have nothing better to do.

Have you ever wondered why these standards are still just in 'recommended' or 'draft' standard? Because no one out in the real world of web development cares about them...at least not the ones mentioned over and over in this thread.

JIT javascript compilers deliver very impressive performance and open up entirely new capabilities.

Perhaps, as a web developer, it is time that you updated your skills to encompass these new emerging standards-based features, rather than relying on the already-on-its-way-out non-standrad quirks of IE and proprietary plugins for it.

Have you ever wondered why these standards are still just in 'recommended' or 'draft' standard? Because no one out in the real world of web development cares about them...at least not the ones mentioned over and over in this thread.

The ones mentioned like PNG, SVG 1.2 (or 1.1/1.0)?

I haven't met anyone "in the real world" who isn't about standards for a while, about 3 years. Maybe I'm not in the same environment as you.

"In the real world" standards save time, and because time is money it saves money too. It means with the exception of IE, I can trust that my site will work (with about 99% certainty) on the next iteration of their browser engine. And here's a kicker, I charge extra on a monthly fee for testing when new browser versions come out. It's about keeping the site updated.

"In the real world" it's really important that browsers implement these standards correctly and keep up to date with new ones to push the web forward, not their own agenda.

One thing I don't see mentioned as a reason for implementing drafts of standards with specific tags is so developers can start testing them before using them on live sites. As more developers test the more likely a glitch will happen. The more likely a glitch is found before real world implementation of the spec, the less likely it will hinder the web.

Some standards should of course be adhered to, and the ones you mentioned are decent examples. But everything in Acid3? Sometimes I feel that many developers do frilly stuff like that just because they can, not because they should.

Some standards should of course be adhered to, and the ones you mentioned are decent examples. But everything in Acid3? Sometimes I feel that many developers do frilly stuff like that just because they can, not because they should.

I cannot side with Microsoft here, as long as they leave important pieces of the puzzle out (SVG) while offering incompatible own implementations to improve vendor lockin (Silverlights vector graphics which were clearly derived). We are not talking about kitchen sink here, but something along the lines of being able to display real vector graphics.

I don't blame any browser manufacturer for deciding if and when to implement a new W3C 'standard'. The W3C creates virtually a new 'standard' every day for all sorts of completely inane things that maybe one or two people want to do with a web browser.

XForms? Timed Text? XML Events? OWL? Pronunciation Lexicon Specification? These are just a couple of examples of ill-considered, difficult-to-understand or completely useless W3C "standards" that have failed to take hold and as such as of absolutely no use to anybody. If Internet Explorer's developers tried to implement all these W3C 'standards', they wouldn't have time to add essential browsing features such as tabbed browsing and Javascript.

So, good on Microsoft for drawing the line somewhere. If Acid3 is finalised, then support it. Until then, assume it's another XAdES.

IE 8 passes Acid 2. I think that's awesome given that previous releases failed and so many standards fronts.

If there's a moving target in play here it's personal standards of the community of folks who care about these things. The cry used to be "You guys don't even pass Acid 2". When they finally pass Acid 2, it becomes, "Well... yeah.. but you don't pass Acid 3." However valid Acid 3 may be as a standard (and I'll even completely grant its validity) any sort of outrage or finger wagging is way over-blown.

The fact that MS made a judgement call with which we disagree should be call for mild disappointment not a call to pitch forks and excoriation. Granted, I doubt the folks in the browser division are angling for our love and adoration but If we truly want the Microsoft to play nice and be a part of the "community", maybe we should play nice, too.

I should point out that I'm typing this into an ACID 3 compliant browser and that I'm a developer of web-enabled products and such things are quite important to me.

cTests against a huge list of non draft standards. SVG for instance definitely is non draft, and old enough that Microsoft was able to fork it away under its own name and with a handful of changes. But yet IE8 does not support it. The same goes for a myriad of other things which are the reason why IE does not even reach the 70% Firefox does.

The only drafts Acid3 tests is, HTML5, CSS 3 and EmcaScript 4!
But those count for 30% maximum while IE8 reaches around 17%

MS forgets its strategy doesn't work anymore. It used to work, because faster browsers weren't that known, but now users notice that other browsers like firefox, opera are a lot faster. Users don't care about acid tests, they just want a good and fast surfing experience.
If MS is interested in gaining market share they should implement the standards used by other browsers. If they implement the features the same way as its main competitors those features will become the standard anyway.
I call it features, which is about the web standards, but also about other stuff, so the complete browsing experience. If their browser works almost as fast and good, users won't see the need to change. Looking at the stats users do change even though IE is already installed on their computer!
It is possible that MS will start to act when companies that create IE-only web applications now start to create acid3-only web apps... That will happen when firefox and others keep gaining market share.

I say this because I remember that Opera announced that it was the first browser to pass ACID3. Later that week, ACID3 itself was tweaked (to fix some problem or whatever). That tweak caused Opera to no longer pass ACID3. The Opera team made a new release to re-pass ACID3. This showed that Opera coded against ACID3, not against the "standards" that ACID3 is supposed to test. Opera passes ACID3, but does it really support the "standards" in question in a robust manner? Not if they have to update Opera whenever ACID3 changes.

Microsoft could have done like Opera did and code against ACID3, even if they didn't robustly support the standards in general. But it's a waste of time, means nothing except a checkbox on the "features" list.

Let the "standards" become real standards, then support them accordingly, I say.

I say this because I remember that Opera announced that it was the first browser to pass ACID3. Later that week, ACID3 itself was tweaked (to fix some problem or whatever). That tweak caused Opera to no longer pass ACID3. The Opera team made a new release to re-pass ACID3. This showed that Opera coded against ACID3, not against the "standards" that ACID3 is supposed to test. Opera passes ACID3, but does it really support the "standards" in question in a robust manner? Not if they have to update Opera whenever ACID3 changes. Microsoft could have done like Opera did and code against ACID3, even if they didn't robustly support the standards in general. But it's a waste of time, means nothing except a checkbox on the "features" list. Let the "standards" become real standards, then support them accordingly, I say.

Acid3 isn't the standard. Acid3 is a test of compliance to selected levels of the standards ... and at one stage one of the tests may have been flawed, and subsequently corrected. That doesn't mean the standard was flawed, nor does it mean that the standard was changed.

From the link:

"The test was officially released on 3 March 2008. A guide and commentary was expected to follow within a few months, however, as of September 2008 it has not yet been released. The announcement that the test is complete means only that it is to be considered "stable enough" for actual use; if problems and bugs are found, it will still be modified to fix it. The test has already been modified to fix several issues including issues regarding to sub-pixel positioning, SVG surrogate pairs and performance. On 26 March 2008—the day both Opera and WebKit teams announced a 100/100 score—developers of WebKit contacted main Acid3 developer Ian Hickson about a critical bug in the Acid3 that presumably may have forced a violation of the SVG 1.1 standard to pass; thus Hickson proceeded to fix it with the help of Cameron McCormack, member of W3C's SVG Working Group.

By the end of March 2008, early development versions of the Presto and WebKit layout engines scored 100/100 on the test and rendered the test page correctly. Presto still has performance issues in producing a smooth animation in the test, thus it has not passed the Acid3 test yet. As of build r36882, WebKit produces a smooth animation on the reference hardware, and thus passes the Acid3 test. Firefox developers had been preparing for the imminent release of Firefox 3, as a result they had focused on stability rather than passing the Acid3 test. Microsoft, developers of the Internet Explorer browser, said that Acid3 does not map to the goal of Internet Explorer 8 and that IE8 will improve only some of the standards being tested by Acid3.

On 22 April 2008, Hickson again fixed a bug in the Acid3 test discovered by a Mozilla developer. This change possibly invalidates the previously reported scores of 100/100 for development versions of Presto and WebKit. On 29 September 2008, David Baron raised an issue with the CSS Working Group concerning media queries that might cause the test to change again."

As I said, bugs were in the Acid3 test, not in the standards themselves, which AFAIK haven't changed since first publication.

Please indicate which of these levels (as named in the Acid3 test scope) of the standards has, in any way, changed since their publication dates, which in most cases was from between five to eight or nine years ago.

Note: If the XTHML test includes anything from HTML 5, then that would be one such case. Perhaps the only one.

Note also: I am in full agreement with the developers of IE8 when they said "that Acid3 does not map to the goal of Internet Explorer 8". Full agreement. IE8 certainly has no goal of standards compliance, particularly when it comes to any long-published standards that ages ago specified functionality that Microsoft have put instead into non-standard proprietary Silverlight.

This is coming from someone with 8 years experience developing web applications for large corporate IT departments, so take it for what you want...but I do feel I'm qualified enough to speak for most large IT departments.

Fact: By far and large, the vast majority of web applications exist on the LAN for corporations.

Fact: Almost all of these LAN users use IE as their browser. On most of the LANs, other browsers are prohibited...not because they are inferior (which they aren't), but because of support costs. It is much cheaper for IT depts to support a single vendor's software.

Fact: Corporate IT departments don't care about standards. They care about time to market, simplicity, and maintainability. Adhering to standards makes the development cycle more complex, and thus more expensive...and for what advantage? "Just Working" is goal number one, maintainability (e.g. simple to maintain) runs a very close 2nd.

Fact: MS's largest installed userbase (not just by %, but also by sheer numbers) is within companies.

Fact: MS isn't going to go out of their way supporting some of the edge cases that the Acid tests call for just to appease what would be a tiny portion of their customers since (as stated above) most of these customers don't care about edge case standards. Most of them are easy to code around, or aren't even necessary in the first place.

Fact: Building in support for standards that are rarely used costs MS extra money, and the ROI just isn't there.

It's not rocket science to see why MS doesn't throw in the kitchen sink supporting every willy nilly standards that exists just for the sake of saying that they can. I have never ever encountered a case where development on an application came to a halt because x browser didn't support y standard. None of my colleagues have either...in fact, I doubt this has EVER happened. You either code around it, or move on and find a different solution. This is why I get such a kick out of hearing people cry foul about standards support...most of these "standards" are luxuries that increase cost and complexity. 98% of web applications (on the browser end) consist of HTML + CSS + Javascript + some sort of image rendering. All the crap in the Acid tests are luxuries that only a small percentage of sites actually use.

So what's the logic in supporting everything under the sun when usually the basics are plenty good enough?

To be fair, the big missing elephant in the room is SVG. I don't think it's accurate to state that SVG has been out there (in usable browser form) for 8-9 years like some have been claiming, but more like 2-3 years in incomplete form (at least according to the history in Wikipedia).

Probably the IE folks decided that SVG was not high priority for this release. They may also still be unhappy about the rejection of VML.

To be fair, the big missing elephant in the room is SVG. I don't think it's accurate to state that SVG has been out there (in usable browser form) for 8-9 years like some have been claiming, but more like 2-3 years in incomplete form (at least according to the history in Wikipedia).

Probably the IE folks decided that SVG was not high priority for this release. They may also still be unhappy about the rejection of VML.

Actually SVG as a plugin has been there even for the IE since day 0. Adobe just dropped the ball on SVG after the bought Macromedia. But it was too late then the ghost was out of the bottle, aka SVG was official web standard and others have started to adobt it.

As for Microsoft, yes the biggest blocking stone for IE8 is the lacking of SVG, it did not have high priority for them, due to the fact that they have their own incompatible SVG implementation in Silverlight (It really is a fork of svg with a few commands changed) so people should use that instead if they want vector graphics on IE...
But there is some hope left for SVG on IE9 Microsoft seems to discuss it internally, and after all the beating they got for the lack of SVG in IE8 they maybe will adobt it after all (god knows how incompatible they again will make it like they did it with everything else in the past)

My biggest guess is how to force the browser vendors to certain standard levels probably would be to have some web09 we08 etc... branding, which they would be allowed to use if they implement a certain set of standards correctly. The Acid tests really helped in this regard but we need more and something more understandable for the average user.

As for the corporate problem, yes many corporations are on IE and most of them still on IE6 due to many factors, but I think the upgrade cycle there will soon get going, after all Windows 7 does not look like a total looser like Vista did, and Microsoft now pushing out a major browser release almost every year will make the stuck gear starting again. My hope is that the days of ie6 are numbered now that ie8 is out.

To be fair, the big missing elephant in the room is SVG. I don't think it's accurate to state that SVG has been out there (in usable browser form) for 8-9 years like some have been claiming, but more like 2-3 years in incomplete form (at least according to the history in Wikipedia).

Probably the IE folks decided that SVG was not high priority for this release. They may also still be unhappy about the rejection of VML.

The history of SVG on Wikipedia says this:

SVG 1.0 became a W3C Recommendation on September 4, 2001.
SVG 1.1 became a W3C Recommendation on January 14, 2003.
SVG Tiny 1.2 became a W3C Recommendation on December 22, 2008.
SVG Full 1.2 is a W3C Working Draft.

So the level asked for in Acid3, which is SVG 1.1, has only recently become available in those browsers that mostly pass Acid3 (that is, almost anything except IE).

That level of SVG has been a recommendation (i.e. stable) for over six years now. SVG 1.1 is the stable level, and that is all that is reasonably required to be considered standards compliant.

The additional SVG functions defined in level 1.2 Tiny are too recently recommended to expect to be implemented anywhere as yet, and the further functions defined in level 1.2 Full are still draft.

BTW, DOM level 2 compliance being missing in IE is almost as big an elephant in the room. As is the lack of a compliant JIT javascript compiler. Actually, we seem to have a bit of a huge roomful of elephants.

Reading some of these comments are a hoot... Got news for folks - When did CSS2 exit draft? 1998... When did you start to see it's widespread use in the manner it was meant to because it was real world deployable? 2004-2005 ish.

Is support for CSS2 complete TODAY over a decade later? NOPE.

Just because the browsers support it does that make it deployable? Nope.

As I've said before several places I do not expect the majority of CSS3 to be real world deployable until sometime around 2015 to 2020.

... and I actually APPLAUD the IE team's deciding to try and focus on getting CSS2 correct before moving on to CSS3 - lands sake if only the mozilla folks bothered with that we'd not have a buggy inline-block that most developers are claiming works properly, and we'd have properly working colgroups, correct default positioning of elements inside inline-block ones, working @page, working attr=, fully styleable psuedo-elements, proper behavior of white-space on textarea, working pre-line, working display:run-in, properly triggering blur when onchange is tripped, properly implemented print properties... Hell, none of the browsers even implement float:right and float:left 100% correctly yet! (rarely an issue, involves line-collapse upwards)

As I said on the DECADE OLD UNRESOLVED bugzilla #915, maybe they should concentrate on finishing off HTML4 and CSS2 before having people wasting time on specifications that aren't even out of draft? (HTML 5 and CSS3)

Glad to see somebody listened, too bad it wasn't Mozilla.

Oh, and as to SVG, Adobe dropped it hard because they realized it couldn't compete with Macromedia Flash, so they took a page out of Symantec's playbook and bought out macromedia, buried their own product and rebranded Flash as their own...

Wait, no, my bad... Adobe has a history of doing that too - see what happened to Aldus.

Oh, and as to SVG, Adobe dropped it hard because they realized it couldn't compete with Macromedia Flash, so they took a page out of Symantec's playbook and bought out macromedia, buried their own product and rebranded Flash as their own...

Yes but show me one open standard doing decent vector graphics implemented by many browsers pluginless and you will end up with SVG, we do not have an alternative, period!
If you can show it to me I will be happy to stop my ranting!

The history of SVG is pretty well known, but that does not make it a pointless or useless standard, in fact it is one thing most web designers today really miss, the possibility of scalable resolution independend graphics. I am not even talking about the advanced capabilities of this format (which btw. would make most of flash obsolete) I am just talking about plain vector rendering as it was specified by SVG 1.0.
That Adobe dropped it was clear, they got possiblity to buy their strongest competitor and got basically an industry defacto standard into their hands with a superset of SVGs functionality so why still bother with SVG. Again that does not make the standard itself pointless in fact it is very important!
Important enough that Microsoft saw the need to fork it away and rename it to XAML!

And so far Microsoft is the one party to the browser mix who again prevent the widespread usage of an important technology, just like they did so many times. All I may say here is PNG transparency and how many years people had to suffer through transparent gifs or browser hacks which slowed the IE rendering down!

I actually agree SVG is an important technology - but I have the same trepidation about it's use I have for flash, since open/closed so far as standards means shit to me.

Just as flash is ABUSED for things like headers, text replacement, navigation and other applications where it is an accessability fail and bloats out the page needlessly, SVG runs the same risk. In a lot of cases it will be a bandwidth saver where vectors are smaller than fixed images and will resize better - and I'm all for that... The problem is in a lot of cases it's just going to be used and abused by people who have no business designing websites in the first place - you know, the people commonly known as 'flashtards'. After all there's a reason it's called flash and not substance.

As to transparent png, all supporting that does is increase the sizes of websites up into the stratosphere, as if we don't have enough of that drek already with many websites peaking out over a megabyte all to deliver under 2k of text content... Then trying to use technologies like Ajax, flash (and soon SVG) to try and save bandwidth or compensate for CSS being 'too hard' to understand, and instead accomplishing the exact opposite. (Have a look at the steaming pile of manure known as the code behind the latest incarnation of hotmail for an example of bloating out a page and making it slower in the name of saving bandwidth and increasing speed!).

Rarely are alpha transparent .png neccessary for a layout, and usually result in fat bloated rubbish that just costs bandwidth for something that can usually be pre-composited... The only people that REALLY give a flying fig about alpha .png are the same art faygala's who forget that users do not visit websites for fancy bandwidth chewing layouts crammed full of "gee ain't it neat" technologies like flash banners.

Users visit websites for the content - frankly if you are kvetching over alpha .png, the site in question is probably not doing all that well in that department as more time is being spent on goofy graphics than anything of value the end user might actually visit the site for.

Oh, and don't forget IE has supported palettized transparent .png since IE4... The only REAL complaint I have about .png is that it doesn't color-match becuase the artificial gamma correction IE applies to .gif, .jpg and CSS/HTML color values is not applied to .png - oh noes, I might have to use a .gif or .jpg - aah, it's the end of the world...