As you may know, all browsers have a set of CSS features that are either considered a vendor extension (e.g. -ms-interpolation-mode), are partial implementations of properties that are fully defined in the CSS specifications, or are implementation of properties that exist in the CSS specifications, but aren’t completely defined. According to the CSS 2.1 Specification, any of the properties that fall under the categories listed previously must have a vendor specific prefix, such as '-ms-' for Microsoft, '-moz-' for Mozilla, '-o-' for Opera, and so on.
ms-interpolation-mode
'-ms-'
'-moz-'
'-o-'
As part of our plan to reach full CSS 2.1 compliance with Internet Explorer 8, we have decided to place all properties that fulfill one of the following conditions behind the '-ms-' prefix:
This change applies to the following properties, and therefore they should all be prefixed with '-ms-' when writing pages for Internet Explorer 8 (please note that if Internet Explorer 8 users are viewing your site in Compatibility View, they will see your page exactly as it would have been rendered in Internet Explorer 7, and in that case the prefix is neither needed nor acknowledged by the parser):
We understand the work involved in going back to pages you have already written and adding properties with the '-ms-' prefix, but we highly encourage you to do so in order for your page to be written in as compliant a manner as possible. However, in order to ease the transition, the non-prefixed versions of properties that existed in Internet Explorer 7, though considered deprecated, will continue to function in Internet Explorer 8.
Unfortunately, the original filter syntax was not CSS 2.1 compliant. For example, the equals sign, the colon, and the commas (highlighted in red) are illegal in the following context:
filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=80, FinishOpacity=70, Style=2);
Since our CSS parser has been re-designed to comply with standards, the old filter syntax will be ignored as it should according to the CSS Specification. Therefore, it is now required that the defined filter is fully quoted. The proper way of writing out the filter defined above (with changes needed highlighted in green) would be:
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80, FinishOpacity=70, Style=2)";
-ms-
filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80, FinishOpacity=70, Style=2)";
In order to guarantee that users of both Internet Explorer 7 and 8 experience the filter, you can include both syntaxes listed above. Due to a peculiarity in our parser, you need to include the updated syntax first before the older syntax in order for the filter to work properly in Compatibility View (This is a known bug and will be fixed upon final release of IE8). Here is a CSS stylesheet example:
#transparentDiv { -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50); opacity: .5; }
#transparentDiv {
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);
opacity: .5;
}
Thanks for your time and we are glad to hear your feedback!
Harel M. Williams Program Manager
edit: modified header
PingBack from http://www.easycoded.com/microsoft-css-vendor-extensions/
Just as I was asking Matt Heller yesterday at IE8 Roadshow we had in Christchurch NZ about this. Boom today, we have the answer to one of my question. Good to see that we developer can at least get the site CSS ready for CSS 3 using vendor-CSS-properties just like on Mozilla and Safari.
Kudos.
Now... why not separate the XHTML/CSS rendering engine from the core code and update that more regularly with Windows Updates etc without having to rebuild the whole IE, and wait for the next 18-months launch... many micro updates is far better than one big product launch. :-D
Well done Microsoft!
It's great to see that IE is progressing towards being a more "friendly" internet neighbour.
Now we can finally diminish all the IE specific CSS properties to conditional comments which will make it far easier to get a valid CSS certification.
Also thanks for mentioning the changes to -ms-filter: this needs to be spread around the blog-o-sphere as the broken filters were a concern for a lot of people.
Hopefully they have also refelcted these changes in the MSDN docs for IE.
Yeah. More broken websites in the name of "standards!" So essentially, I need to update all of my websites from overflow-y to -ms-overflow-y. But I can't remove the overflow-y because IE6 and IE7 need that. Then of course when IE8.1 or IE9 (whatever is next) comes around and supports CSS3, I need to revert back to overflow-y because now it will be standardized. But I can't remove -ms-overflow-y because IE8 needs it. Essentially, this change guarantees that websites will NOT be standards compliant for years! If you just leave it at overflow-y maybe people will complain until CSS3 is standardized, but at least after that the madness ends rather than just continuing for years to come.
@dman.... read the post again since you overlooked one important sentence:
"However, in order to ease the transition, the non-prefixed versions of properties that existed in Internet Explorer 7, though considered deprecated, will continue to function in Internet Explorer 8."
So I take it from the last example that we can't just expect "opacity" support in IE8?
@dman: Read the text again..
This is precisely the right road to take. Well done!
The new tabs look so smooth and clean but when you select it the dotted line just makes it all ugly. Could you remove the dotted rectangle line that surrounds the tabs when selected? sometimes it would show up randomly and i think it should be remove completely.
Since some CSS properties are deprecated but still available in IE 8. Isn't this going to make broken pages last longer on the web and keep web pages non standard for a longer time ? Is there any way (in the Developer tools ?) to make programmers aware of what is deprecated in their web pages ? I would like to know very quickly what in my website is up to date and what needs update without fully read MSDN documentation.
This is mainly good, but bad for things which are already covered by most others without the prefix. I would vote for keeping:
"background-position-x"
"background-position-y"
"overflow-x"
"overflow-y"
"text-overflow"
These are IMHO the most prominent ones which are most widely used already without any prefix. A common between all browsers should be seen as required here. I could also live when more nearly final things from the Working Drafts are used without a prefix.
@wayhi : I think the IE team kept it because it helps people control the browser with the keyboard (using tab, the focus is where the dotted square is) and might also be useful for disabled people. Though, I agree the look is not very polished. In the same way, when you select an image, selection is a "checkerboard" of blue and transparent dots, which does not offer a very polished look either.
Finally! Congratulations for this advance.
I second others' thoughts: there should be a way through Developer Tools to quickly be alerted about deprecated properties: we don't want them to stay around for the next decade, right?
And please, like others suggested, consider updating Trident independently of IE in the future. CSS3 really needs to be pushed forward and this can't happen until implementations do not appear.
@Ben Hollis: That is correct, opacity is not currently supported. We wish it was as simple as mapping the opacity property to our Alpha filter, but unfortunately our Alpha filter does not entirely match up with the opacity property described in the CSS3 specification and, by extension, other browser implementations.
Half good, half bad, again...
It's nice that you decided to follow the prefix convention (at last!), however... you still use filter rather than opacity ("opacity" must be some kind of ongoing private joke at the IE team, I guess), and add a needless prefix for stable and widely implemented properties, such as overflow-x and y, already supported as is by all browsers.
This is very great news! Well done! And as Leith Bade says this has really been a concern for a lot of people.
About interacting with the filters from javascript, is there any changes in that?