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
Anonymous
September 08, 2008
PingBack from http://www.easycoded.com/microsoft-css-vendor-extensions/Anonymous
September 08, 2008
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. :-DAnonymous
September 08, 2008
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.Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
@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."Anonymous
September 08, 2008
So I take it from the last example that we can't just expect "opacity" support in IE8?Anonymous
September 08, 2008
@dman: Read the text again.. This is precisely the right road to take. Well done!Anonymous
September 08, 2008
The comment has been removedAnonymous
September 08, 2008
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.Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
The comment has been removedAnonymous
September 08, 2008
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.Anonymous
September 08, 2008
@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.Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
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?Anonymous
September 08, 2008
The comment has been removedAnonymous
September 08, 2008
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!Anonymous
September 08, 2008
The comment has been removedAnonymous
September 08, 2008
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?Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
The comment has been removedAnonymous
September 08, 2008
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.
Anonymous
September 08, 2008
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.Anonymous
September 08, 2008
Well this is a start. Well done. Please remember: Standards, community standards is all we've gotAnonymous
September 08, 2008
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.Anonymous
September 08, 2008
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!Anonymous
September 08, 2008
Congratulations on doing the right thing.Anonymous
September 08, 2008
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?Anonymous
September 09, 2008
The comment has been removedAnonymous
September 09, 2008
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.Anonymous
September 09, 2008
uhm what? I'm sorry but these two in particular -ms-overflow-x -ms-overflow-y qualify as a LOGICAL FAILAnonymous
September 09, 2008
oh no you ruined it: if memory serves, overflow-x and y DO work in IE6, actually. Make sure to test in "strict" mode...Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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?Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
Thanks guys!!! This makes my life a lot easier.Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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...Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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-radiusAnonymous
September 09, 2008
@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!Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
@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.Anonymous
September 09, 2008
The comment has been removedAnonymous
September 09, 2008
@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.Anonymous
September 09, 2008
@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!Anonymous
September 09, 2008
-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.Anonymous
September 09, 2008
The comment has been removedAnonymous
September 09, 2008
The comment has been removedAnonymous
September 09, 2008
Could anyone provide a link to the specifications of the MS specific extensions in IE8 ?Anonymous
September 09, 2008
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 ?Anonymous
September 09, 2008
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.Anonymous
September 09, 2008
@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" ...Anonymous
September 10, 2008
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.Anonymous
September 11, 2008
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.Anonymous
September 11, 2008
The comment has been removedAnonymous
September 12, 2008
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.Anonymous
September 12, 2008
@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.Anonymous
September 15, 2008
The comment has been removedAnonymous
September 16, 2008
MS 왜 그러는 데 그냥 좀 놔두란 말이닷!! - MS Specific Prefix : -ms-Anonymous
September 16, 2008
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.Anonymous
September 16, 2008
I'm amazed. Not everybody will understand this but this is really a step in the right direction. Keep up such good work.Anonymous
September 17, 2008
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 my2centsAnonymous
September 18, 2008
The comment has been removedAnonymous
September 19, 2008
Stephen, you are absolutely right. I have the same issues on several sites. But improvement must be on it's way!Anonymous
September 19, 2008
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.Anonymous
September 19, 2008
me too. what's about the border-radius?Anonymous
September 19, 2008
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/Anonymous
September 19, 2008
it's a bit late for all this now isn't it?Anonymous
September 21, 2008
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.Anonymous
September 21, 2008
Please, please, please implement -ms-border-radiusAnonymous
September 21, 2008
Border radius is the most needed thing IMHO - Web 2.0 is all about the rounded corners baby!Anonymous
September 30, 2008
'비 표준 CSS속성을 IE8이 지원하지 않으므로 IE8에서 사용하려면 이렇게 하랍니다.' 예) 반투명 효과라면 {opacity:0.5; filter:alpha(opacity=50); -ms-filter:alpha(opacity=50);} 이렇게 세번 선언해야 합니다.