IE 8 and vendor prefixes
I haven’t been posting much lately, since I’ve been focusing on actually getting things done, but I wanted to point out what I think is a very good decision from Microsoft that seems to show they’re really serious about standards.
Historically, CSS property vendor prefixes (-moz-, -o-, -khtml-, -ms-, …) have generally been used for properties that either aren’t part of a current CSS standard or are part of a current standard but only have experimental support by the browser. But most browsers have made exceptions to these rules depending on how common the non-prefixed versions are on the Web.
Microsoft has announced that they are taking a clear-cut approach to this topic and will always follow these convention rules. In Internet Explorer 8, webpages invoking the best standards mode (default) will be required to add an -ms- prefix to vendor-specific properties like filter, scrollbar-base-color, and zoom, as well as non-finalized CSS 3 features like background-position-x, overflow-x, and word-wrap.
Microsoft claims that every CSS 2.1 property will be considered supported, so no CSS 2.1 property will require a vendor prefix.
Now, here’s why I think this decision is so significant: Asking a browser to always follow the vendor prefix conventions is a picky request. An unreasonable request, some might say. I’ve argued about this subject a number of times in the past, and I’m usually dismissed as a silly idealist for wanting browsers to deliberately break support for current websites just to follow a convention with fairly hard-to-see benefits.
Most people don’t know or care that breaking the convention introduces possible complications for the development of future standards. They just want to see the “Passed Validation!” message in CSS 3 mode. They’re more concerned with the short term issues of getting all the lights to turn green than the long term issues of the growth and stability of sound web standards.
Microsoft’s decision makes some short-term sacrifices for the interest of the long term health of the Web, and it’s on an issue that even many standards advocates would consider picky. Well, I for one am thrilled to see Microsoft getting “picky” about the quality of their standards support.
Update 2008-09-09: I should clarify that the non-prefixed properties that were supported in IE 7 will continue to be supported in IE 8, with or without the prefix. But Microsoft considers the non-prefixed versions deprecated, and they may be removed in a future version.
The exception is the filter property, which will not work in IE 8 standards mode without the prefix. This is because the original filter syntax didn’t comply with CSS’s grammar rules and will thus be ignored in IE 8’s improved CSS parser. If you have to continue using the filter property, you need to include the prefix and put quotes around the property value. For compatibility with older versions of IE, you’ll need to write the filter both ways.
September 12th, 2008 at 06:28 UTC
Will you be starting testing for completing your compatiblity tables to include IE8 or will you wait untill the final version is released.
Posted using Internet Explorer (Windows) 8.0 on Windows.
September 12th, 2008 at 14:28 UTC
I always wait until the developers announce that the platform development is done.
Posted using Mozilla Firefox 3.0.1 on Linux.
September 12th, 2008 at 14:44 UTC
Great step imho, but there are some drawbacks:
First, they should’ve removed filters entirely. A -ms-opacity (who uses the other filters anyway?) would’ve been the right idea.
Also, I don’t think it was a good idea to add -ms-overflow-(x|y), the standard properties are implemented in all browsers, so there was no need for them.
Anyway, the second Beta looks great and most big sites (those that don’t use the meta tag) got no problems at all.
Posted using Mozilla Firefox 3.0.1 on Windows.
September 15th, 2008 at 09:06 UTC
@Daniel: the CSS3 implementation of overflow-x|y isn’t completely identical among developers. MS probably chose to rename it in order to have:
– standards-based implementation using proper name
– their legacy variant using the prefix
– currently, the property and its suffixed version match, it’s not guaranteed to stay the case
Having tested it, I agree that CSS 2.1 support in IE 8 is impressive: it actually is better than most other browsers out there, and may actually beat Firefox (which still hasn’t implemented 2.1’s finest points over 2.0 yet) and Opera.
That leaves CSS3, though.
Now, if they could actually fix their event model to make using these CSS 2.1 features actually useful (CSS pseudoframes and events don’t mix – scrolling is reset on many events)…
Posted using Mozilla Firefox 3.0.1 on Linux.
September 19th, 2008 at 14:44 UTC
@Mitch 74:
You’re probably right there.
About CSS 2.1, it’s indeed impressive. Well, they promised to support it 100% which the other’s have not reached yet as well (Firefox is only missing run-in boxes and some print properties). If you count bugs, than border-collapse is another point that IE8 better than the others.
I think this is great, CSS 2.1 itself will improve by this implementation and the serious work on CSS 3 modules also restarted this year.
However, not everything is great. We won’t see any great steps forward in the DOM department, I hope they promise 100% DOM 2 support in IE9.
Posted using Mozilla Firefox 3.0.1 on Windows.
September 22nd, 2008 at 15:09 UTC
Microsoft actually hasn’t committed to 100% CSS 2.1 support by IE 8. As far as I know, they’ve just committed to offering support for all CSS 2.1 properties and selectors. I don’t think they’ve committed to supporting all property values, and it will definitely have bugs and other shortcomings, as all browsers have. So there’s still quite a bit of wiggle room.
Whether or not IE 8 will be up to scratch with Firefox, Safari, and Opera in CSS 2.1 support is yet to be seen. But it seems clear that IE 8 will have a ton of progress, and I think it will finally become what I consider a “modern” browser.
Posted using Mozilla Firefox 3.0.1 on Linux.
September 23rd, 2008 at 09:56 UTC
@Daniel: to promise DOM2 support in IE 9 would require a complete rewrite of the event object – which has sat practically untouched for 10 years (the last major revision was for IE 5, in Windows 98).
There are, however, a few improvements such as ‘better’ static DOM handling:
– BUTTON doesn’t take its innerHTML as value, and default action is SUBMIT
– setAttribute, getAttribute, hasAttribute now work properly
– getElementById matches only ID
– it has a REAL debugger, strongly inspired by Firebug, making IE debugging actually EASY (before, you had to guess what got IE’s pants in a knot, now you know – so you can insult IE sooner, making the accumulation of venom less likely)
@David: you’re right in what they’ve committed to; it also happens that some parts of CSS 2.1 are not very well applied by current browsers and their bugs weren’t caught before because of plain lack of use. There are also some inconsistencies and dark areas in the spec, that weren’t actually discussed until now. The large panel of test cases provided by MS, regardless of their actual quality in implementation, may just help right there.
It’s too bad Acid3 focused so much on Javascript, DOM and SVG, because it would have helped a lot in refining the CSS 2.1 specs.
Posted using Mozilla Firefox 3.0.1 on Linux.
September 26th, 2008 at 15:50 UTC
@David: I guess you’re right. However, I still think I’ve seen someone from the team comitting to this goal. I really should save such thing somewhere..
Anyway, their implementation is pretty good, as you said, so I don’t think IE will make CSS problems anymore. Most modern websites I’ve tried had none or few problems to be rendered in IE, even without X-UA-Compatible or Hacks.
@Mitch: The DOM work in IE 8 is about the CSS work in IE 7. I’d say, DOM in IE 7/8 is broken as much as CSS was in IE 6 and 7. And the developers came pretty far in those two years.
I don’t think they’ll have problems to update their DOM support greatly for IE 9.
Besides, Acid 3 contains lot of CSS 2.1 but most of it is already implemented. There’s nothing about display: run-in or border-collapsed tables; The latter seems to be left out intentionally. CSS 2.1 isn’t cler enough and at least Mozilla is going to wait for the CSS 3 Tables Module. I heard rumors that this module will be created by Microsoft representatives after IE 8 is finished.
Posted using Mozilla Firefox 3.0.2 on Windows.
September 30th, 2008 at 09:12 UTC
@Daniel: improving DOM support opens a whole new bag of nasties, as it hits directly where it hurts: scripts.
Correcting the CSS was relatively easy: with many websites still being table based, the majority of all websites remained functional if ugly. If you try to improve DOM support, stuff like white spaces not being taken into account in DOM, two ‘event’ objects and some other not-quite-standard-but-it-seemed-like-a-good-idea-at-the-time stuff will, this time, make websites go boom.
Now, this would probably be greatly mitigated by Firefox’s market share having forced most websites to correct these shortcomings; but, we still have one bad thing remaining:
IE6, and its DOM support, will be supported until 2014. Yeugh.
The way I see it, the only way to really get DOM support upgrades from MS would be if next WinXP (and Vista) SP contained a DOM-corrected browser. Or we’re in for another metatag switch.
Posted using Mozilla Firefox 3.0.3 on Linux.
October 3rd, 2008 at 12:09 UTC
@Mitch: You’re right. Changes to the DOM of IE will cause much trouble. However, I think you fail to see that even the CSS changes to IE 7 caused much trouble. Besides, table layouts weren’t that common these days anymore.
The web – or at least some other factors – made Microsoft to enable IE8’s Standards Mode to be the default. That’ll cause much trouble again, though it’ll be slightly mitigated by their meta madness. the devs stated that they prefer not to add another mode but they could if they wanted.
Even if they do, the web or at least those other factors will make IE9’s Standards Mode the default again. Meta mitigates (the meta tag is made forward compatible for such cases).
It’s true, that Microsoft can’t remove things like
document.allanymore, but fixing the DOM is possible. If IE 9 wouldn’t include a major DOM overhaul, it would be its end.BTW, it looks like Win7 may come out next year. It’ll include IE8. Since many companies don’t like Vista this could be the needed boost to finally eradicate IE 6.
Posted using Mozilla Firefox 3.0.3 on Windows.
October 21st, 2008 at 09:31 UTC
@Daniel: you mean, migration path away from WinXP?
*Mitch has a dream sequence with bids chirping, cute animals frolicking in a field by a fresh, sunny morning… and one single properly validated CSS file for his whole website, for all browsers)*
I however disagree with you on what would actually happen on a DOM overhaul for IE: while correcting CSS support in IE 7 did bring corrupted pages, one could still use workarounds to navigate:
– scrolling to deal with f*ed up boxes resizing in an unexpected way
– tabbing to deal with f*ed up z-index boxes overlapping
And quite rarely, a browser crash (CSS intensive sites dealing with IE 6 idiosyncrasies could trigger some bugs in IE 7).
However, DOM support may produce the following:
– older page detects an Internet Explorer (through UA sniffing MOZILLA/4.0 + MSIE, for example): it loads IE-specific code for IE 9. It fails.
– recent page uses standard dynamic DOM for all browsers, user still has WinXP with IE 6, 7 or 8: page won’t load (currently, IE can’t deal with DOM modifications before what other browsers call “DOMContentLoaded”)
Meaning that IE 9 correcting its DOM support will lead to a lot of sniffers rewrite.
That is, provided IE 9’s DOM support matches other browsers’ (which aren’t identical either, although tests like Acid3 actually helped).
Posted using Mozilla Firefox 3.0.3 on Linux.
October 24th, 2008 at 16:04 UTC
@Mitch: Indeed. And that dream will come true anywhere from mid to long-term.
Hm, actually I think we can’t diagree with each other. We just see the situation from a differen perspective.
The current situation simply is, that modern browser are close to each other, while IE is far away from them. If IE doesn’t move, it’s bad for the web (and its standards). If IE moves, there’ll be a big loss of backwards compatability.
Both are no good, but given the current situation it makes more sense for IE to move.
Besides, IE includes both user and developer contolled functions to mitigate the worst-case scenario (a site that can’t be handeled). What to think about these functions is a different story.
Posted using Mozilla Firefox 3.0.3 on Windows.
January 8th, 2009 at 23:37 UTC
You should update this blog more, it’s really fantastic stuff when you do.
Posted using Mozilla Firefox 3.0.5 on Windows.