Microsoft CSS Vendor Extensions


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.

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:

  • If the property is a Microsoft extension (not defined in a CSS specification/module)
  • If the property is part of a CSS specification or module that hasn’t received Candidate Recommendation status from the W3C
  • If the property is a partial implementation of a property that is defined in a CSS specification or module

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):

Property Type W3C Status
-ms-accelerator Extension  
-ms-background-position-x CSS3 Working Draft
-ms-background-position-y CSS3 Working Draft
-ms-behavior Extension  
-ms-block-progression CSS3 Editor’s Draft
-ms-filter Extension  
-ms-ime-mode Extension  
-ms-layout-grid CSS3 Editor’s Draft
-ms-layout-grid-char CSS3 Editor’s Draft
-ms-layout-grid-line CSS3 Editor’s Draft
-ms-layout-grid-mode CSS3 Editor’s Draft
-ms-layout-grid-type CSS3 Editor’s Draft
-ms-line-break CSS3 Working Draft
-ms-line-grid-mode CSS3 Editor’s Draft
-ms-interpolation-mode Extension  
-ms-overflow-x CSS3 Working Draft
-ms-overflow-y CSS3 Working Draft
-ms-scrollbar-3dlight-color Extension  
-ms-scrollbar-arrow-color Extension  
-ms-scrollbar-base-color Extension  
-ms-scrollbar-darkshadow-color Extension  
-ms-scrollbar-face-color Extension  
-ms-scrollbar-highlight-color Extension  
-ms-scrollbar-shadow-color Extension  
-ms-scrollbar-track-color Extension  
-ms-text-align-last CSS3 Working Draft
-ms-text-autospace CSS3 Working Draft
-ms-text-justify CSS3 Working Draft
-ms-text-kashida-space CSS3 Working Draft
-ms-text-overflow CSS3 Working Draft
-ms-text-underline-position Extension  
-ms-word-break CSS3 Working Draft
-ms-word-wrap CSS3 Working Draft
-ms-writing-mode CSS3 Editor’s Draft
-ms-zoom Extension  

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.

Changes in the filter property syntax

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)";

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;
}

Thanks for your time and we are glad to hear your feedback!

Harel M. Williams
Program Manager

edit: modified header

Comments (78)

  1. Kelvin Yong says:

    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. ๐Ÿ˜€

  2. Leith Bade says:

    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.

  3. dman says:

    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.

  4. -TNO- says:

    @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."

  5. Ben Hollis says:

    So I take it from the last example that we can’t just expect "opacity" support in IE8?

  6. erlando says:

    @dman: Read the text again..

    This is precisely the right road to take. Well done!

  7. wayhi says:

    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.

  8. Joss says:

    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.

  9. 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.

  10. Joss says:

    @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.

  11. LorenzoDV says:

    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.

  12. Harel M. Williams [MSFT] says:

    @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.

  13. Stifu says:

    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.

  14. Esben2000 says:

    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?

  15. Joe Chung says:

    #transparentDiv {

       -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

       filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);

       opacity: .5;

    }

    FFS, WTF is this?  Are you all daft?

  16. Lenen says:

    It’s nice there finally is a standard for this, but it’s really a lot of work to change old CSS files to this new standard.

    Eventhough i’m glad you guys finally finished this!

  17. Pete B says:

    Looks like a pain in the head.

    For some of those properties with the prefix are supported in other browsers without the prefix. You say they will still work without the prefix in IE8, Great, so then all old pages will break in IE9 instead. To be forward compatible we need to double up our code declarations just because you love to do your own thing in spite of what all the other browsers are doing.

    And, implementing opacity… what a mess! Just support a regular opacity property like every other browser. It’s hideous.

  18. Hey guys, it seems to me that prefixing overflow-x and overflow-y is a mistake as all browsers support those universally now. It would be annoying for authors if they have to use special syntax just for Internet Explorer. I assume this can still be undone?

  19. Stifu says:

    Anne van Kesteren: the prefix-less version will still work. However, this adds unneeded confusion… Some web beginners may even only use the -ms version only and not the normal one, so things would only work right with IE8.

  20. Askilla says:

    Great, even more code to write and maintain. Isn’t this a step in the wrong direction? Wouldn’t it be better to rid IE8 of all things MS-specific? Same goes for other browsers and their proprietary properties, btw.

  21. Annoyed of Grumbleton says:

    Sheesh.

    Its great to see how stupid many web developers truly are.

    "IE MUST be standards compliant!" Your all cry.

    MS do there best to do so.

    "Hey!  No one else follows that standard for overflow-x, why the hell are you?"

    MS just shudder and sigh.  There really is no pleasing some people.

    In other words… its OK to ignore standards as long as <insert favourite browser here> also does?

    Get a grip people and complain to the other browser manufacturers.  IE still has the dominant percentage of normal web users, so go figure where your complaints should really lie from this point on…

  22. Mitch 74 says:

    Errr… Wow. Cool. No, really!

    Ideally, the proprietary implementation should go sooner or later to make room for the standard one; in the case of opacity, as the syntaxes are completely incompatible, it’s not really a problem ("filter:opacity" can still exist; it will result in an error, that’s it, and both can be defined in a document without interference: last matching rule defined is kept).

    If an "-ms-opacity" property appears, and finally "opacity" ends up different than in current draft (unlikely, but possible since "opacity" is also defined slightly differently in SVG and could change again to match), what happens?

    – is -ms-opacity discarded and opacity kept? (intended behavior)

    – is -ms-opacity an alias for opacity, even if opacity ends up slightly different? (may hurt more than above, but may allow designs to not be completely broken up)

    – is -ms-opacity kept as-is and opacity implements the newer version? (not recommended, but allows some backward compatibility)

    I guess the approach may vary depending on how different the proprietary version is from the final one, but it would help in making a decision.

  23. Mitch 74 says:

    As far as I know, overflow-x and -y actually fall into the "created by a browser vendor, implemented by others, thus integrated into standards as a de-facto one" – as such, they are already supported as-is by IE, Firefox 1.5+, Opera 9.5, and Konqueror/Safari.

    If you already have overflow-x and -y somewhere in your code, don’t change it; just know that they are also accessible through the proprietary alias (see my above comment for possible use of the alias for compatibility reasons).

    Of course, it would arguably be better to extend the "overflow" property to accept two parameters (say, overflow: auto hidden being equivalent to overflow-y: hidden) – but then, it would require so much code rewriting and so much trouble that, well, it ain’t practical.

  24. zardoz says:

    Well this is a start. Well done.

    Please remember: Standards, community standards is all we’ve got

  25. Ivan says:

    I agree with IE team that proprietary property names should be vendor specific e.g.: -ms-filter instead of filter etc.

    I agree that new implementations should be also vendor-prefixed e.g.: -ms-border-radius (I know it’s not implemented).

    How ever, I do not agree, like some of you, that existing implementations should be vendor-prefixed e.g.: -ms-overflow-x / y. Moreover since both syntax are supported, why should I use -ms prefix in the first place? The normal syntax is gonna be fully supported in the next version of IE anyway… or hopefully it will be suported.

    Indeed it adds counfusion among developers.

    Thumbs up for the new implementations. And thumbs up for keeping the existing standard implementations without -ms prefix.

    I suppose this will bring some discussion during the upcoming Fronteers conference.

  26. JAB Creations says:

    1.) This is a completely positive move in the correct direction which I fully and enthusiastically applaud!

    2.) I’m slightly disappointed not to see critical properties support (border-radius, multiple background-image support, multi-column support, and resize in example) though I presume we’ll see support for these in IE9.

    3.) Proprietary implementation is pure genius in ***THIS*** sense because it gives us ***SOME*** support in contrast to no support. Microsoft has made it clear that with their large number of test cases that CSS 2.1 leaves so much in question that browser vendors are clearly going to end up implementing different behaviors. By sticking to a proprietary implementation they will not support a feature when it’s called in CSS by standard versus supporting it incorrectly (thus introducing headache inducing issues for web designers).

    4.) Implementing this per version of IE is a snap, conditional comments.

    5.) Any one who complained on this blog post has proven to me that they sorely lack in critical real-world understanding of how to balance features and standards.

    6.) I welcome Microsoft to introduce their own in-house proprietary ideas through the -ms- prefix. I recall favicons in example were introduced by Microsoft and my bookmarks toolbar in Firefox and links toolbar in IE use mostly just favicon only bookmarks/favorites. Of course I would recommend minimizing such features to concentrate on standards though that does not mean Microsoft can’t still introduce some interesting features that could one day be implemented in to one standard or another.

    Thanks for the great post!

  27. snark says:

    Congratulations on doing the right thing.

  28. Adlib says:

    Heading in the right direction – excellent!

    Glad to see Filters back, and I understand the need to "quote" the filter content for the re-designed CSS parser.  However the filter syntax example given above is quite lengthy:

    #transparentDiv {

          -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

          filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);

          opacity: .5;

    }

    Will the current shorthand version used by existing web pages targeting IE6/7 continue to work in IE8? i.e.

    #transparentDiv {

          -ms-filter: "alpha(opacity=50)";

          filter: alpha(opacity=50);

          opacity: .5;

    }

    In other words, can we still continue to omit the "progid:DXImageTransform.Microsoft" part?  

    Of course it would be even better if there was time to implement an opacity or -ms-opacity property that matches the CSS3 Draft in IE8 final.  IE8.1 perhaps?

  29. Chris Poteet says:

    Yes, I don’t understand why in the world you would make properties such as overflow-x/y, etc to use a -ms prefix.  It still doesn’t make sense to me.  That seems to be a move backwards especially if later down the line you’ll remove them only when the CSS3 spec is "finally" made a spec (which I’m confused on whether it ever will).

    Have the ms specific styles using filters is fine, but anything in a standard or recommendation is better to implement as specified.

  30. oh no you ruined it says:

    Are you serious?

    Why did you have to go and mess up opacity?

    just have:

    -ms-opacity:.5;

    Point internally to:

    -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

    I seriously have no desire in adding 65 characters to my CSS file to declare a transparency value.  This is silly.

    15 characters vs. 65

    IE8 65 characters (over 4 times as big!)

    IE7 25 characters

    IE6 25 characters

    All other browsers:

    15 characters

    I was really happy with this post and the last, until I saw this botch.

    Speaking of botches, will IE8 be fixed to not render opacity as 0%, when it encounters filter syntax that was added just to satisfy your old non-standards browser?

    I also agree with Chris, the overflow-x, and overflow-y properties are just fine, please don’t try to fix what isn’t broken.  IE6 is the only browser that can’t handle the overflow-[x/y] please don’t make IE8 step backwards to re-support what it already supported.

  31. developer says:

    uhm what? I’m sorry but these two in particular

    -ms-overflow-x

    -ms-overflow-y

    qualify as a LOGICAL FAIL

  32. Stifu says:

    oh no you ruined it: if memory serves, overflow-x and y DO work in IE6, actually. Make sure to test in "strict" mode…

  33. Will Peavy says:

    Prepending a vendor specific notation to selectors that have not yet reach recommendation status, while fully supporting the latest recommendation, is an ideal and standards-friendly solution. I think MS has done the right thing here. Good job guys.

  34. pd says:

    First a genuine standards mode, then (belatedly) turning the standards mode on by default (except for intranets), the showing every sign of building a decent Firebug clone, now proper compliance with the CSS vendor-specific prefix!

    At this rate, if you guys aren’t careful, you might start to get a few people just quietly wondering if you’ve dreamed of turning into good citizens.

    What is next, a rapid deployment of IE8 to finally rid us web developers of the IE6/7 nightmares?

    A web where Microsoft plays well with others? What is the world coming to? Feels like we’re entering some sort of twilight zone (queue music). What’s next, an American president with a brain?

  35. I think that the ideas offered by Microsoft are very good. Unfortunately, there exist many browsers. I think that new elements must be coordinated with other producers of browsers, because it is very difficult to software companies to develop web sites for each browser.

  36. Donny V says:

    Thanks guys!!!

    This makes my life a lot easier.

  37. stan says:

    IE Developer Toolbar Bug:

    The developer tools for IE, has a bug in the menu where the menu header doesn’t change to white text on a dark blue background (default XP theme), but stays as black text on a dark blue background thus making it very hard to read.

  38. maxwell says:

    Does anyone else find that in IE8 standards mode setting the height attribute (or style) on a td cell to "100%" has little to no effect?

    I realize that this may not concern those working with divs but since many of us laid out our markup based on what IE could render in the past, we now find ourselves at an odd conflict trying to handle things like this.

    Regardless, for data tables I still think this is entirely still very relevant.

    The basic issue is that the content of the cell, with 100% height (or a fixed height) doesn’t "push" the cell to be larger if overflow-y (or now -ms-overflow-y) is set to auto.

  39. Jezie says:

    In the new tab page the text link under the Use an Accelerator would not show and sometimes it has been cut off.

    Tabs doesn’t ungroup when moving to another website.

  40. Jezie says:

    Did you guys forget to add middle click to open new tab in smart address bar? In IE 8 Beta 2 I can’t middle click the favorite link in smart address bar to open website in a new tab.

  41. Gyrobo says:

    I’ve written a small example to test (-ms-)overflow-x/y, as well as -ms-filter:"alpha(opacity=50)"

    http://databathing.com/tests/msPrefixExample.html

    Although, since you’re changing the basic syntax of the filter property, why not add a shorthand specifically for opacity, like -ms-filter:"opacity=x"? It’s not like you’d be violating a spec…

  42. Joss says:

    Geez ! Many of you are complaning about this change. However, please note that standards are made by browser editors, and they agreed in this change. If you do not like it, don’t blame IE, start blaming W3C !

    If some other browsers are not using the same technique, it means that they are not standard compliants : ask other browsers to fix their code.

    At least some developpers will start seeing that following the standards solves the compatibility problem at one point but it does not solve the compatibility problems **over time**. Compatibility problems are not over because IE is becoming standard. Browsers editors are still going to make extensions over the standards since they need to have better features than competitors. Therefore some websites will rely on these extensions and the problem is back again. Put pressure on W3C to find a solution on solving this problem in the long term !

    Kudos to the IE team for going towards the standards.

  43. Kevin Goldman says:

    I can’t tell you how much all designers wished/dreamed/prayed the following were added to this list:

    -ms-border-radius-topleft  

    -ms-border-radius-topright

    -ms-border-radius-bottomleft

    -ms-border-radius-bottomright

    Creating rounded corners with nested divs and spans requires loads extraneous markup that inevitably slows everything down (including the dev and debug process).

    I’m stunned that IE7 and now IE8 wasn’t taken an "early adopter" position with this CSS3  spec. Mozilla and Safari do:

    -moz-border-radius-topleft  / -webkit-border-top-left-radius

    -moz-border-radius-topright / -webkit-border-top-right-radius

    -moz-border-radius-bottomleft / -webkit-border-bottom-left-radius

    -moz-border-radius-bottomright / -webkit-border-bottom-right-radius

    http://www.w3.org/TR/css3-background/#the-border-radius

  44. Harel M. Williams [MSFT] says:

    @Adlib: Yes, the shorthand version of the filter syntax will continue to work as long as it is quoted. We used the longer example because the colon included in it is one of the characters that causes the filter syntax to require quoting in the first place. Thanks for bringing this up!

  45. Sous Internet Explorer 8, les propriétés propres à Microsoft suivent la syntaxe préconisée par le W3C : désormais, on n’utilisera plus filter, mais -ms-filter.

  46. Morten says:

    WHY OH WHY is the CSS3 opacity so dangerous to implement? WHY OH WHY do we need to have a THIRD way of doing opacity. Especially considering that 2/3 of all the ways of doing opacity is Microsoft proprietary ways???

    If you are changing everything around, get all of it done now. Don’t wait for IE9 to get the rest done, with yet another painstaking transition for all the developers.

    Besides your opacity filter is flawed! It doesn’t multiply very well on other semi-transparent layers. For instance try and add this filter to a PNG32 that contains semitransparency for nice antialiased edges, and BOOM! the image’s semi-transparency is gone and instead we have really ugly rough edges.

  47. AlfonsoML says:

    @Morten: Maybe the fact that the filter doesn’t work in all situations is one of the reasons why they haven’t added the -ms-opacity alias.

  48. lancenz says:

    Why don’t you use something like "-css3-overflow-x"  for any css3 features? If you done that, other browsers would most likely implement the same code.

    -ms- to me would indicate the feature is only available to ie, which is not the case for the css3 features.

    Also, why not just beat your developers up and make them implement opacity. If they say it is not that easy then you need better developers :)

    It doesn’t have to be perfect, just has to work.

    eg:

    if ($property_name == ‘opacity’) {

      $filter = ‘progid:DXImageTransform.Microsoft.Alpha(Opacity=’ . ($property_value * 100) + ‘);’;

    }

    problem solved :)

    For the people who want to use the filter to it’s full, they can still use -ms-filter:xx but I personally stopped doing that years ago when I realised it didn’t work in any other browser. Much like using vbscript over javascript to use msgbox to get a yes/no/cancel dialog.

    I would expect "opacity" to over-ride any "filter" value, but "-ms-filter" should over-ride opacity.

  49. Ray says:

    @lancenz: "-css3-overflow-x" is not standard compliant "-ms-overflow-x" is how the standard dictates things have to be done (for now…).

    There is no way to have opacity called in the same way as other browser do if the feature is not 100% compliant with the other browsers (and hence standard). It would lead to divide the web again.

  50. Morten says:

    @AlfonsoML:

    Well maybe it was about time that they got this fixed! It’s been a problem at least since IE6.

    I see a huge problem with IE9. When they decide to implement CSS3 by then, we will have the opacity property, but they will most likely keep the filters around, and it would be a real mess when they get mixed.

    This very blogpost is showing how to do opacity in a way that would expose that very problem. By both setting opacity and filter, what will happen when IE starts supporting opacity? We will get opacity applied twice! NOW is the right time to rectify it. Any later versions is too late.

    There are several other good arguments in the comments here that demonstrates similar future problems with the -ms- prefix.

    Microsoft have talked so much about how they looked at how other browsers where doing it, and how they would implement some CSS3 features if there was enough demand for it. "opacity" has BY FAR the largest demand (but maybe all that talk was just that: "all talk").

    To the IE team: I remember you guys used to have a lot of good posts explaining how you made some really unpopular decisions, and for most part they made a lot of sense. PLEASE try and make sense of this decision by writing a good post about it. If you can’t, you really should consider changing your minds!

  51. Neal G says:

    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

    filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);

    Come on, wouldn’t it have been easier to just code you stupid parser to recognize this:

    opacity: .5;

    Rather than the stupid dximagetransform filter?

    Heck you could even use the dximagetransform filter behind the scenes and just interpret opacity: .5; over to the filter.

    Even worse, now to do opacity we have to do it three times, one for IE6-IE7, one for IE8 and one for standards compliant browsers.

  52. lancenz says:

    @Ray – Correct, but that’s not my point.. My point is that the standard is stupid. I’d rather IE break standard for draft css3 then put in pointless code.

    I’ll eat my hat before I use -ms-overflow-x as I’ll just have to remove the -ms- as soon as another browser supports the css3 attributes. Fair enough for IE specific extensions, but not future/draft CSS features. To me "-ms-*" means that NO OTHER BROWSER (other then a MS browser) will EVER support this feature. Standards or not. Also, what about poor old IE6/7.. they support overflow-x, so either way I’ll be using overflow-x if I want my page to work on IE6/7, unless I have different css for different browsers, which is not a good way to live.

    Either that, or I’d have to-do:

    .test {

     overflow: scroll; /* for everything else */

     -ms-overflow-x: scroll; /* ie8+ */

     -moz-overflow-x: scroll; /* if/when they implement it */

     -webkit-overflow-x: scroll; /* if/when */

     overflow-x: scroll; /* ie 6/7 */

     overflow-y: auto;  /* + all the -xx-overflow-y */

    }

    Now in the example above, all the browsers (assuming they support overflow-x) would read their -xx- and also the std overflow-x. So why prefix it at all?

    .test {

       overflow: scroll;

       overflow-x: scroll;

       overflow-y: auto;

    }

    The above would work exactly the same, so why not use it?  

    Unless you don’t want old browsers to visit your site you must use invalid css to give you the outcome you want anyway.

    Also, who says it must be -ms-.. why can’t it be -css3-.. what if I released a browser called "css3" – surely I could use -css3- in that case.. :) It makes very little difference what the prefix is, but is just silly if 2 browser engines use different prefixes for the same thing.. especially when they would both read the same value without the prefix anyway!

    Maybe lash out and use:  -c3draft- to indicate that it is a draft feature, any browser that wants to support it can do so :)

    Also, as I said, opacity can be ported from filter:DX.. without much stress.. sure, filter has a lot more functionality, but no-one ever uses it as it don’t work on moz/webkit, thus most people just use:

    #transparentDiv {

         filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);

         opacity: .5;

    }

    Which is not rocket science to port. Thus opacity should not be a problem to implement.

    Don’t get me wrong though, I’ll still have to write in filter: either way to support IE6/7 so no real skin off my back, but I don’t want to still be using filter: in 20 years, so may as well start porting it now.

    filter needs to stay in (forever?) for people who currently use it in css for older browsers, but I don’t see w3c/moz/webkit supporting it anytime soon, so they might as well just implement opacitiy now and make everyone happy so that when a developer builds a page (in the future) with minimum support for FF3/IE8 they don’t have to still use "filter", or -ms-filter for that matter :)

    I guess the silly thing is that you really should support IE6 and FF1.5 in any decent html/css/js page anyway, so the whole topic is really moot. Anyone who uses css validators will either have css filtered using server side browser sniffing or leave out anything which is not supported by all browsers and is css 2.1 standard. Using sniffers means you css is still invalid, just not to someone with a compliant browser anyway :)

    Madness.

  53. Ray says:

    @lancenz: I do totally agree, some parts of the standard are stupid and never completely took care of versionning. I think you should complain to W3C in order to change the standard. Pushing MS to break the rules again will lead to breaking the web again.

    Some points to consider :

    – 1st scenario : Let’s say browsers are using the -css3- feature you propose.

     – Internet explorer implements it.

     – Firefox implements it.

     – Let’s say you have bad luck and the implementations are not 100% identical. (Which happened in the past)

     – Developpers start using hacks because they need to differentiate browser versions.

     – They are breaking the web.

    – 2nd scenario: Let’s say browsers are using some new CSS3 extension (-css3-NewOne or -ms-NewOne -o-NewOne -moz-NewOne) for a new feature.

     – Internet explorer implements it.

     – Firefox implements it.

     – Luckily the implementation matches.

     – But finally W3C decides to modify the behavior of the feature.

       – Old -ms-NewOne is not compatible with the now -ms-NewOne

       – Old -moz-NewOne is not compatible with the now -moz-NewOne

       – Developpers start to use hacks again.

    – 3rd scenario:

     – browsers are not using prefixes at all

       – IE implements one functionnality

       – FireFox implements it at the same time but understands the feature in a slightly different way due to a lack of precision in the standard.

       – Developers face the same option with two different behaviors.

       – …

    – 4th scenario:

     – Internet Explorer implements a cool new feature

     – Firefox decides to implement at the same moment another feature that has nearly the same behavior.

     – The W3C has to standardise. But which one to choose ?

     – At least one browser has to re-implement the other browser’s feature giving an advantage to the one for which the feature is already implemented.

    -5th scenario:

     – The W3C asks for browser editors to only respect the standards.

     – Browsers do not have any advantage over the competitor so they start breaking the rules.

    What does the W3C want ?

    It looks like they are waiting for some features to be implemented before making a final decision. But if they change their mind about some of the features, they break the web.

    If they are waiting for features to come from browser editors and browser editors each propose a different solution already in use, they break the web. I they fix the standard first, and let browser implement the standard feature using the extensions until the feature is recognized as standard compliant, how to say that this feature doesn’t have any bug ? If people find differences in a feature that was recognized as safe, we are back to holly hacks again !

    Regarding opacity, up to what I understand, the effect of :

    filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);

    does not 100% match CSS standard for opacity.

    If Microsoft was doing what you say, it would mean they implement a non compliant version of CSS3 opacity, leading to the problem we know (whether you have the -css3- prefix or not). So it is not possible to make a "shortcut" until the property is completely implemented.

    This is the long and hard path to standard mode ! I guess Microsoft didn’t want to do such a jump because of this kind of troubles, and many people complained about it. Microsoft finally made the jump (for good) and many people are still complaining about it ! :)

    We can be standard or not standard, but there is not middle between the two. As soon as you are a bit away from standard, you are risking to break the web.

    As you say Madness. Feel free to complain to W3C !

  54. hAl says:

    Could anyone provide a link to the specifications of the MS specific extensions in IE8 ?

  55. hAl says:

    I would suggest to Microsoft to add these -ms- property names also to IE7 for those properties that already existed in IE7. That should not require work on the renderingengine but only on the parsing and it should not break any compatibility.

    Could someone from Microsoft give us an indication which of those properties were already supprted in IE7 and whether or not they will add the -ms- prefix to the IE7 parser for those items ?

  56. PatriotB says:

    The "short" filter syntax, e.g. filter:alpha(opacity=50), has been around since IE4 (1997).  The "progid" syntax, e.g. filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50), has been around since IE5.5 (2000).  I think it’s great that the IE team is continuing to support filter after all these years.

    Remember folks, filter is more than just opacity.  It’s a specific contract that means that for the given ProgID, I instantiate a COM object and use its IDXEffect interface.  You can even write your own filters (there were some cool MetaCreations filters created back in the day).

    In other words, filter is tied to a specific implementation, and mapping opacity to filter isn’t good enough.  I imagine that the IE team wants to implement opacity natively, without the filter architecture, and when they do that, they’ll add support for the opacity property.

  57. Adlib says:

    @Harel M. Williams [MSFT]: Thanks for clarifying – it is good to know that the shorthand version of the filter syntax will continue to work.

    When filters are used inline within a HTML tag, do we just need to exchange the double-quotes for single-quotes? i.e. for an inline style attribute which already uses double-quotes:

    … style="-ms-filter:’alpha(opacity=50)’; filter:alpha(opacity=50); opacity:0.5" …

  58. Tino Zijdel says:

    fwiw: text-overflow doesn’t seem to work anymore in IE8 standards mode; haven’t tried -ms-text-overflow yet though.

    As for opacity: since we still have to use ‘filter’ that means that I will have to add an ie8fix.css just for that. bummer.

  59. Rich Ragan says:

    Just adding a working version of filter back does not seem to address a different problem we have seen. Windows Server 2003 SP1 with security hardening applied introduces a new security setting for IE 6 and 7, namely "Binary and script behaviors".

    (Further described here:http://technet.microsoft.com/en-us/library/cc776248.aspx).

    We discovered the problems with this OS/security hardening combo when all our IE filter-based opacity usages suddenly went to solid black.

    The default setting for "Binary and script behaviors", so far as I can tell, is to disable them for the Internet domain. Among other things this breaks filter-based opacity in IE 6 and 7 on Windows Server 2003 environments with security hardening applied. I guess this is a small set of folks or more would have been heard about it.

    In any event, I checked IE 8 Beta 1 in an XP VM so the Windows Server 2003 changes should not be relevant. I saw this very same security control present so I assume it is native to IE 8 on all OS versions. If this is so and it disables opacity filters and W3C style opacity is not implemented, folks will be out of options except to use PNG’s for many of the usages (this still is problematic for IE 6 which does not support PNG well without filters).

    I hope something is wrong in my doom and gloom analysis above, but lack of opacity and relying on filters seems to be on a collision course with the aforementioned security change.

    To echo others, we really just want the simple W3C opacity.

  60. Dean Known says:

    Jesus christ, just implement CSS3 properly, get some work done.

    Webkit and Mozilla and Opera are all outcompeting IE. IE8 Betas so far have been a joke.

  61. Mo says:

    This is excellent news.

    Seriously, you guys have done precisely the right thing here: if your property doesn’t match the specified behaviour, you’ve prefixed it. What a lot of commenters don’t seem to be understanding is that, say, -ms-overflow-x is not the same as overflow-x or even -khtml-overflow-x. This is very very important to anybody who has to deal with the oddities of cross-browser CSS.

    Hopefully, of course, there’s an unwritten โ€œhopefully, all or most of the currently-prefixed properties will eventually be implemented to match the standardsโ€ in there, too.

  62. PatriotB says:

    @Mo — I would hope that in the case of overflow-x/y, that they do match the CSS3 overflow-x/y… since they were around long before CSS3 existed (since IE4 in 1997), I hope that CSS3 would spec the behavior that’s been around for 10 years rather than doing something different :)

    Same thing goes for the other properties — if they were Microsoft extensions (added before the dash prefix was first recommended by the W3C) then the W3C specs had better match that, rather than going out of their way to be incompatible with the majority of the browser market.

  63. Scott says:

    Interesting that so many people buy into the idea of vendor-specific code. It’s enough of a mess with this vendor’s fubar’ed browser now that it just makes more sense to ignore it altogether and let end user’s see a message stating their browser is broken when visiting standard’s compliant sites that don’t work in it.

  64. MS ์™œ ๊ทธ๋Ÿฌ๋Š” ๋ฐ ๊ทธ๋ƒฅ ์ข€ ๋†”๋‘๋ž€ ๋ง์ด๋‹ท!! – MS Specific Prefix : -ms-

  65. Ok, so here’s the deal:

    YES, if a feature does not match the specs, it is technically a browser-specific property and should be prefixed.  In this regard, I’m glad to see Microsoft following the standard.

    The frustration is that many of the "browser specific" properties on this list are actually just incomplete implementations of standard properties.  While you’re technically able to stash every quasi-supported CSS property behind a prefix, you’d have a browser that every single web designer would be making exceptions for.  Why not fix the poor implementations and support the standards?  Sure, make your browser unique by adding cool and unusual stuff and giving it a prefix; but for properties where standards have already been defined, save us all some trouble and use them.

  66. amazed says:

    I’m amazed.

    Not everybody will understand this but this is really a step in the right direction.

    Keep up such good work.

  67. Drossaert Kristof says:

    As a developer the thing that troubles me the most is not the future developments in browsers, but the fact that still a whole lot of computers are using old browsers.  This goes mostly for IE (because people using FF/Opera/Safari are mostly early adopters).

    I still get to see people surfing to my websites with IE5 quiet a lot.

    So it would be a great gift to all developers if Microsoft could write a "light" version  of their future IE that gets widely spread to all old IE-browser.

    "Light" because it has to work on old pc’s with not a lot of diskspace.  All the funky visual features don’t even have to be implemented, just the correct reading of CSS-code would help us a long way.

    Maybe it can be build into a very small script that us webdesigners can put in our websites and that doesn’t allow viewers to access the website before upgrading to (at least) this lightweight, new browser.

    This way, when all webdesigners are pushed to do so, we can finally get rid of all those ancient IE-browsers that don’t compliant to anything.

    [— And if you guys at Microsoft don’t want to do this, please let us find a new way to install MultipleIE on Vista!!!! —]

    Just my2cents

  68. Stephen Weiss says:

    I just spent at least 3 hours trying to move one little div 35 pixels down the page, 35 pixels that only IE 6/7 decided the div should be moved up by.  Top:0px means top:0px IE!

    Please, for christ’s sake, make sure that your browser actually supports CSS1 (you know, margin, padding, etc) properly while you’re doing all this extra stuff.

    And be sure to force people to upgrade.  None of this means anything if everyone’s still using IE 6.  And believe me, people will not upgrade on their own.

  69. autoverzekering says:

    Stephen, you are absolutely right. I have the same issues on several sites. But improvement must be on it’s way!

  70. Ted says:

    Stephen: If you actually provide a live repro URL, people might believe you instead of assuming (as I do) that you simply don’t know how to use CSS properly.

  71. Stefan says:

    me too. what’s about the border-radius?

  72. Not to beat a dead horse, but border-radius would be great.

    And this might be a stretch…but if you feel like playing catch-up with webkit than font-face would be my next suggestion.  http://www.css3.info/preview/web-fonts-with-font-face/

  73. Sean Johnson says:

    it’s a bit late for all this now isn’t it?

  74. Levi says:

    Can I beg the IE team to please add ms-border-radius? How hard would it be? It would be a major goodwill booster in the design community.

  75. Steve Reed says:

    Please, please, please implement -ms-border-radius

  76. Geoff Parker says:

    Border radius is the most needed thing IMHO – Web 2.0 is all about the rounded corners baby!

  77. ‘๋น„ ํ‘œ์ค€ CSS์†์„ฑ์„ IE8์ด ์ง€์›ํ•˜์ง€ ์•Š์œผ๋ฏ€๋กœ IE8์—์„œ ์‚ฌ์šฉํ•˜๋ ค๋ฉด ์ด๋ ‡๊ฒŒ ํ•˜๋ž๋‹ˆ๋‹ค.’ ์˜ˆ) ๋ฐ˜ํˆฌ๋ช… ํšจ๊ณผ๋ผ๋ฉด {opacity:0.5; filter:alpha(opacity=50); -ms-filter:alpha(opacity=50);} ์ด๋ ‡๊ฒŒ ์„ธ๋ฒˆ ์„ ์–ธํ•ด์•ผ ํ•ฉ๋‹ˆ๋‹ค.