The CSS Corner: Using Filters In IE8

Article
02/19/2009

Opacity. Gradients. Drop shadows.

Long before CSS proposals for Transitions and Transforms, Internet Explorer 4 supported visual special effects through CSS. This capability was further extended by Internet Explorer 5.5. As an example, the following rule could be used to apply opacity to an object:

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

Partly as a consequence of its early design, the syntax for filter properties violates the CSS 2.1 grammar: it includes a ‘:’ character, a delimiter used by CSS to separate property names from their values and therefore forbidden outside of a quoted string. The value syntax also relies on a functional notation i.e. of the form function(expression) but accepts the ‘=’ sign in the expression.

“OK, but what is really wrong with that?”

The consequence of these violations can be quite visible when a filter is syntactically invalid e.g. missing a terminating parenthesis. CSS syntax error recovery rules require parsers to ignore unknown, illegal or malformed declarations by locating the end of such declarations and resuming parsing the rest of the style sheet. An important caveat is that certain character pairs must be matched during the recovery : if one or more ‘(‘ are found, the declaration does not end until the matching set of closing ‘)’ have been parsed.

Given the following markup :

 <!doctype html><html><head><title>Filters in IE8</title><style>.bordered {       border: 2px solid black;       padding: 5px;}      .filtered {       filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50;       border: 1px dotted black;       background-color:lime;       width:75%;}p#test { font-weight:bold; color:red;}</style></head><body>       <div class="bordered">       <div class="filtered">       <a href="https://blogs.msdn.com/ie/">Visit the IE Blog</a>       </div>       <p id="test">This text should be red</p>       </div></body></html>

A standard-compliant parser will render the following:

Because filter is a non-standard Microsoft extension, the parser must look for the end of the unknown bold red declaration so as to ignore it. As it encounters an opening ‘(‘ along the way but never finds its matching ‘)’ in the rest of the rule set the dotted border, background, width and paragraph rules end up being ignored as well.

Since it understands filters and is not strict in its CSS parsing, IE7 is more resilient in this case:

But the dotted border rule that follows the filter declaration remains lost.

How should IE8 standards mode handle filter declarations?

With a new stylesheet parser compliant with CSS 2.1, one option for IE8 would be to require filters such as the one above to be rewritten like this:

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

The –ms vendor prefix explicitly marks the property as proprietary to Microsoft. By delimiting the entire value as a string, grammatical delimiter issues are avoided. Other browsers are thus able to safely ignore this declaration even if the filter value itself is syntactically invalid.

This is in fact what IE8 Beta 1 and Beta 2 required.

“But what would this strict syntax mean for my web site?”

It means none of your existing filter declarations are applied by IE8 Betas’ standards mode. At best, these declarations have no effect; at worst, they are syntactically invalid and silently disable one or more declarations in your style sheet.

It also means that in order to apply a filter in both IE7 and IE8 Betas, you have to write two rules :

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

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

Moreover, the sequence of these declarations mattered to IE8 parser in compatibility view: -ms-filter was required to come first.

“So I would have to go through all of my stylesheets that use this property and update them ?”

Indeed, and this was a very expensive proposition for some of our customers and partners. While they were both very understanding and supportive of our standard compliance goals, the backward compatibility impact was sufficient for some to consider forcing Compatibility View when IE8 shipped until their assets were up to date. Which meant millions of users would upgrade to IE8 and still access these high-traffic sites through the IE7 layout engine.

A Pragmatic Solution

While the decision may appear binary – should IE8 be backward-compatible or standard compliant? – other factors needed to be considered :

The filter property is proprietary to Microsoft and unlikely to be standardized or supported by other browser vendors
The filter property is widely used
Both the CSS grammar rules and existing implementations are able to skip syntactically valid filter rules safely.
In IE8 standards mode, our CSS parser must conform with CSS 2.1 error recovery.

Given these constraints, a solution emerged: if a filter declaration is syntactically valid, apply it: the feature remains proprietary to IE, other browsers are able to skip it safely per CSS 2.1 grammar and web authors do not have to rewrite their stylesheets.

If the filter is syntactically invalid, however, IE8 should fail per standard rules.

This is what IE8 does since RC1.

“Since it is the only feature I and many others ever use filters for, why not just implement opacity?”

Yes, opacity is a very common use case for filters today. However :

As a CSS3 feature, opacity was beyond our compliance release goal - CSS 2.1 – and as such a stretch goal.
A common assumption is that implementing opacity is mostly a matter of converting the alpha filter value to a number between 0 and 1. As specified, however, the opacity property has side-effects on an element’s stacking context.
Opacity is not the only filter feature in use on the web. Some of these features do not have CSS counterparts.

Built to pass a very large number of CSS test cases, IE8’s new layout engine is also expected to ‘just work’ with HTML and CSS input that is somewhat compliant, a little compliant or not compliant at all. It is expected to pass standard tests and support proprietary features from earlier releases. Being able to write one cross-browser stylesheet tomorrow is great, as long as yesterday’s stylesheets still work. The goals of web standards and the expectations of web designers and end users are not either-or: standard compliance and backward compatibility are essential.

Sylvain Galineau
Program Manager

edit: updated code sample

Comments

Anonymous
February 19, 2009
PingBack from http://www.clickandsolve.com/?p=11689
Anonymous
February 19, 2009
"The consequence of these violations can be quite visible when a filter is syntactically" The consequences of syntactical violations in 'normal' CSS are equally visible, so what point are you trying to make? That the filter-syntax is overly verbose and thus will lead to more syntax-errors? Why did Microsoft not implement at least -ms-opacity? I think it is the most used 'filter' out there. You are now making it needlessly difficult to implement something in IE8 that is already commonplace in all other browsers...
Anonymous
February 19, 2009
@Tino Zijdel, "Why did Microsoft not implement at least -ms-opacity? I think it is the most used 'filter' out there. You are now making it needlessly difficult to implement something in IE8 that is already commonplace in all other browsers..." because it's no better than -ms-filter? and how is -ms-filter "needlessly difficult" at all? at the most, you just need a quick "replace all" if you don't want to write it all manually.
Anonymous
February 19, 2009
Here's an earth shattering suggestion. Why not just use the CSS property "opacity" rather than come up with a vendor proprietary prefix or is your support for opacity still buggy enough that it isn't worthy of that? I would like to applaud you guys for your standards support in IE8 although it just seems more logical to me to use the standards compliant property in this situation and insert the filter property after that.
Anonymous
February 19, 2009
@Neal: The filter for opacity was introduced pre-IE6, and does not behave exactly as the CSS opacity property. Hence, it would be incorrect to simply map the existing implementation to the standards-defined property.
Anonymous
February 19, 2009
I saw "CSS", "Corner" and "IE8" in the same headline and immediately thought OH MY THEY DID IT! :)! Alas, I was mistaken. :( All I want from IE8 Final is -ms-border-radius...
Anonymous
February 19, 2009
The comment has been removed
Anonymous
February 19, 2009
@Sylvain, I read your post and did not find answers to my questions. 1- I use filter: alpha(opacity=70); in my webpage www.gtalbot.org/DHTMLSection/DynamicOpacity.html and I query its support in objects like this: if("filters" in objImageToModify && typeof objImageToModify.filters.alpha.opacity == "number") {...} and I have so far never had a problem. So 1- Why should I now turn to -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(opacity=70)"; for IE 8 and filter:progid:DXImageTransform.Microsoft.Alpha(opacity=70); for IE 7 ? 2- If I have to use the declaration -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(opacity=70)";, then how would I be able to set its value dynamically? Regards, Gérard
Anonymous
February 19, 2009
> The filter property is widely used How widely? Come on, give us some metrics from msnbot - these must have influenced your decision?
Anonymous
February 19, 2009
There is one minor detail your forgot, Sylvain : http://www.w3.org/TR/SVG11/filters.html#FilterProperty And Microsoft is listed in the authors of that specification. So a web author who wants to apply a well-defined filter in a cross-browser environment will have to write 3 filter declarations : one for -ms-filter, one for SVG using external references, one for IE7. As a matter of fact, Firefox now allows such SVG-based filters even for HTML4 content.
Anonymous
February 19, 2009
The comment has been removed
Anonymous
February 19, 2009
The comment has been removed
Anonymous
February 19, 2009
Hey Now, I'm glad I just learned quite a bit on filters. Thx 4 the info, Catto
Anonymous
February 19, 2009
Hey Sylvain, I believe you made the correct decision given all the considerations. Nothing is as straighforward as it seems, and in this case I think you found the sweet spot. And thanks also for the great write-up. Thanks, Nate Nate Koechley
Anonymous
February 20, 2009
Well I'm let down. I thought they were going to make it easy for developers and just implement opacity, but no. "A common assumption is that implementing opacity is mostly a matter of converting the alpha filter value to a number between 0 and 1. As specified, however, the opacity property has side-effects on an element’s stacking context." So what? Could you at least start implementing the opacity property, even if it means that under the covers it still uses the old proprietary filter? That would be a big step toward simplifying this situation going forward.
Anonymous
February 20, 2009
"2. The filter property is widely used" As Wikipedia would say, please cite a source for this. I have only just begun using the filter property since IE8 Beta has been out and only to mimic some CSS3 properties supported by most other browsers.
Anonymous
February 20, 2009
Do not want to use IE filters. As long as there aren't just eye candies on top of a good CSS3 implementation, a good DOM and event model for JS, support for canvas and the list could get pages. oh,sorry! your road map is the one that FF had 3 years ago, oopsy, too bad... for us. The bad thing is that your road map is certainly closed to: thru away IE8 with W7 where other's road map is : release when it works. Anyway, if you could specify in what way filter:alpha(opacity) differs from the opacity spec, it could help to see your point. Because here, your explaination,well, does not explain. Be sure that if people used filter:alpha(opacity), it wasn't for the IE features (counter effects??)but certainly for the css opacity property that works everwhere else but IE.
Anonymous
February 20, 2009
Jim-- Don't you suppose that maybe, just maybe, Microsoft has some sort of web crawler that actually looks at pages in the wild? Every other browser maker has one, and Microsoft has a search engine. So saying "cite your sources" to a source is somewhat obnoxious. Aaron-- While you're dancing around it, you're really saying "please mark your proprietary thing as if it were the standards-compliant thing." That's EXACTLY the wrong way to go, as history has shown. Say "Please implement CSS3-standard opacity" all you want, but don't try to suggest that renaming what exists already would be a good thing. Stu-- "defeat the spirit of standards" -- what the heck does that mean? Do you write promos for movies and TV dramas? Daniel-- IE doesn't support SVG. Maybe you missed the memo? Tino-- "I guess passing the Acid2 test was deemed more important..." Ummm.... yes, getting CSS2.1 compliance before (the not yet standard) CSS3.0 sorta makes sense, dontcha think??
Anonymous
February 20, 2009
@Ted the epic fail - re: "yes, getting CSS2.1 compliance before (the not yet standard) CSS3.0 sorta makes sense, dontcha think??" yeah, cause it is real hard to understand how the border-radius property that devs are waiting for works. border-radius, I wonder what the implementation might change to before the spec is carved in stone. Maybe they'll do this: border-radius: Verdana; so you can set the border radius of your element to a font. hhmmmm, not likely. I'm going to go out on a limb here (now don't quote me on it) but I'm gonna guess that the border-radius will always be a unit of measurement.... pixels, percent, you get the idea. But lets focus on Opacity since that's what your tireless rant started on. opacity as currently spec'd ain't likely to ever change either, but since you are so "hip" with all the goings on of the web, please do tell us how you think this spec might change. opacity: yes; opacity: kind of; opacity: Tahoma; opacity: Yellow; opacity: 13px; I don't think I'm the only one that thinks this property just simply isn't changing.
Anonymous
February 20, 2009
@gordon the epic fail: Learn to read. The point is that no one should be surprised that they're doing CSS2.1 (which IS a standard) before CSS3.0 (which isn't, yet).
Anonymous
February 20, 2009
@sylvain, et al: I'm sure you had your reasons for handling opacity the way you have. The rise or fall of human civilization will not, thankfully, hinge upon it. (I'm certain, really.) Border Radius would have been real nice and TIMELY, I think, for this release. But that's water under the bridge at this point. Overall, CSS2.1 support in IE8 seems well-done. IMHO. Thanks for clarifying the filter syntax - this post I'll need to print out...
Anonymous
February 20, 2009
@Tino: due to its functional notation, the consequences of bad filter syntax may result in more than the filter rule itself not applying. If you write, say, a margin shorthand badly, it may affect a lot of elements but it will rarely - if ever - result in the rest of your ruleset or stylesheet to be skipped by a CSS parser. Filters, however, can have such an impact as demonstrated in the sample and its screenshots. Since IE7 was much more tolerant than IE8 in this respect, it is worth mentioning. As for opacity, it is not more difficult in IE8 than it was in IE7; it would have been harder had we stuck to a strict syntax. But yes, it remains harder than it should be. Anything that does not work interoperably is harder. @RichB: yes, we did check out search index metrics but in practice there were not as much of a factor as the daily bug reports of sites broken by filters no longer applying. The stream of issues was nearly constant through our months of Beta. Opacity simply is a very popular feature and this is the only way to use it in IE. @Jim Robinson: well, I used filters for the first time in IE5 ! Our sources are our bug reports - internal/external - as well as our search index. We also received data from large web sites about their own style sheets and apps but we can't really publish that either. @Stu: we talked with the W3C working group on whether this was a suitable course of action. This is in principle no different from us skipping a -moz property while Firefox applies it. Except that in IE8, we will now fail the same way as everyone else is the value is bad. The filter syntax is unfortunate, but updating it was not any better an option for existing content than requiring double quotes. As for the name, this is the Corner of the blog where we talk CSS. We care enough about CSS to give it its own series. @Daniel: you are of course correct. Thanks for the pointer ! @Gerard: you do not have to change anything for IE8. You had to in Beta 1 and Beta 2. This was the goal of our changes in RC1. The backward-compatibility impact of forcing a strictly compliant syntax was too significant. We support the existing syntax. But if the filter value is syntactically incorrect, especially if it has unbalanced delimiter pairs then IE8 is not as forgiving as IE7 was. It will fail per CSS2.1 error recovery rules. The -ms prefix in your static style rules is something we recommend not just to be a good standard citizen but because it is the forward-looking thing to do in your future stylesheets. As Daniel points out, you can already apply SVG's filter property in Firefox.
Anonymous
February 20, 2009
@Sylvain, > The -ms prefix in your static style rules is something we recommend not just to be a good standard citizen but because it is the forward-looking thing to do How to convert these lines according to the new -ms- format? if("filters" in objImageToModify && typeof objImageToModify.filters.alpha.opacity == "number") and objElement.filters.item("DXImageTransform.Microsoft.Alpha").opacity += intIncrement; Declaratively, things (prefixes to add) are clear: -moz, -o, -ms, -khtml, -icab. What about dynamically, in scripts? objElement.Msfilters.item("DXImageTransform.Microsoft.Alpha").opacity += intIncrement; ? The answers to such questions should be at MSN. Regards, Gérard P.S. value is not a valid attribute for <a>, even in HTML 5; <title> is missing in your code example. The W3C validator would have reported these.
Anonymous
February 20, 2009
I would like to see Microsoft push for a URL-based extension mechanism, such as XMLNS is in XML, for CSS going forward. CSS 3 is a draft, some modules have made progress, some made it to candidate -- just to be flipped back to draft, and so on. FireFox, Opera, Safari, Chrome and others (including IE 8) are starting to play with some portions of the CSS 3 specifications. The issue is, there is no way to indicate the target version of the draft standard in CSS 3.0, and there is no consistent way from JavaScript and from CSS to access the properties. This leads to code like in jQuery where browser sniffing is used (has to be browser sniffing -- there's no way to feature detect it) to switch between CSS property names for various attributes. What is needed is a way to say: -filter means: http://w3c.org/css/3.0/filters/200901-draft.xml That way, the CSS property becomes: -filter-whatever: whatever; and the JavaScript becomes: .style.filterWhatever = 'whatever'; Similarly, if places where CSS 3.0 is known to conflict with CSS 2.1 (documented in 3.0, just as 2.1's breaks from 2.0 are documented, and 2.0's breaks from 1.0 are documented) can be handled similarly to this, then no web pages break because of the changes. This is similar to the DTD in HTML, which allows the possibility of switching layout rules based on the document type, to preserve compatibility with websites. All markup-based technologies should be using some URL-based extension mechanism.
Anonymous
February 20, 2009
I've got your "compliance release goal" right here...
Anonymous
February 20, 2009
It took about 24 hours for someone to mention conditional comments, thank you Tino. I don't know why this blog post was made without mentioning them? It's not standards compliant though it is a standards friendly method of implementing Microsoft's opacity filter in all versions of Internet Explorer without fail. I've had my IECCSS tutorial available for at least a couple of years now with a slew of examples of how to target various versions of IE to include IE-specific stylesheets... http://www.jabcreations.com/web/web-ieccss.php As far as IE9 goes if we get some key CSS3 support (selectors and the properties I always mention) and the JScript engine gets as much attention as CSS got in IE8 then all that's really left is XHTML support.
Anonymous
February 20, 2009
Insane, late night heretical, mostly-unrelated-to-this-post thought ahead: Wouldn't it be easier to just release a new browser at this point? Same IE8 Standards Mode, just call it something else, put it in a different package. Call it Windows Live Explorer 8. Allow it to install side-by-side with IE. These backwards compatibility issues have more to do with not being able to install multiple IE versions at once than anything else. You don't break huge enterprise deployments that way.
Anonymous
February 20, 2009
The comment has been removed
Anonymous
February 20, 2009
Hi, I am lost. I can't work out opacity. What I want is a single style block that will work on all browsers. Here is what I have so far. <div style=" background-color:Red; color:White; text-align:center;z-index:1; filter:alpha(opacity=50);-ms-filter: 'Alpha(Opacity=50)';opacity: 0.50;-moz-opacity: 0.50;-khtml-opacity: 0.50; clear:both"> Works for IE8, FX3x, Mozilla, SeaMonkey, Safari and KMelion. Doesn't work for IE6 and IE7 (I am using Virtual Images for IE6, IE7 not the IE8 browser modes) I just tried reversing the order for the IE7 and IE8 syntax <div style=" background-color:Red; color:White; text-align:center;z-index:1; -ms-filter: 'Alpha(Opacity=50)';filter:alpha(opacity=50);opacity: 0.50;-moz-opacity: 0.50;-khtml-opacity: 0.50; clear:both"> and it didn't work in IE6 and 7. I remember that HW also wrote about this and provided a cross browser solution, but I cannot find this. Could you please point me in the right direction. Regards.
Anonymous
February 20, 2009
Ted wrote: "Learn to read. The point is that no one should be surprised that they're doing CSS2.1 (which IS a standard) before CSS3.0 (which isn't, yet)." CSS2.1 and CSS3 Color are both W3C Candidate Recommendations; how is one "a standard" and the other not?
Anonymous
February 20, 2009
@"CSS3 Color [is a] candidate recommendation" Not according to the W3C: http://www.w3.org/Style/CSS/current-work
Anonymous
February 21, 2009
@Ted the epic fail - CSS Color module IS a Candidate release, and was one back in May 2003. http://www.w3.org/TR/2003/CR-css3-color-20030514/ The latest CSS3 version of it is still a working draft. http://www.w3.org/TR/css3-color/ PS is there not a "I love everything Microsoft and you can't convince me otherwise, never ever, double stampsies, no erasies" blog out there that you could better spend your time on?
Anonymous
February 21, 2009
The comment has been removed
Anonymous
February 21, 2009
The comment has been removed
Anonymous
February 22, 2009
The comment has been removed
Anonymous
February 22, 2009
The comment has been removed
Anonymous
February 22, 2009
The comment has been removed
Anonymous
February 22, 2009
This post makes me cry. IE8 was supposed to bring in "Standards Compliant IE" with Compatibility Mode available if you wanted to use the old MS-only stuff. Standards Mode should be just that - STANDARDS ONLY. Seriously, you guys are just storing up more pain for yourselves and the web in the future. IE9 will now need IE8 and IE7 compatability modes, and web designers are still being forced to write their sites twice instead of one stylesheet that works on all browsers.
Anonymous
February 23, 2009
Is there any chance to include Auto Update for IE8 so IE can notice the use to update on next release? since most of the people doesn't check Auto update for windows.
Anonymous
February 23, 2009
Is there any chance to include Auto Update for IE8 so IE can notice the user to update on next release? since most of the people doesn't check Auto update for windows.
Anonymous
February 23, 2009
EnigmaOX: I don't know where you get your info, but a significant majority of users DO have automatic updates set to either CHECK or INSTALL. Kpax: I don't think you understand how this works. ALL browsers support vendor-specific extensions in Standards mode. Furthermore, all browsers support behaviors in their standards mode that are not defined by any standards-- they're just the way things have always been.
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
@Ted: It isn't both. That 2003 draft was a candidate recommendation; it has returned to a working draft since.
Anonymous
February 23, 2009
gsnedders: Thank you. I stand correct.
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
Please update IE 6 for web standard!!
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 24, 2009
The comment has been removed
Anonymous
February 24, 2009
History is littered with the corpses of "superior" technologies and companies that don't recognize the importance of backwards compatibility. Failure to recognize what users actually want is the height of hubris and the demise of many otherwise promising technologies.
Anonymous
February 24, 2009
@Dan: while backward compatibility is a lofty goal, History is littered with the corpses of "backward-compatible" technologies that interested no one because they didn't innovate and didn't work with the current ecosystem. Currently web pages use vector graphics, update content without reloading (AJAX and DOM manipulations), contain advanced scripts representing bona fide applications. What has IE 8 brought to the table here? Its scripting speed is no better than Firefox 1.5/2's (engine from 2005), its DOM support no better than Opera 7's (from 2004), its vector graphics support lower than anything (still no SVG, VML support greatly reduced) and its markup parsing limited (no XHTML support, XML support relying upon non-XML 1.0-compliant msxml3). All in all, that makes IE 8 a 2005 browser (that happens to pass somewhat the Acid2 test; yay). Which would be good in 2005, fair in 2006... But downright ancient in 2009. Other features like separated processes for each tabs, integrated developer tools and sandbox mode notwithstanding (they're great ideas at the very least), I have lost all excitement about IE 8 and I will support it like all other IE releases before it. Reluctantly, like a necessary evil.
Anonymous
February 25, 2009
The comment has been removed
Anonymous
February 25, 2009
@Alahmnat > can someone tell me how IE8 can claim to fully support the CSS 2.1 specification and STILL not allow for the creation of scrollable tables with fixed headers (...) This is obviously a difficult capability to implement. I can not speak for IE Team but I believe (a hunch) this bug issue is in their internal to-implement-in-the-future list and that it has the keyword highrisk. > If I could require my users to run Firefox or Safari (or Opera), I would, and just get on with making simple, HTML+CSS scrollable tables with fixed headers Opera 7.x, 8.x, 9.x and 10.0 alpha 1 can not do that. I personally filed bug 123296 in Opera Bug Tracking System in 2004; it's nr 2 at my Opera bugs webpage. Safari 2.x, 3.x and 4 beta can not do that. There is plan to support this at webkit though bugs.webkit.org/show_bug.cgi?id=3239 > If the IE team manages to close the gap they've been left with by Microsoft's decision to freeze IE's development in 2001, I'll be the first to sing their praises As long as we restrict talks to CSS 2.1 and HTML 4, the gap with other W3C-web-standards-compliant browsers (Firefox 3.0.6, Opera 9.63, Safari 3.2.2, Konqueror 4.2, etc) has positively and definitely been greatly reduced... it may be that IE 8 RC1 leads the pack now in those 2 standards. IE 8 RC1 has possibly right now the most complete and most accurate CSS 2.1 implementation. regards, Gérard
Anonymous
February 25, 2009
I found this post rather confusing. I guess it refers only to IE8 betas and running sites under both betas and RC1. If this is true, than the current filter:alpha(opacity=50); should still work under standard IE8 RC1? Please clearly state how is the filter implementation supposed to be used under IE8 standard. I'm not interested in IE8 Betas at this point.
Anonymous
February 25, 2009
Compatibility tables for features in HTML5: http://a.deveria.com/caniuse/ Selectors API Test Suite in IE 8: http://ejohn.org/blog/selectors-api-test-suite-in-ie8/
Anonymous
February 27, 2009
good, that you are trying to tidy up old garbage, where it sticks out and you cannot get rid of it. This is a step in the right direction and it's good that you are focused on CSS-compliant parsing. My appreciation of this is of course based on the hope that you get to continue your good work after IE8, so that filters and other horrible workarounds can finally be ignored due to better CSS3 support (among other things) in IE9.
Anonymous
February 27, 2009
Just to be clear, I am not advocating that IE8 have a full CSS3 implementation. That ship has sailed. Just that there is a reason why Sylvain Galineau used the opacity filter as an example -- it is the most widely used filter in use today. I was simply advocating that instead of implementing up to CSS2.1, that you could break the CSS2.1 standard by including a little bit of CSS3 here and there which is in wide use in websites today out of need and worked around in IE, in this opacity example, using filters. But as stated above, the workaround is still not equivalent.
Anonymous
February 27, 2009
The comment has been removed
Anonymous
February 27, 2009
Firefox 3 uses SVG filters. I think that's the way to go.
Anonymous
March 02, 2009
A possibly better solution is to expect web developers to add that closing parenthesis, rather than breaking pages in a way that forces them to become more complicated/ugly instead of less.
Anonymous
March 03, 2009
Fix opacity already. This is a joke.
Anonymous
March 03, 2009
None of the filter syntaxes seem to have any effect on a <span/> element. <p/>, <div/> etc work great, but text in a <span/> gets no transparency at all. (IE8 RC1)
Anonymous
March 05, 2009
@Magnus: 'filter', in all IE releases, require a block element to apply (for example, using opacity filter on a span doesn't work in IE 6, be it in Quirks or Standard mode); said block element must ALSO have layout (hasLayout=true) I wrote a test that shows when filter works for all versions of IE, that can be found at http://moneyshop.perso.cegetel.net/moneyshop/testfilter.html Interestingly, IE 8 now doesn't need an element to have layout, it can apply 'filter' to any block-level element (so, filter can now get applied even in cases former IE versions would have disregarded it).
Anonymous
March 15, 2009
I have a few comments...

-ms-opacity would be better than -ms-filter because you no longer have a filter property declaration in another style resetting your opacity when both styles are applied to the same element.
The "-ms-" prefix should have never been applied to PREEXISTING proprietary IE properties. Those property names CANNOT be used in new CSS specifications anyways because they're already used heavily "in the wild". While I applaud Microsoft for adopting the proper method of indicating vendor extensions, they should have limited its use to NEW proprietary CSS properties. Using it for older properties merely causes confusion and headaches for Web developers.
The latest version of Webkit, Mozilla Firefox and Opera all support the "opacity" property without a vendor prefix. Therefore, although the standard containing the "opacity" property is still in development, this specific property is a standard for all intents and purposes. Side note: "-moz-opacity" has been an alias for "opacity" in Mozilla Firefox since version 0.9. As of the version 3.5 (formerly known as 3.1), the "-moz-opacity" property name is being dropped entirely, and is obsolete.

Anonymous
March 15, 2009
IE 16 might be as good as firefox 3 and safari 3. Webkit's already implementing HTML 5 client databases and CSS animation ... and IE can't quite figure out opacity because their code from 4.x is still around?! Just one more frustrated designer :)

Share via

The CSS Corner: Using Filters In IE8

Comments

Additional resources