Slashdot Mirror
W3C Says IE9 Is Currently the Most HTML5 Compatible Browser
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.'"
Thats why it used to be referred to as a recommendation, instead of standard (lots of discussions around it, though i think the likes of ISO and whatsnot now consider W3C stuff as actual standards).
That said, if you ever tried to implement anything from the W3C, its full of holes, inconsistencies, ambiguous parts, things "left to the implementator", and all around, Microsoft's OOXML may have been a lousy ISO standard, but it sure would fit right in anything the W3C ever published.
The only reason it kindda works, and that so many browsers seem to implement it, is because the likes of those working on Firefox, Safari, etc, kind of agree on stuff they don't like or the standard doesn't dictate. That also makes IE8 look worse than it actually is (not that its not awful, but in a few (very few) cases web developers will complain about things on which IE8 is actually right, and Firefox is wrong, but Safari, and Chrome are wrong the same way).
Its not just HTML/CSS/whatever. The XQuery specs for example, are just as bad.
Not only that, but I think at least one of the features they're testing is a former IE-ism that's been standardised, and the other browsers have prioritized HTML5 features like local storage that aren't tested here at all.
The "released" browsers are:
Google Chrome 7.0.517.41 beta
Firefox 4 Beta 6
Opera 11.00 alpha (build 1029)
Safari Version 5.0.2 (6533.18.5)
The only one which doesn't have "beta" or even "alpha" in its name is Safari. So probably that one is actually released.
The Tao of math: The numbers you can count are not the real numbers.
On Snow Leopard, yes. FireFox uses the platform's native text rendering engine. Safari uses Apple's one wherever it runs. This means that you get Apple's sub-pixel AA instead of Microsoft's ClearType on Windows.
You also get some slightly different glyph positioning. Microsoft tweaks glyph positions by a fraction of a pixel to make them line up more closely with pixel boundaries. This makes individual characters clearer, but means that the spacing between characters looks a bit messed up. Apple renders glyphs exactly where they should be, which means that they often overlap pixel boundaries and need a lot of antialiasing.
If you're used to Microsoft's rendering, Apple's text will look slightly blurry. If you're used to Apple's rendering, Microsoft's will look weirdly spaced.
I am TheRaven on Soylent News
That's probably because Firefox supports fractional font sizes: 12.1px, 12.3px, 12.5px...
Every other lunkheaded browser rounds to the nearest whole pixel value. If the site developers use relative font sizes (ems, percents) and don't do precise math, the site ends up with a declared pixel size between values...and only Firefox delivers the declared size.
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, it means Firefox more often than not looks "wrong," because it's far enough ahead of the curve to be out front alone.
It's Office Open XML. Stop trying to pollute the good name of OpenOffice.
Did you try disabling the Win7 firewall rules? My guess is the client does active FTP and that is where the problem is.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Um no, it really doesn't "remain to be seen" at all. The very first preview of IE9 (10 months ago, now) had CSS rounded corners, for example.
You could always try out the tests on http://ie.microsoft.com/testdrive/Default.html in your browser of choice. They all work on IE9, and usually better (faster, smoother, or without layout issues) than on other browsers. All browsers, even IE8, can do some of the stuff there, but all other browsers have issues with some parts.
That's not to say IE9 doesn't still have issues with soem things that other browsers do fine, because it does. For example, I don't think it has WebSockets. However, it's still not only a huge step up from earlier versions, it's also better than its competitors in many areas.
There's no place I could be, since I've found Serenity...
If you're used to Microsoft's rendering, Apple's text will look slightly blurry. If you're used to Apple's rendering, Microsoft's will look weirdly spaced.
As a Linux user, Apple fonts look blurry; Microsoft fonts (AA'd or not) look like jagged crags of ugly (very difficult to read, at times - see the powershell font).
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Safari uses Apple's one wherever it runs. This means that you get Apple's sub-pixel AA instead of Microsoft's ClearType on Windows.
This used to be the case, but for a while now Safari for Windows gives you the choice between OS stock rendering, and Apple's fonts.
Microsoft tweaks glyph positions by a fraction of a pixel to make them line up more closely with pixel boundaries. This makes individual characters clearer, but means that the spacing between characters looks a bit messed up. Apple renders glyphs exactly where they should be, which means that they often overlap pixel boundaries and need a lot of antialiasing.
To be more specific, ClearType tweaks glyphs such that vertical lines are snapped to pixel boundaries - so a 1px vertical line is rendered using a single-pixel-wide column of physical pixels. On OS X, the same 1px vertical line can end up on fractional coordinates (e.g. at X=8.5px), and will be rendered using double-pixel-wide column of physical pixels to approximate that. The result is more blurry.
This is particularly noticeable on small fonts with thin elements, such as Windows system fonts Tahoma 8pt (in 2K/XP) and Segoe 9pt (in Vista/7). It's also why OS X default font is larger, and the stems are thicker.
The disadvantage with ClearType approach is not just "weird spacing", though. It distorts the overall size of the text by its adjustments. Normally, if you increase the point size twice, the physical size in pixels should also increase by exact same amount (+/-1px due to need to round to physical pixel boundary). OS X rendering actually guarantees that. On Windows, text rendered using small fonts is noticeably (by 20% or so) larger than it would be if "perfect rendering" was used, and so proportion is not maintained.
Which one is better is highly subjective, and more often than not the preference is defined by what the person was using before. Personally, I can't stand OS X rendering and love ClearType. I've met people who felt just as strong in the other direction.
It's all a bit complicated. Let me try to explain.
First of all, VS2010 does indeed use WPF 4, though not for all UI elements (it was not a grounds-up rewrite). But text editor is fully WPF, and so are menus and toolbars. Tool windows may or may not be on a case-by-case basis.
WPF 4, unlike previous versions, does use DirectWrite when available. This is indeed the same technology that IE uses, and it provides for "perfect rendering", where font glyphs are not snapped to vertical pixel boundaries, and therefore proper text size is maintained without distortion. It should be noted, though, that even past WPF versions used the same kind of rendering, though they had their own text layout engine.
Now, DirectWrite actually has a flag which disables "perfect rendering" and enables pixel-snapping for fonts, with the result being not pixel-by-pixel identical to the traditional GDI ClearType, but pretty close to it. WPF 4 exposes it as a property on all widgets.
VS2010 beta 2 actually used the "perfect" rendering, and there were a lot of user complaints about text being blurry etc. This MS Connect ticket (which I had created, though the problem was reported long before on various forums and blogs) summarizes the issue Consequently, WPF added the aforementioned property, and it was used from VS2010 RC to enable ClearType-style rendering for all windows in the application.
From what I've seen in IE9 beta, they use DirectWrite, but they do not use that same flag. So their rendering is different from what you see in VS2010, and specifically more blurry. I wonder if they'll end up going through the same change by the time they release - I've actually suggested that they do so.
If you want pixel perfect rendering of fonts and graphics, use PDF or a related technology. The whole idea behind HTML is that the content can be rendered differently on different devices. As such, a proper design should never rely on exact font sizes.
They compared IE9 against both Opera 11 Alpha and Firefox 4 Beta 6.