W3C Says IE9 Is Currently the Most HTML5 Compatible Browser 382
GIL_Dude writes "The W3C posted results for their latest HTML5 compatibility tests and have found that, so far, IE 9 has the best overall results. 'The tests cover seven aspects of the spec: "attributes," "audio," "video," "canvas," "getElementsByClassName," "foreigncontent," and "xhtml5." The tests do not yet cover web workers, the file API, local storage, or other aspects of the spec. Not do they cover CSS or other standards that have nothing to do with HTML5 but are somehow lumped under HTML5 by the likes of Apple, Google, and Microsoft.'"
Posting from IE8... (Score:5, Interesting)
Well I'm going to say congrats... (Score:5, Interesting)
Now figure out a way to get people to stop using IE6. (maybe an add-on to IE9 that makes it so you can run your ancient IE6 only apps?)
Re:Not suprising (Score:2, Interesting)
No kidding - place I work has to block Chrome, Safari, and Firefox at the firewall since all three have actively exploited zero-day exploits.
But not IE8. It's secure.
And, yes, they also block all versions of IE prior to 8, because those also have actively exploited holes in them, but if there's one thing Microsoft did right in Vista, it's securing IE. Too bad no other browser maker takes advantages of the OS features used to do that.
Re:Not suprising (Score:5, Interesting)
Re:Not suprising (Score:3, Interesting)
For all the flak IE gets, it's actually a great browser..
I don't mind IE at all, and use FF daily too. However I much prefer the text rendering of Safari on both PC and Mac
Re:What kind of a "standard" is this? (Score:2, Interesting)
My first suspicion (Score:4, Interesting)
Tried with latest chromium (Score:3, Interesting)
Just tried with latest chromium, it passwed all random tests I clicked on, that the tested chrome failed on.
Re:What kind of a "standard" is this? (Score:1, Interesting)
oracle ftp clients are not standard compliant. I know of some other clients that are not standards compatible.
Re:Not suprising (Score:5, Interesting)
No other browser is limited to Windows.
Re:Well I'm going to say congrats... (Score:2, Interesting)
It does support quite a bit of the css3 draft including rounded corner, box shadows, etc..
I find it funny that IE (from 7+) seems to have the best implementation of @font-face
Dear W3C, there exists good test for HTML5 already (Score:1, Interesting)
Some of tests seem dumb, and site seems broken. (Score:3, Interesting)
I stopped clicking through the tests one-by-one when I came across one that would have been fixed by a simple “if (x1 == x2 && y1 == y2) return;”. I went ahead and scrolled down the list, though... for some reason a lot of the tests near the bottom read “No Result” for many/most browsers, and clicking a test at random (canvas(2d.transformation.scale..zero.html) [w3.org]) that said “No Result” in every column except Safari gave me a 404 error.
I’m not terribly impressed.
It's worse than that (Or.. IE is better than that) (Score:1, Interesting)
According to W3Schools [w3schools.com], FireFox didn't support XSLT before version 3 and Opera didn't before version 9... But IE 6 supported it.
Re:Not suprising (Score:3, Interesting)
They're also comparing a development version of a browser to the released versions of other browsers, instead of their development versions. For example, Chromium already passes tests that Chrome failed in the article.
The test is vastly incomplete... (Score:5, Interesting)
...according to the test developers [w3.org].
According to wired [wired.com]:
Run IE9 against other aspects of HTML5 and the browser would be decidedly behind its competitors. IE9 lacks support for Web Workers, drag-and-drop features, SVG animations and the File API, all of which are vital components for building useful web applications, and all of which enjoy considerable support in other browsers.
Re:Not suprising (Score:3, Interesting)
From the coverage of the tests, they seem to be pretty close to the features that were tested in Microsoft's own compliance tests, which were then submitted to the W3C for inclusion in the W3Cs test suite.
To highlight this: see here [w3.org].
Notice that the only directory here is "Microsoft"?
Comment removed (Score:3, Interesting)
Re:Not suprising (Score:5, Interesting)
As a CSS guy, this means I find other browsers infuriating. Now that we have Webfonts I want to render ever piece of text with fonts instead of graphics...but getting a banner to just the right size is often impossible without a fractional font size. As a normal user ...
As a normal user, I do not want you to have the ability to define exact pixel sizes of fonts, without my ability to override them without completely breaking site layout (which is what will happen if your buttons etc will be designed for a specific size). There are many reasons for why that is the case, but the most obvious one is that I do not want to see tiny, hard-to-read text, and so all my browsers are set up to not allow anything below 13px. Any well-designed website works fine with such an arrangement; if yours does not, I will just go elsewhere.
By the way, one of my personal dislikes with Flash is that there is no way to impose a similar restriction there, and that Flash designers, for some reason, love tiny fonts for menus, buttons and such.
Re:Posting from IE8... (Score:3, Interesting)
I know it's a petty nitpick, but hear me out. There's a reason the more intelligent among front-end web developers ditched the term "graceful degradation" for "progressive enhancement". For all but a minuscule (but growing) portion of possible web tasks, the client-side approach has a direct HTML/HTTP/server-side analog with—if we're doing our jobs right on the client-side—a UI that is less usable and slower. Even though the two philosophies could be implemented the same way, they rarely are. The philosophy of "graceful degradation" is essentially that the UI is the application and its core functionality is an afterthought to be implemented as a fallback; the philosophy of "progressive enhancement" is essentially that the core functionality is the core responsibility, and that client-side behavior is meant to improve the user experience. Another difference between the philosophies is that, where the analogs exist between client-side and traditional functionality, "graceful degradation" tends to carry with it an implication of increased development cost, whereas "progressive enhancement" promotes a model that allows simplified development. (Again, note that I am not discussing the terminology so much as existing differences in approach.)
I think, though, there's a line to be drawn between content delivery and applications, in terms of the responsibility of web developers. I don't think that information on the Internet should be hidden behind a wall like requiring Javascript; but I do think that some of the capabilities of web-based applications don't have a direct analog to HTML/HTTP/server, or can't be implemented that way in a reasonably acceptable way. As an example, web-based video can definitely be implemented without client-side scripting; but web-based video editing cannot (within users' perfectly reasonable expectations). You might say that this latter category ought not be implemented in the browser in the first place, but for better or worse you're fighting a trend that's probably not going to die any time soon.
Re:Not suprising (Score:3, Interesting)
the official claim was that IE8 fully supports CSS 2.1
Unfortunately, the other official claim at the time was that IE prioritizes interoperability over standards compliance, and the two claims together did not jibe. I've encountered far too many instances where IE 8 was correct and the competitors were correct also, except the standard allowed for differences of interpretation and IE 8 alone took different interpretations.
Moreover, IE 8's biggest gaping hole was not its HTML or CSS support, nor even some of its oddities in ECMAScript, but its utterly disfigured DOM implementation, largely unchanged from IE 6 (if not earlier). There are so many analogous-but-slightly-different IEisms in the DOM that huge general-purpose libraries are necessary for most developers to do anything useful on the client-side that isn't missing core features in one implementation or the other.
I haven't seen much from MS about IE 9's DOM improvements, and I'm kind of scared to find out if it's still being hung out to dry. My hope is that, while their public projection of "HTML5" is far too broad to be meaningful, their internal priority does include true HTML5 compliance, which will standardize the DOM.