The CSS Corner: Using Filters In IE8


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=”http://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:



a box with a border, a link to the ie blog is contained as well as the sentence "This text should be red" which is in black font.


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:



A box with a border a link to visit the IE blog with the background of the link in green highlight.  A sentence "This text should be red" the text is red.


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 :



  1. The filter property is proprietary to Microsoft and unlikely to be standardized or supported by other browser vendors

  2. The filter property is widely used

  3. Both the CSS grammar rules and existing implementations are able to skip syntactically valid filter rules safely.

  4. 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 (68)

  1. Tino Zijdel says:

    "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…

  2. glastheim says:

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

  3. Neal G says:

    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.

  4. EricLaw [MSFT] says:

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

  5. Pat says:

    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…

  6. Ben Hollis says:

    Does the difficulty in properly implementing "opacity" for Internet Explorer mean that other visual tricks like rounded corners, box and text shadows, gradients, etc are unlikely to show up in any timely manner?

  7. @Sylvain,

    I read your post and did not find answers to my questions.

    1- I use

    filter: alpha(opacity=70);

    in my webpage

    http://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

  8. RichB says:

    > The filter property is widely used

    How widely? Come on, give us some metrics from msnbot – these must have influenced your decision?

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

  10. Tino Zijdel says:

    @glastheim "because it’s no better than -ms-filter?"

    -ms-opacity would be better in the sense that at least Microsoft can line up the property-value syntax with that of opacity:

    -ms-opacity: 0.8;

    against:

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

    or (which should at least be mentioned in this article because afaik this will also work in IE8):

    -ms-filter: alpha(opacity=85);

    indeed having to add yet another line for opacity to our CSS (or having to serve a seperate CSS file only for IE8 through conditional comments) is a pain which would not have been necessary if Microsoft took the effort of actually implementing opacity. I guess passing the Acid2 test was deemed more important…

  11. Stu Smith says:

    Sounds like you’re using the letter of the standards definition to defeat the spirit of standards.

    And your title… "The CSS Corner"… gives the impression that you consider CSS to be one tiny corner, an insignificant "oh if we must" feature. Do you see IE as a wizz-bang Windows application that just so happens to contain a browser canvas that really isn’t of much interest to you?

  12. ccatto says:

    Hey Now,

    I’m glad I just learned quite a bit on filters.

    Thx 4 the info,

    Catto

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

  14. Aaron says:

    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.

  15. Jim Robinson says:

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

  16. shi says:

    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.

  17. Ted says:

    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??

  18. gordon says:

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

  19. Ted says:

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

  20. Richard Fink says:

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

  21. SylvainG [MSFT] says:

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

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

  23. Dave Bacher says:

    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.

  24. Yeah Yeah says:

    I’ve got your "compliance release goal" right here…

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

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

  27. Alec says:

    I’ve been struggling to find information about the limitations of CSS file includes and CSS @import statements in IE8.

    Lala is a web app, and because of the way it is designed, etc., we have a lot of CSS files. We crunch them down for production deployment, but in dev we like to have each widget to have its own CSS file. IE6 and IE7 have limits on how many files can be referenced via includes, and the way we worked around this was to use @import within the page. The problem is that IE8 can’t handle that method, nor can it handle 54 includes as all other modern browsers can.

    That said, it is happy to render things correctly on prod.

    In dev, the current workaround for me (since I’m the guy who gets to use IE8 for testing), is to render in Compatability mode. It is obviously not a straight replacement, I know, but at least the page isn’t missing half of the style definitions.

    If anyone has any info, please share. Links, tips, whatever. alec at lala will contact me directly.

  28. Rob Parsons says:

    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.

  29. 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?

  30. Ted says:

    @"CSS3 Color [is a] candidate recommendation"

    Not according to the W3C:

    http://www.w3.org/Style/CSS/current-work

  31. harold says:

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

  32. Ted says:

    @harold the epic fail – Let me get this straight– the "Color" module of CSS3 is a "Candidate Recommendation"… but it’s ALSO simultaneously a "Working draft" which is NOT YET a "Candidate Recommendation"?  And this somehow makes sense to you?  

    So, tell me again why a spec in such a confused state about its own readiness should be implemented before CSS 2.1?  

    The W3C itself rates CSS3 as "Medium Priority" while CSS 2.1 is a "High Priority"?

  33. glastheim says:

    @Tino Zijdel,

    "-ms-opacity would be better in the sense that at least Microsoft can line up the property-value syntax with that of opacity"

    huh? how is that better? you still have to write your extra line of CSS code for IE.

    "or (which should at least be mentioned in this article because afaik this will also work in IE8): -ms-filter: alpha(opacity=85)"

    have you even read the article? the article is NOT about how you can write opacity in IE8, it’s about how IE8 improves standards compliance by following the standard syntax better (ie. adding the -ms vendor prefix and delimiting the whole value into a string)

    As far as I see it, the article just uses opacity setting as an example to explain how the new -ms-filter syntax is better than the old filter syntax. It’s not trying to teach you how many ways you can set opacity or how you want the opacity property.

    "indeed having to add yet another line for opacity to our CSS (or having to serve a seperate CSS file only for IE8 through conditional comments) is a pain which would not have been necessary if Microsoft took the effort of actually implementing opacity. I guess passing the Acid2 test was deemed more important…"

    Of course it’d be less a pain if W3C can invent CSS3 before MS invented filter property, or the filter property didn’t became a de facto standard that’s used in so many websites today. That’s why they are trying to fix the filter property as much as they can now in IE8. Implementing CSS3 is another completely different matter.

  34. sroussey@network54.com says:

    Please stop, and re-evaluate your goals for IE8. CSS3’s opacity should be included. Even though it is not in CSS2.1, it should have been a goal for IE8 all along.

    There might be people using other filters, etc., but I don’t think you can find one item so much in widespread use all over the web as opacity. It is like not supporting transparent png in IE6.

    Make a freaking exception. Please…

  35. Andrew Powell says:

    I agree 100% with sroussey. IE had been neglected for so long that it fell years behind the other browsers in terms of CSS support. (not to mention other features) While support of CSS 2.1 can certainly be applauded, you’re dooming the browser to remain behind.  If the IE8 team continues to just turn a blind eye to the emerging (and already implemented) technologies then IE will just continue to trail the other browsers. So what does all this mean; Will we have to wait another year for IE9 to be released for CSS3 implementations?

    By systematically dismissing popular javascript (reference: the ‘Operation Aborted’ cover up) and CSS use patterns for this release, you’re telling the developer base that you still insist what you are doing is correct, despite what is actually being done on the web today. From the outside looking in, your team is doing a really sad job of conveying to the developer base that you understand how to get IE back to being a technologically competitive (let alone superior) browser in the near future.

    Maybe we need to get Ballmer a permanent desk in the IE8’s corner of the campus and have him shout ‘DEVELOPERS DEVELOPERS DEVELOPERS’ three times daily at the IE8 team & management.

  36. X-Talisman-Compatible says:

    http://my.opera.com/hallvors/blog/2009/02/22/x-talisman-compatible-messup

    I wonder what other amusing stuff we’ll see in the future.

  37. kpax says:

    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.

  38. EnigmaOX says:

    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.

  39. EnigmaOX says:

    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.

  40. Dan says:

    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.  

  41. Mitch 74 says:

    There is Standard and Standard support; what most Web developers ask for, if for IE to finally support standards properly.

    Take a ‘run of the mill’ web page: it will contain a few hundred errors in its HTML, if only because it was programmed following XHTML syntax but transferred and parsed as HTML (in ‘pure’ SGML-based HTML, / short-closes a tag; the following ‘>’ of XHTML thus becomes an illegal entity).

    Current HTML parsers don’t understand a tag’s short close character, and will merely ignore it; this single fact has become standard (it’s cited in XHTML 1.0 Strict annex C definition at W3C’s).

    However, let’s take another case: if my memory serves me, paragraphs are supposed to close when another block-level element appears (in HTML, you don’t have to explicitly close a paragraph); however, IE for a long time, even in Standards mode (as opposed to Quirks mode) made the table an inline block that was a child of a paragraph.

    This has an impact on the DOM, as IE would consider the table element as a child of the paragraph, while it should actually be a sibling.

    Now, let’s write a piece of code that turns the text of all children (but not grandchildren) of the BODY (containing our paragraph and table) into red:

    – in IE, the table would remain black

    – in standard browsers, everything would turn red.

    Compensating for IE’s bad interpretation of the DOM tree would require the detection of the browser, and ‘if IE’, look for all tables inside paragraphs and color them red too.

    Please not here that the markup is perfectly correct, that the ECMAscript code is too, and that it will run flawlessly in all cases – but it will vastly differ in results depending on browsers, not because of missing properties or lack of support, but because one browser ignores a standard rule that says that in an HTML document, a paragraph followed by a table will close itself before the table.

    Workaround: explicitly close all your tags where they are supposed to close as per the standards.

    An extreme case that was once used (my failing memory won’t help) was the following:

    <i>Some italicized text <b> some bold and italicized text </i> and yet some more text </b>

    How should be ‘some more text’ written? In bold? with nothing?

    Nope, as per the standards, it should be written italicized because the ‘i’ isn’t closed by the ‘/i’ since it’s inside the ‘b’ tag, it’s actually an invalid entity; so, in fact, it runs on (at least until its parent closes).

    However, IE will write these ‘as expected’, and create a very special DOM tree: ‘b’ is at the same time child and parent to ‘i’, so if you run an ECMAscript that recursively goes along the tags in your page, you will freeze your browser in an endless recursive loop RIGHT HERE, which will (hopefully) cause the Jscript engine to catch on and ask, after 30 seconds, if you want to stop all scripts in your page because there’s an error in them (while there is none).

    Developers that like standards like them because, at least, programming for them creates a predictable behavior in most cases; not following the standards creates huge restrictions and a lot of extra work, guessing and testing for everybody.

    For example, by not allowing proper DOM or CSS parsing.

  42. gsnedders says:

    @Ted:

    It isn’t both. That 2003 draft was a candidate recommendation; it has returned to a working draft since.

  43. Ted says:

    gsnedders: Thank you.  I stand correct.

  44. Sage says:

    http://www.neowin.net/news/main/09/02/23/internet-explorer-8-has-reached-rtm

    As mentioned before, they only want to ship this in time for Windows 7 RC1 in April. Code quality, spec violations be damned.

  45. EricLaw [MSFT] says:

    @Sage: If you believe everything you read on the web, you will find yourself believing all sorts of crazy stories.  

    When IE8 is done, you’ll read all about it here.

    As we’ve stated before, IE8’s downlevel release is not tied to the schedule of Windows 7.

  46. @Mitch 74

    > (…) paragraphs are supposed to close when another block-level element appears (in HTML, you don’t have to explicitly close a paragraph); however, IE for a long time, even in Standards mode (as opposed to Quirks mode) made the table an inline block that was a child of a paragraph.

    This is supposed to have been fixed as soon as beta 1 because acid2 test specifically tests this at line 129.

    Line 129 of acid2 test:

    <p><table><tr><td></table><p class="bad"> <!– <table> closes <p> per the HTML4 DTD –>

    Also:

    "<P> element now closes when <TABLE> is encountered (ACID 2 compliance). "

    blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx

    but Jukka Korpela discovered that an unclosed <p> preceding a <form> was not closed implicitly and, indeed, it affects the DOM tree. See

    http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug74

    or bug 338580 at connect.

    > let’s write a piece of code that turns the text of all children (but not grandchildren) of the BODY (containing our paragraph and table) into red (…)

    Mitch, provide a test case (where IE 8 RC1 fails) on that and I’ll file it at connect IE beta feedback for you.

    > Workaround: explicitly close all your tags where they are supposed to close as per the standards.

    Before people start to code workarounds, weird hacks, fixes of all sorts, they should report the bugs, especially when IE Team is trying to fix all the bugs.

    "

    Close Your Tags

    Unlike Extensible Markup Language (XML), HTML has the notion of implicitly closed tags. This includes frame, img, li, and p. If you don’t close these tags, Internet Explorer renders your pages just fine. If you do close your tags, Internet Explorer will render your pages even faster.

    "

    Building High Performance HTML Pages

    msdn.microsoft.com/en-us/library/ms533020.aspx#Close_Your_Tags

    Regards, Gérard

  47. @ Mitch 74

    > <i>Some italicized text <b> some bold and italicized text </i> and yet some more text </b>

    Whenever there is misnesting of nodes or invalid markup code, then there is no correct or incorrect layout output according to HTML 4. That is why valid markup code is always to be preferred.

    > Developers that like standards like them because, at least, programming for them creates a predictable behavior in most cases; not following the standards creates huge restrictions and a lot of extra work, guessing and testing for everybody.

    Exactly! This is what IE Team and MSDN documentation should be repeating and explaining.

    Regards, Gérard

  48. highca says:

    Please update IE 6 for web standard!!

  49. I found the answers to my own questions… at least, these are empirical results.

    Assuming

    style="filter: alpha(opacity=70);"

    becomes

    style="-ms-filter: ‘progid:DXImageTransform.Microsoft.Alpha(opacity=70)’; filter: progid:DXImageTransform.Microsoft.Alpha(opacity=70);"

    Q.1) How to convert this following line according to the new -ms- format?

    if("filters" in objImageToModify && typeof objImageToModify.filters.alpha.opacity == "number")

    A.1)

    if("filters" in objImageToModify && typeof objImageToModify.filters.item("DXImageTransform.Microsoft.Alpha").opacity == "number")

    ——

    Q.2) How to convert this following line according to the new -ms- format?

    objElement.filters.item("DXImageTransform.Microsoft.Alpha").opacity += intIncrement;

    A.2)

    Same code.

    objElement.filters.item("DXImageTransform.Microsoft.Alpha").opacity += intIncrement;

    ——

    Q.3) How to convert this following line according to the new -ms- format?

    if(objImageToModify.filters.alpha.opacity < intCeilingThreshold)

    A.3)

    if(objImageToModify.filters.item("DXImageTransform.Microsoft.Alpha").opacity < intCeilingThreshold)

    Regards, Gérard

  50. Mitch 74 says:

    @Gérard: I was using these known bugs (indeed, the P not self-closing bug has been partially fixed) as an example of how bad standards support can lead to very difficult web programming when a browser claims to support standards, then runs away with them and produces unexpected behaviors.

    That’s what one would call a bug, right?

    The misnested tags example I gave is a more interesting example than one may think at first glance: yes, it is incorrect markup. Browsers may deal with it as they want (it is, after all, undocumented) but while Gecko, KHTML/Webkit and Presto may deal with this case differently, they will at least produce a valid DOM tree – while IE, up to version 7 (I haven’t tested version 8 in that regard) will produce an invalid DOM tree, with a branch grafting itself upon its sibling – making iterative processes go completely ga-ga.

    Which may have the dire consequences I described in my above post: endless loop.

    Now, all these bugs may have been solved in IE 8 (at least in Edge mode), but my point (which wasn’t very clear I admit) is that, because someone someday allowed an illegal construct to happen (inline tables, misnested tags still interpreted), we now risk ‘breaking the web’ every time a fix is required that is made much more difficult by these exceptions – and right here, the IE team allows a fundamentally wrong CSS syntax to be parsed by its ‘strict’ CSS parser.

    Just imagine that CSS 3 (or 4) creates a ‘filter’ property that can take a value; said filter, let’s imagine, is actually a piece of programming with some logic (with all the 3D craze going on in UIs these days, it could even be a pixel shader). Now, current CSS basic rules require such string values that can contain spaces to be quoted.

    Now, a distracted developer forgets the quotes in 2012, and his filter (which is ignored by all browsers for being wrongly written) would cause IE 8 to hang (bear in mind that in 2012, Windows 7 will still be supported, so IE 8 will be, too) even though IE 8 now has a less-than-2% market share (IE 9 was successful, see); but since it’s now a minority browser, he (the programmer) doesn’t catch on.

    Then, a high profile website, grabs his code and displays it; for whatever reason, said website uses X-UA-compatible:IE=8.

    An suddenly, IE 9 crashes every time said code is loaded, because its IE 8 mode loads the CSS rule, which is incorrect per the CSS syntax (it was discarded by IE 9 Edge, which supported standard ‘filter’ but disqualified its unquoted value), but ‘seems’ correct per the IE 8 ‘filter’ property syntax; however, it now hits upon a component that takes ill to what is actually asked of it, it enters a recursive loop or causes a buffer overflow…

    And because of a bad design decision in IE 8 RC1 in early 2009, in 2012 a few thousand browsers will crash.

    After all, nobody will ever make use of the ‘filter’ property, right? Like nobody will ever recursively browse a DOM tree.

  51. <blockquote>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.</blockquote>

    Are you kidding me? The only reason we’re in this mess is because IE absolutely refuses to bite the bullet and fix what’s broken. Backward compatibility is not essential. Backward compatibility inside of standards is essential.

    IE is being left to rot in terms of innovation and features. Inside of 10 years, the question is going to become "Do I want the Gecko engine or the Webkit engine?" because no one is going to give IE a second thought. And since these technologies are open-source this time around, you’re going to have a hard time buying your way back into the market like you did with Netscape.

    The only shot IE has of staying relevant is embracing standards more emphatically than the other guy. Javascript speeds available in Chrome, Mozilla and Webkit is virtually out of your grasp, they’re also already implementing the HTML5 spec and CSS3 elements. What have you done? Worried about backwards compatibility and proprietary CSS filters?

    IE is living in the dark ages. Fix it.

  52. Dan says:

    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.

  53. Mitch 74 says:

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

  54. Alahmnat says:

    Since this is the CSS Corner, 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 and footers without using a JavaScript library like jQuery? (Don’t get me wrong, I loves me some jQuery, but it’s a completely unnecessary layer of complexity for something that’s 100% achievable with CSS 2.1 and proper application of THEAD and TBODY tags.) And the CSS expression-based hacks out there don’t work in IE8 unless I make it fall back to the IE7 rendering engine, which causes its own collection of problems I then have to muddle through.

    At least IE8’s CSS implementation doesn’t create a single table row the entire height of the table I want to be able to scroll through, without actually making it scroll, so I only get one row of data (this was IE7 and below). Now it gives me as many rows as it can fit into the height of the table, but STILL doesn’t give me a scrollbar with the overflow property set to require one.

    Seriously, though, why is this still not working? 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 and stop wasting hours trying to come up with a "cross-platform" solution (by which I mean something that IE will actually support without breaking it in every other browser) that’s less elegant and functional across the board.

    Web development seems to be the only place where Microsoft is still trying to appeal to the lowest common denominator, rather than give actual developers the tools and rendering engine they need to get the job done without losing all of their hair. As much as I appreciate diversity in the marketplace, developers and consumers of web-based projects are poorly served when the majority product in that marketplace is several years behind the rest of the pack in terms of capabilities and standards support. 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, if only because it means I’ll have a less stressful job!

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

  56. Ag says:

    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.

  57. Greg says:

    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/

  58. Christian says:

    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.

  59. sroussey@network54.com says:

    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.

  60. @sroussey

    > you could break the CSS2.1 standard by including a little bit of CSS3 here and there

    The problem with such decision is that IE Team would then open the door to other/more requests and then you would see lots of people requesting more and other things: border-radius, application/xhtml+xml support, canvas, etc.

    Already there are people who strongly believe there should be an RC2. Again, same problem. After shipping a RC2, there are chances/possibilities there would be people asking for a RC3.

    Once RC1 was released, it was made clear that only bugs or issues selectively chosen (limited list) (sorry, can’t find the correct wording for that [1]) would be fixed before final release.

    Bottom line is this: IE Team and IE project managers have to draw the line somewhere and, in major projects (rebuilding an entirely new rendering engine is a major project), this is usually done at design requirements definition time, not after.

    Customers should not decide mainly because they do not see what is behind the counter and their position is quite different regarding the business, budget, plans, etc.

    The problem is not that IE 8 RC1 does not support opacity or that final release will not

    support opacity: it’s the code necessary to "call" it that will be different and not W3C web standards. So, it’s already debattable, quite relative how and why implementing opacity according to CSS 3 would make a huge, significant difference.

    regards, Gérard

    [1] "report any critical issues (e.g., issues impacting robustness, security, backwards compatibility, or completeness with respect to planned standards work). Our plan is to deliver the final product after listening for feedback about critical issues.

    We will be very selective about what changes we make between the next update and final release. We will act on the most critical issues. We will be super clear about product changes we make between the update and the final release. "

    blogs.msdn.com/ie/archive/2008/11/19/ie8-what-s-after-beta-2.aspx

  61. webdesigner says:

    Firefox 3 uses SVG filters. I think that’s the way to go.

  62. David says:

    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.

  63. web says:

    Fix opacity already. This is a joke.

  64. Magnus Markling says:

    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)

  65. Mitch 74 says:

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

  66. Matthew Raymond says:

    I have a few comments…

    1) -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.

    2) 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.

    3) 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.

  67. rpflo says:

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