Improving the CSS 2.1 strict parser for IE 7


We’ve already started talking about a few of the CSS changes that are going to be available in IE 7 when we release, but there are a few hanging points that we haven’t talked about yet or haven’t covered completely. There are 3 specific items I’d like to talk about:

  • Using the root node wild card selector for IE only rules (* HTML) [strict mode only fix]
  • Multi-class selectors as defined by CSS 2.1 (.floral.pastel) [strict mode only fix]
  • Pseudo-element parsing sometimes flags rules as invalid (P:first-letter{ color: red; }) [strict/quirks mode fix]

Root node selection:

To be very clear the root node selector was a bug. This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore.

The root node selector has long been used to create rules that only work in IE. The general pattern would be to write rules that would match in all browsers first. Then use the child selector logic ( > ) to create more specific rules that would match only in browsers that supported these selectors. Prior to IE 7 we didn’t support these selectors so they were transparent to us. Finally, you would apply rules that would only match in IE by using the * HTML pattern to match the root node. Since no other browser supports or contains a node in the DOM located above the HTML node these patterns wouldn’t match.

So what happens when we start to match child selectors in IE 7? Well, it makes a big mess because we now match more rules not meant to be used from within IE and then those are merged with IE only rules. Because of the merge styles that were never meant to be combined end up changing the layout of the page away from what the author originally intended when they designed their cross browser matrix and testing patterns.

The best fix here was to disable the root tag matching logic because it wasn’t supposed to work according to the standards. We only do this in strict mode, since the new selectors only match in strict mode, and so we now use the same sets of rules that other CSS 2.1 compliant browsers would use and we ignore the IE only rules resulting in a page that will lay out as designed by the author. There are a few issues with this when we differ in our interpretation of the spec from other browser implementations but most of the time these are minor and have easy workarounds.

An article on peachpit by Molly Holzschlag contains further examples detailing how this works.

Multi-class selectors:

When the class selector support was originally written it was drawn up based on the CSS 1 spec which only supported a single class selector in each simple selector. We wound up keeping this behavior even after implementing portions of later versions of CSS. The end result is that we always threw out the extra classes in the selector and only kept the last one in the list and matched based on that.

Well, some sites use multi-class selectors so when we looked at doing CSS 2.1 selectors work it was pretty easy to upgrade our class selectors to allow more than one class to be applied. When in strict mode we now obey all specified class selectors per simple selector. While you won’t often use the feature it can be used for some interesting applications. One of my original test cases would use combinations of red, yellow, and blue classes to paint elements based on their combined color. A selector such as .red.yellow would paint and element orange if it contained both of these classes in a space separated list within the class attribute. Any elements not matching at least both of these wouldn’t match and so you can more accurately apply hierarchical styles.

DHTML Kitchen has a great example of multi-class selectors and the current compatibility problems.

Invalid Pseudo-Element selectors:

We applied a very, very strict interpretation of pseudo elements in our parser and this would cause certain constructs to get thrown out. Basically we asserted that any pseudo-element had to be the very last thing in the selector. The spec only really mentions that there can be only one pseudo-element per selector and it must appear in the last simple-selector within the selector. Because of our strict interpretation if we saw any non-whitespace character or token after we just processed a pseudo-element we’d throw an error flag into the rule. This gave us the following behavior:

  • Fail – P:first-letter{ color: blue; }
  • Fail – P:first-letter:hover { color: blue; }
  • Succeed – P:first-letter { color: blue; } /* note the space */
  • Succeed – P:hover:first-letter { color: blue; } /* note the ordering */

The parser is much more intelligent about when and how it applies the error flag in IE 7 and the two failures you see will now succeed. Truly invalid rules will still fail and you have to be careful not to apply multiple pseudo-elements or apply pseudo-elements that are in simple selectors that are in the beginning of a complex selector.

For a clear example of this issue you can take a look at an article on MaxGeek.com.

Moving Forward:

These small issues that made writing web pages according to spec a trial-and-error situation have been fixed for IE7. By improving the parsing logic it becomes more obvious how your selectors should be written and existing W3C documentation can be used to quickly come up to speed. It should be easy to introduce interesting layouts and formatting in your web pages without having to specify custom rules for each browser and hopefully IE 7 comes one step closer to making that a reality.

 – Justin Rogers

Comments (118)

  1. Anonymous says:

    The removal of the * html selector worries me slightly, but if you’ve done a decent job of correcting the rest of the engine, it shouldn’t be a problem. I look forward to it with interest 🙂

  2. Anonymous says:

    There’s been a massive improvement in the quality of this weblog recently. Thanks guys.

    Like Olly, I don’t like the fact that the * html hack has been removed. It just seems like compliance for the sake of it. Sites using hacks in Strict mode are going to have to be updated no matter what.

    There is going to be a need for CSS hacks for Internet Explorer 7. The * html hack in conjunction with html>body was an easy one until you took away * html.

    Conditional comments are an imperfect solution. They force you to either bloat the size of the HTML documents, or use an additional external resource. CSS hacks don’t, making them more efficient in terms of requests to the server, compression, and caching. Yeah, it’s only a few K here, a few K there, but it all adds up, both in terms of load on the server, and in terms of slowing down your website, especially for mobile/dialup users.

    In particular, the problem you cite could be fixed by the page author by simply moving the Internet Explorer 6 only rules to above the compliant browser rules in the stylesheet. I’ve always coded this way, I don’t agree with your assumption that the other way around is typical.

  3. Anonymous says:

    This is great news.

    I’m sure some people will complain about the removal of the * html hack, but it is just that, a hack. Its a *hack*! Browser makers fixing these *bugs* is precisly why many of us have been warning against the use of parsing hacks for some time now. Especially when there are cleaner methods of targeting a specific browser that allow the preservation of compliance.

    I, for one, am happy to see it go, and will be extremely pleased to find less of this nonsense polluting the stylesheets that I have to maintain and review.

    No matter what, IE7 is going to be a different browser. It’s going to require extensive testing and planning regardless of which parsing hacks continue on. With any luck, it’ll be easy to switch off most IE6 hacks, and we’ll see the web move forward with a more standards-compliant IE.

  4. Anonymous says:

    Great work so far. I’ve been pro removal of the * html hack as well, since I think it’s not going to be necessary anymore. If you need to cater to IE only, use conditional comments instead. There’s not that much of a difference anyway.

    As for the relaxing on pseudo elements, I don’t think it can hurt what you’ve done with it. We all get annoyed by a missing space or a wrong order of elements.

    I really think IE is going in the right direction now. I’ve cursed a lot at it in the past years for things not working correctly, but it finally seems IE7 is going to be a huge improvement in terms of standards. Truly, good job.

  5. Anonymous says:

    Good things 🙂

    But what about other selectors ? a[hreflang~=fr] and the other : http://www.w3.org/TR/REC-CSS2/selector.html 🙂

    Great Job, I hope we can make website for IE7 with interesting CSS 🙂

  6. Anonymous says:

    Removing "* html" is a brave decision. I hope you have also removed all _reasons_ for this hack.

    If "hasLayout" haven’t been documented for historical reasons, you should leave some convenient hack (conditional comments are good, but usually too much hassle)

    I hope your fix for multiple classes won’t cover IDs as well. This is very useful hack:

    foo#bar#baz

    matches

    <foo id="baz">

  7. Anonymous says:

    Oh my,this looks very interesting,we’re seeing the commitmnet guys,we’re seeing it! 🙂

    keep it up!

  8. Anonymous says:

    >This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore.

    Harsh!

  9. Anonymous says:

    ROFL

    "To be very clear the root node selector was a bug. This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore."

    Was this post put up on Friday so Chris didn’t get a chance to hit you all long-weekend?

    Great post Mr. Rogers, very informative and good links to resources for the serious developers in the crowd.

    Keep up the great work!!!

  10. Good. Death to hacks.

    People who want conditional CSS can still do something like

    <!–[if IE ge 6]–>

    <link rel="stylesheet" href="ie6-or-better-stylesheet.css">

    <!–[end if]–>

    <![if IE lt 6]>

    <link rel="stylesheet" href="not-ie6-or-better-stylesheet.css">

    <![end if]>

  11. Anonymous says:

    [To be very clear the root node selector was a bug. This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore.]

    Was that REALLY needed?

    [Fail – P:first-letter{ color: blue; }

    Fail – P:first-letter:hover { color: blue; }

    Succeed – P:first-letter { color: blue; } /* note the space */

    Succeed – P:hover:first-letter { color: blue; } /* note the ordering */]

    :thumbsup: these are important and convient Technical fixes – also, the ORDER of the

    a:

    link vlink alink and hover will make a Fail or Pass difference

    THANK YOU

  12. Anonymous says:

    theoretically, if the finalized rendering engine is every bit as good as firefox & safari… we should be able to leave our current style sheets containing * html in place and not have a thing to worry about in IE 7.

    Besides, * html will still be needed for a few more years until the majority of windows machines no longer use IE6.

    As someone else said, this is a sign of commitment. From here on out it’s either get the rendering engine perfect or go back on their word and continue letting * html do what we’ve used it for even in IE7 standards mode.

  13. Anonymous says:

    "One of my original test cases would use combinations of red, yellow, and blue classes to paint elements based on their combined color. A selector such as .red.yellow would paint and element orange if it contained both of these classes in a space separated list within the class attribute."

    *combined* color?!?! while "cool", that doesn’t sound like a correct way to handle color assignments in multiple class names. would that only work for the color properties? how would it work for other props… like margin?

    i’ve used multiple classes on elements to accomplish something like this: suppose there are a variety of elements on a page, each with a different class. each class specifies a certain kind of layout (color, dimensions, etc.). another class, "Inverse", can be added as a secondary class to an element to switch the colors (to black on white instead of white on black). to accomplish this, the color and background-color properties are overridden in the Inverse class definition. in this scenario, i would most certainly not want (nor expect) both the color and background-color to turn 50% grey!

    does this "test case" confuse and/or surprise anyone else?

  14. Anonymous says:

    Very nice post, glad to see such great progress is being made for IE7. One question though, can someone explain to me what this means? Or give a URL?

    >> you have to be careful not to apply pseudo-elements that are in simple selectors that are in the beginning of a complex selector.

  15. Anonymous says:

    >> Was that REALLY needed?

    Yes, it was funny.

    I’m sure Chris is on to bigger and better things now. 🙂

  16. Anonymous says:

    <blockquote>*combined* color?!?! while "cool", that doesn’t sound like a correct way to handle color assignments in multiple class names. would that only work for the color properties? how would it work for other props… like margin?</blockquote>

    I think he means that there was a stylesheet with rules like

    .red {

    color: red;

    }

    .red.yellow {

    color: orange;

    }

  17. Anonymous says:

    If these are strict-mode-only fixes, what happens if the user isn’t in strict-mode?

  18. Anonymous says:

    hey guys,this post isn’t suitable here,but i don’t know where to give this suggestion

    -The ability to merge separate windows into tabs for IE7

    this will be awesome

  19. Anonymous says:

    Cyril-

    I wasn’t particularly clear in my last post, I suppose (http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx) – I believe we’ve added ALL the CSS 2.1 selector types, [hreflang~=fr] included. (Justin, you should confirm.

    As for the comment about letting me touch the code, I told Justin I was responsible for that one, and I saw his post before it went out. He’s done enough great work on our CSS support for IE7 that I’m going to be the last person to smack him for harshing on my six-year-old code. 🙂

  20. Anonymous says:

    [To be very clear the root node selector was a bug. This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore.]

    That is not polite to write it. Even if he is guilty for that bug, nobody else tried to fix it since then. So forget the past and work as a team.

    But with all the information you provide about IE7 I’m very much looking forward to the final version. It’s going to be a great come-back for IE and it’ll be even better in Vista. Great work, can’t wait to get it!

  21. Anonymous says:

    Are you going to support :before and :after ?

    I’m glad you went that way with the * HTML

    You’re doing it guys, I’m actually getting entusiastic on this bug free IE coming up. [even thow this should have been done some time ago, I’ve jsut spent the last 2 or 3 years pestering about this particular piece of software and it’s mother company] [not to forget also that we’ll still have to code for the older versions for quite some time now]. But yes, you are going the right way, as shows your involvement with WaSP.

  22. Anonymous says:

    Poor old Chris 🙂

    You mention the first-* pseudoelements yet use pseudoclass notation in your selectors. Are you going to be supporting CSS3’s "::" pseudoelement notation?

    http://www.w3.org/TR/css3-selectors/#pseudo-elements

  23. Anonymous says:

    "This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore."

    ROTFL!!!!! The truth, finally, after all these years 🙂

  24. Anonymous says:

    There’s an article on the IE Blog about the CSS parser bugs they’ve fixed for IE 7. It’s interesting that they are having to choose which parser bugs to fix, and in which modes, because people rely on those bugs as ways to &quot;detect&quot; particular CSS problems which only occurred in IE 6. Worse, there isn’t generally a 1:1 match between parser bug and CSS bug (although there are some objections, such as the Box Model Hack). Why is taking advantage of particular parser bugs any better than conditional comments, or user agent sniffing, which has long been considered harmful?…

  25. Anonymous says:

    Careful! The fix you describe for the pseudo-elements is not quite right. The following *should cause a fail*:

    p:first-letter:hover

    The rule is that one pseudo-element may be appended to the last simple selector in a chain, in which case the style information applies to a subpart of each subject.

    So the following are valid:

    P:first-letter,DIV{}

    P:first-letter,DIV:first-letter{}

    P.foo:hover:first-letter{}

    …but the following are INVALID:

    P:first-letter DIV{}

    P:first-letter:first-letter{}

    P:hover:first-letter.foo{}

    P.foo:first-letter:hover{}

    P:first-letter.foo:hover{}

    All of those in this last list should cause the entire rule to be ignored.

    E-mail me if you need more info or tests: ieblog@hixie.ch

  26. Anonymous says:

    IE7はCSS2.1を出来るだけサポートするみたいです。

  27. Anonymous says:

    First, thanks for sharing this explanation and spotlighting these three items. It’s important stuff to be aware of, no question. Keep it up! Working across IE7 and IE6 might not be the easiest nut to crack, but we can all see the forward motion and that is terrific.

    Second, good catch there Ian!

    Finally, that Chris Wilson reference was a riot, and I trust there are no hard feelings there in the slightest. (For context: Chris is "the lead program manager for the web platform in IE" … and "NOT Chris Wilson the drummer for Good Charlotte." Recall that Chris also made the first truly <a href="http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx">action-packed CSS post</a> on ieblog – which Justin even goes so far as to link back to at the start of this post. Let’s hear it for conceptual continuity!)

  28. Anonymous says:

    Gaah – the embedded markup in the last post didn’t quite render as I expected. Try this:

    http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx

  29. Anonymous says:

    Thanks for describing this.

    Could you please tell us if you’ll work on the way Internet Explorer treats the !important statement :

    In the current versions it is not taken into account when the property is stated again with a different value in the same rule. Will you improve that behaviour in standards and/or quirks mode ?

    And will you work on the fact that the xml prolog switches IE to quirks mode ?

  30. Anonymous says:

    I wonder exactly what "strict" mode is.

    It seems better to make these fixes applied in all XHTML DTDs. (including "transitional")

    I hope you have added attribute selectors also.

  31. Anonymous says:

    IE Team wrote:

    > Fail – P:first-letter:hover { color: blue; }

    While I’m pleased you’re adding more standards support for CSS and fixing some selector bugs, please don’t introduce more. That one is *invalid* and *MUST* fail. DO NOT "fix" it in IE7!!!

    Pseudo-elements are only allowed to be appended to the end of the last simple selector in the chain, and *must not* be followed by any other attribute selectors, ID selectors, or pseudo-classes. This is true for both CSS2.1 and CSS3 Selectors.

    http://www.w3.org/TR/CSS21/selector.html#q2

    http://www.w3.org/TR/css3-selectors/#selector-syntax

    If you feel this is a short-coming of CSS, please take it up with the CSS WG, but please don’t violate the spec.

  32. Anonymous says:

    And once again a great thank you to the IE team, intelligent and interresting writing on what goes under the hood for us to know, and insight of the way you guys work.

    You Go Guys, thanks to you the web may soon become a much better works for web devs to live in, and much more interresting from the client side of the rendering engine. You rock.

    > does this "test case" confuse and/or surprise anyone else?

    It doesn’t, it’s just a test for heck’s sake, what’s simple than checking if <span class="red yellow"> is as orange as it should be?

    It’s a *test case*, it’s not supposed to be semantic or anything, it’s supposed to be… well… testing

    > If these are strict-mode-only fixes, what happens if the user isn’t in strict-mode?

    IE7 will behave as IE6-quirks I guess, since it allows the engine to not break non-standard websites and hacks for that behaviour.

    > That is not polite to write it. Even if he is guilty for that bug, nobody else tried to fix it since then. So forget the past and work as a team.

    You should turn on your Joke Parsing engine or something, because you obviously missed The Funny

    > I wonder exactly what "strict" mode is.

    Quirks and Strict modes were introduced in the world by IE5/Mac, fathered by Tantek Celik. The goal was to allow for high-level standard compliance (in strict mode) while not breaking the "legacy" behaviour of the IE4/NS4 ways (Quirks mode), it’s done via Doctype Switching. The right doctype will trigger Strict mode, a wrong one or none will trigger Quirks, and some browsers have an "almost strict" mode that doesn’t do much but keep image in block mode (images should be displayed inline, not as block, as default behaviour in strict)

    Check Quirksmode’s page on the subject (http://www.quirksmode.org/css/quirksmode.html) for more informations

    > It seems better to make these fixes applied in all XHTML DTDs. (including "transitional")

    no. What they chose is perfect, either you know enough as to have knowledge of Quirks/Strict and will realise what they mean and use them well, or you don’t and your page won’t get fubared by unexpected (although standards compliant) behaviour.

    As a final note/question to the IE Team: will the XML prolog still trigger Quirks mode in MSIE or has that (fairly stupid me think) rule been dropped?

  33. Anonymous says:

    Well, that’s the kind of post I like to read! You are doing great jobs guys. Continue like that.

    IE team rock!

  34. Anonymous says:

    I really appreciate the posts by the IE team in letting us know what changes are being made! I must say I am happy and agree with whats being said and I think IE7 will bring IE in general very close if not completely up to date.

    daybreaker…

    All browsers render HTML in either Quirks or Standards mode.

    Use this to detect which rendering mode your browser is rendering your page in.

    <a href="javascript:(function(){var mode=document.compatMode,m;if(mode){if(mode==’BackCompat’)m=’Quirks’;else if(mode==’CSS1Compat’)m=’Standards’;else m=’an unknown’;alert(‘The document is being rendered in ‘+m+’ Mode.’);}})();" ADD_DATE="1089763488" LAST_MODIFIED="1089763503" ID="rdf:#$+8vof1">Detect Rendering Mode</a>

    If your page is not rendering in Standards Mode then you DEFINITLY have to use an HTML validator to help you clean up your code (because you DO directly edit your code and not use some visual editor right? ;-)).

    The W3C has a validator available…

    http://validator.w3.org/

    There are other validators and for other things besides HTML markup.

    Quirks and Standards mode have no relation to HTML transitional and strict.

    HTML 4.1 Transitional

    HTML 4.1 Strict

    XHTML 1.0 Transitional

    XHTML 1.0 Strict

    XHTML 1.1

    So in short if they are talking about strict (or transitional) mode, they are referring to a specific level of (x)html. If they are speaking about quirks or standards they are speaking about how the browser complies to compliant code or how it handles non-compliant code.

    Non-compliant code is allowed to be subjectively rendered by the browser when in quirks mode. IE does a dam good job in this respect.

    Ultimately you will want to at least aim for HTML 4.1 Strict or XHTML 1.0 Strict rendering in Standards mode.

  35. Anonymous says:

    [To be very clear the root node selector was a bug. This was introduced by Chris Wilson back in IE 4 which is why we don’t let him work with the code anymore.]

    Now, maybe because english is not my mother language, or maybe because I don’t follow every single day the posts here.

    But if Chris Wilson is the same guy who leads the team, that comment has presumably to be taken as a joke, and that’s quite fine.

    But if this mr. Chris Wilson is truly somebody (else) that was dismissed because he introduced a bug, that comment would be appalling.

    I am inclined to believe the former hypothesis!

  36. Anonymous says:

    > If your page is not rendering in Standards Mode then you DEFINITLY have to use an HTML validator

    > to help you clean up your code (because you DO directly edit your code and not use some visual editor right? ;-)).

    Markup quality has no influence whatsoever in the rendering mode chosen by the browser.

    The only thing of importance to switch beetween strict and quirks is the DOCTYPE declaration.

    I therefore fail to see the logic in this declaration.

  37. Anonymous says:

    Great work guys,

    I have to have faith that the IE team are going to all of the usual places to test the code (positioniseverything, quirksmode etc.).

    If you have eliminated all of the major IE6 bugs and you get the same results as other browsers in the bug tests then I’m happy to know that the "* html" bug has been taken out.

    As for CSS 2.1 support, bravo, I’m well happy about this. Web development just gets a whole lot quicker & cheaper when you can use pseudo-elements, multi-class selectors and such and it can also contribute to cutting down on html/css document weight reducing server load and making things cheaper again.

    I do have one reservation though and it is this: How soon after IE7 is publicly released will it overtake IE6 as the dominant web leader? I’m sure I’m not the only one who would like to see it triumphed/marketed by Microsoft to get as many people as possible to upgrade in the least amount of time.

    Here are some suggestions;

    – Adverts, lots of adverts! (I’m amazed at how many adverts I still see for XP, despite it being released four years ago, transfer some of that marketing money over to IE7)

    – Bundle with Windows XP (SP2+IE7) retail/OEM

    – Make it an automatic download from Windows Update

    The sooner IE6’s numbers start dropping, the sooner the web (as a whole) can go somewhere exciting.

    Cheers;

    Poncho

  38. Anonymous says:

    >> If your page is not rendering in Standards Mode then you DEFINITLY have to use an HTML validator

    >> to help you clean up your code (because you DO directly edit your code and not use some visual editor right? ;-)).

    >Markup quality has no influence whatsoever in the rendering mode chosen by the browser.

    The only thing of importance to switch beetween strict and quirks is the DOCTYPE declaration.

    >I therefore fail to see the logic in this declaration.

    assert(page doesn’t render in standard mode != page markup doesn’t trigger standard mode);

    assert(page doesn’t render in standard mode = page is in standards mode but doesn’t render);

    That should reveal the declaration’s hidden logic…

  39. Anonymous says:

    Justin, while you were fixing the parser, did you fix this one too?

    p {color: yellow;}

    p#u.a {color: red;}

    p#u.b {color: blue;}

    <p id="u" class="b">This should be blue, but IE6 fails on p#u.a, but does not look at p#u.b for some reasons, therefore, it’s not blue, not red, but yellow.</p>

  40. Anonymous says:

    And what about some fun we had with #id’s and pseudo-elements?

    p#nonexistantid a:first-letter {color: yellow;}

    p#u a:hover {color: red;}

    <p id="u"><a href="#">This should be red on hover</a></p>

  41. Anonymous says:

    Will you be supporting the CSS3 convention of using two colons for pseudo-elements, not just the CSS2.1, single colon version? eg. ::before, ::after, ::first-line, etc. Other browsers already support this syntax, and it’s a very good habbit for authors to get into, as it clearly distinguishes between pseudo-elements and pseudo-classes.

  42. Anonymous says:

    Justin, a last question on these "bang-your-head-on-the-desk bugs" [Chris Wilson, July 29]:

    a {display: block;}

    p#nonexistantid a:first-line {color: yellow;}

    p#u a:hover {color: red;}

    <p id="u">

    <a href="#">Can you tell me please<br /> why only the first line<br /> does react on hover?</a>

    </p>

    The day all these bugs are fixed and gone (and no new issues are constructed, see the warnings in comments by Ian Hickson and Lachlan Hunt), I don’t think I’ll look back in melancholy, but I must say that I got used to them, somewhat, because of the "hacks" that were /so/ surprisingly intuitive:

    a:hover img {border: 1px solid fuchsia; }

    /* uncomment to fix it */

    /* a:hover {background-position: 0 0; }*/

    <p><a href="#"><img src="#" alt="hover" /></a></p>

    If IE joins the other browsers which actually allow for designing layouts that "would work ‘out of the box’", that would be a bright day.

    More time left for serious things like gardening, less time lost on the absurdity of fixing browser bugs.

  43. Anonymous says:

    Wouldnt it be more logical to use these as,

    P:first-letter:hover { color: blue; }

    It’s a hover only over the first letter in the P-tag, and the style would be apllied to the first-letter.

    — —

    P:hover:first-letter { color: blue; }.

    It’s a hover over the whole P-tag and the style applies to the firstletter.

  44. Anonymous says:

    And how about child selectors, sibling selectors and attribute selectors?

    div > h1 {…}

    h1 + h2 {…}

    input[type=text] {…}

    If you know a thing or two about more advanced CSS handling, you’re going to want these and you’re going to use the original IE7 (http://dean.edwards.name/IE7) if you can’t have them…

  45. Anonymous says:

    Thany –

    as stated in my previous post, we added the CSS 2 selector types, including all of these.

  46. Anonymous says:

    Guys get over the Chris Wilson comment. Chris already posted a comment. They are obviously friends and no foul was made.

    Thanks for the update, it sounds like things are moving along nicely. I have no time or intrest in beta testing Vista or IE7 but I am sure by the time the final version is released, IE will be a dream to work with.

    The biggest question that I have for the IE development team is.. <b>WILL any policies be made regarding the release of code fixes and updates that will let you guys continue to improve the software and add updates more often then the operating system is updated?</b>

    I am sure much is fixed and more will be fixed but there are certainly things we would like to see supported immediately after the IE7 release. CSS/W3C/Standards are not perfect, there are still many improvements that need to be made. So if we can have future standards supported it would make like easier the day after tomorrow.

  47. Anonymous says:

    Regarding "strict mode", could someone from MS clarify the situation with respect to DOCTYPE-switching?

  48. Anonymous says:

    Whilst I can’t see myself switching away from Firefox any time in the near to medium future, changes like this encourage me to think that IE7 will, at the very least, restore its reputation as a credible modern browser.

  49. Anonymous says:

    > We only do this in strict mode, since the

    > new selectors only match in strict mode

    Why?

    I still don’t see any justification for retaining this bug even in non-strict mode. Surely point is that the bug is only used to work around bugs which will in IE7 now not exist, so there should be no justification for retaining it in any mode, strict or otherwise.

  50. Anonymous says:

    Thanks for the info Justin. Removal of * html hack is the most correct thing to do. Anyone using this hack when better solution exists (cond. comments) deserves to waste some time to fix it. (Just as I did 1.5 year ago :)).

  51. Anonymous says:

    Okay, so can we have a 1px dotted line that really is a 1px dotted line now instead of a dashed one? Pretty please? 🙂

    I’m really glad to hear about all these fixes. Sounds like you’re going to make a lot of people happy (and a lot of websites encourage people to upgrade to a version of IE that works as it should for a change!)

  52. Anonymous says:

    > Will you be supporting the CSS3 convention of using two colons for pseudo-elements

    Lachlan, AFAIK IE supports this syntax just fine already. I have been using the double colon syntax for quite some time, well since I learned of it. I’m not aware of any bugs from the use of the double colon syntax. This working may be the result of a bug though, so it’d be great if the IE team could clarify this and say whether they intentionally have support for the double-colon syntax.

  53. Anonymous says:

    How about the trick used to get IE 6 in quirks mode (commenting before the doctype), eg.:

    <!– IE6 in quirks –>

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;

    Will IE 7 render in strict mode when this occurs?

  54. Anonymous says:

    Jasper…

    Anything before the Doctype will throw IE in to quirks mode, including an XML declaration.

    It would be most desirable to still have this behavior occur with the exception of having the XML declaration.

    As XHTML is a subset of XML the XML must (if you do so choose to use it) appear BEFORE the XHTML Doctype.

  55. Anonymous says:

    > Regarding "strict mode", could someone from MS clarify the situation with respect to DOCTYPE-switching?

    http://www.quirksmode.org/css/quirksmode.html

    While not the most extensive, this is probably one of the clearest resources on ther subject.

    > Why?

    > I still don’t see any justification for retaining this bug even in non-strict mode.

    > Surely point is that the bug is only used to work around bugs which will in IE7 now not exist, so there should be no justification for retaining it in any mode, strict or otherwise.

    If you know how to code, really, you will produce pages in strict mode. Always. You therefore will be aware of these backward-compatibility breaking changes (because they ARE breaking backward compatibility that Microsoft wants to maintain up to IE4/IE5’s behaviour). If you don’t, you may be relying on IE’s quirks without even knowing it, without trying to work around IE’s bugs but merely thinking that it’s a good way to code. And IE7 would break your website. And from everywhere on the web would the outbreak… well… break… that IE7 breaks T3h W3bz0r, which the IE team can’t afford to happen.

    This can be understood, and their decision to be as strict as possible in "strict mode" while still being lax in Quirks is a Wise One, for this was exactly the reason why Tantek and the IE5/Mac team created Quirks and Strict modes 6 years ago.

    > It would be most desirable to still have this behavior occur with the exception of having the XML declaration.

    > As XHTML is a subset of XML the XML must (if you do so choose to use it) appear BEFORE the XHTML Doctype.

    Even though I do agree with you, XHTML sent as text/html is not considered as XML, not even parsed as XML, it’s parsed as if it were HTML4.01 in whatever rendering mode you set. No more. No less.

    I’d still appreciate that IE stopped dropping to quirks when I use XML prologue, but the reason why it’s done that way I understand (basically, it never makes sense to send XML prologues to MSIE in it’s current state, or in any state ’till it handles MIME types in a stricter way, and understands XHTML as application/xhtml+xml at all.)

  56. Anonymous says:

    I wrote:

    > > I still don’t see any justification for retaining this bug even in non-strict mode.

    > > Surely point is that the bug is only used to work around bugs which will in IE7 now not exist, so there should be no justification for retaining it in any mode, strict or otherwise.

    Masklinn replied:

    > If you know how to code, really, you will produce pages in strict mode. Always. You therefore will be aware of these backward-compatibility breaking changes (because they ARE breaking backward compatibility that Microsoft wants to maintain up to IE4/IE5’s behaviour). If you don’t, you may be relying on IE’s quirks without even knowing it, without trying to work around IE’s bugs but merely thinking that it’s a good way to code.

    But we’re talking here about removal of the * html hack. You would only use that "If you know how to code, really". No bog-standard editor or lame HTMLer isn’t going to know anything about * html.

    In other words, the only sites using * html are ones which are using bugs to work round IE6- problems, which should be fixed.

    So why retain it under any doctype?

  57. Anonymous says:

    p#id

    But why should someone may want this?

    An id is already an unique identifier. Being unique, what is the point with localizing it within a container when it can just be addressed in a selector as

    #id

    Why should a browser be supposed to parse such a selector as the former? In principle, I see. But I can’t see the practical side.

    Any example where a selector such as p#id would achieve something that in no other was was possible or that a mere #id would allow?

    The only situation I can envision is if one flips nodes around.

  58. Anonymous says:

    Great Job with interesting features

  59. Anonymous says:

    Alberto – the same stylesheet can apply to multiple pages. Although an id must be unique to a page it doesn’t have to be unique to a set of pages. You could then have a p with id="id" on one page, and (for example) a div with id="id" on another, yet want to distinguish them in the stylesheet.

  60. Anonymous says:

    > But we’re talking here about removal of the * html hack. You would only use that "If you know how to code, really". No bog-standard editor or lame HTMLer isn’t going to know anything about * html.

    Problem is that this is a thing you think, not a thing you know, and this is a thing the IE7 dev team has no knowledge of. You can’t know if there ain’t some guy out there using * html for his styling.

    So the IE team took the secure stance of not modifying anything (but for clear bug fixings that shouldn’t "break" pages) from IE6’s quirk to IE7’s quirk. They chose the safe path of not taking any risk on that matter, and I do understand: they can’t afford to have people saying that IE7 broke teh intarweb.

  61. Anonymous says:

    > So why retain it under any doctype?

    Because otherwise it might break a site that’s made using CSS and relies on the hack but isn’t set up to render in strict mode. It only makes sense to remove the hack if the reasons that required its employment are removed too, and they are *not* removed in quirks mode. Breaking backwards compliance is not something the new IE should do.

    > Any example where a selector such as p#id would achieve something that in no other was was possible or that a mere #id would allow?

    Yes, higher specificity. p#id is more specific than #id.

  62. Anonymous says:

    Correction: compatibility not compliance.

  63. Anonymous says:

    Please make sure you incorporate the CSS Attribute Selector because when it comes to creating a style for a checkbox or a text field its impossible without adding a class to each, because they both use the same HTML tag (INPUT).

    But if we had the CSS Attribute Selector we could just specify a style for type=checkbox etc…

  64. Anonymous says:

    p#id#id2#id3.class#id4 p#id5 a .class2.class3#id9:hover:first-letter {font-family:’MS Sans Serif’;}

    IE 8 doesn’t interpret that correctly! I am very disappointed cuz it’s mission critical for my blog about the life of blue penguins in Congo.

    IE 8 is not standard compliant! It’s a mess! it sucks! I hate it! It forces me to rewrite all my perfect css! let’s all switch to Camino 0.0.0.0.209123, it rocks!

    🙂

    ok – just for a laugh in a while come on.

  65. Anonymous says:

    Good job, guys. Keep it up.

    "Any example where a selector such as p#id would achieve something that in no other was was possible or that a mere #id would allow?"

    The multi-page explanation someone else gave is good (and might also apply to dynamic pages where different elements might exist at different times with the same ID for whatever reason), but what came to my mind first was that p#id is more specific than #id. In a big, complex style sheet, you need every tool you can get your hands on to assert control over rule application.

    Besides, it’s nice for consistency: if p.class:hover works, it’s nice that p#id:hover works. Fewer rules for newcomers to learn.

  66. Anonymous says:

    Removal of the * hack is spot on. With all known major CSS glitches removed, IE7 will instantly use the standard CSS instead of the hacked styles. If you have used * html carefully to only fix IE CSS bugs, this is a win/win situation. Conditional comments are the proper way to address specific IE’s.

    I have missed news on DOM standard support, will we have addEventListener?

  67. Anonymous says:

    @Alberto, not exactly blue penguins, but nice flowers:

    http://host.sonspring.com/multi-class/

    http://sonspring.com/index.php?id=102

    But your satirical insert has some valid points, thanks. 🙂

  68. Anonymous says:

    Emrah:

    I agree with you here.

    Removing the * html thingy is a good thing because it immediatly makes code just wokr for versions prior to IE7.

    So if you used * html {} for IE only code, to fix its non-compliant behaviour OR if you used html>body {} to overwrite IE6-tailored code for compliant browsers you should be fine, ‘cuz IE7 will render as FF does now AND take over the same rules.

    This actually saves me from waking up at night having bad dreams about the launch of IE 7.

    So where’s the problem folks?

  69. Anonymous says:

    Emrah:

    I agree with you here.

    Removing the * html thingy is a good thing because it immediatly makes code just wokr for versions prior to IE7.

    So if you used * html {} for IE only code, to fix its non-compliant behaviour OR if you used html>body {} to overwrite IE6-tailored code for compliant browsers you should be fine, ‘cuz IE7 will render as FF does now AND take over the same rules.

    This actually saves me from waking up at night having bad dreams about the launch of IE 7.

    So where’s the problem folks?

  70. Anonymous says:

    Sorry for the double posting folks …

  71. Anonymous says:

    Dornavant, IE7 n’interpretera plus le &quot;Star Hack Html&quot; (premier exemple) et interpretera le Child Selector (deuxime exemple) tel que dfini par le W3C, exactement comme les autres navigateurs. En dfinitive, IE7 lira les mmes portions de code CSS que..

  72. Anonymous says:

    Voici exactement ce qu’ils ont modifi.

    * html{

    }

    Cette notation permettait, avant IE7, de passer des attributs spciaux qui seraient interprets uniquement par IE.

    A l’inverse, cette notation :

    html&gt;#elementid {

    }

    permettait

  73. Anonymous says:

    As a Web developer, I’m so excited about all of the CSS fixes in IE7!

    One thing I’ve been wondering a lot about, though (and haven’t seen mentioned anywhere yet), is IE7’s handling of the "application/xhtml+xml" MIME type. Please tell me it will support this! 🙂

  74. Anonymous says:

    "… it wasn’t supposed to work according to the standards. We only do this in strict mode, … CSS 2.1 compliant … a page that will lay out as designed by the author. There are a few issues with this when we differ in our interpretation of the spec from other browser implementations but most of the time these are minor and have easy workarounds."

    This passage bewilders me and seem confusing. You claim to be CSS 2.1 compliant rendering pages as "designed by the author", and then you go on saying that there are cases where you introduce different interpretations than the specification than CSS 2.1 compliant browsers ?

    Was the sentence just badly written with regards to logic, or for the malignant heck of not being CSS 2.1 compliant no matter what ?

    The internal joke about Chris being "on top in the project" and not coding was much easier to get …

  75. Anonymous says:

    It’s good that * html isn’t to be recognised but I can see problems occurring on many thousands of pages that use it to implement a min-height fix.

    As min-height/width doesn’t seem to be on the fixed list (even though it seems to be the one thing that everyone asked for) then anyone who has used the following will find their pages broken on ie7.

    #test{min-height:200px}

    * html #test{height:200px}

    Of course we can use conditional comments to supply height to ie7 (but why should we ?) but that also assumes that height is still to be interpreted incorrectly and will expand with content.

    Had min-height been implemented and height fixed then the above code would have indeed been transparent and caused no problems.

    It’s good that other major problems have been addressed though.

  76. Anonymous says:

    Something I’m curious about:

    You’ve said that you’re going to support CSS 2.1, when it goes to Rec status. Any word on CSS3 Selectors, which IIRC is also going to be going to Rec status around the same time?

  77. Anonymous says:

    I agree with the point about min / max width and height. I think that is very important, and that it absolutely needs to be in IE7. It really allows for some great website layouts.

    Also, if IE7 is really going to be standards compliant, we do we even need to have the * html selector at all?

  78. Anonymous says:

    &amp;#8222;Лошите&amp;#8220; Micro$oft все пак са решили да хвърлят нящолко трохи на уморените от проблеми уеб дизайнери. IE 7 ще съдържа и следните промени:

    Е

  79. Anonymous says:

    Will selecting alternate stylesheets be available?

  80. Anonymous says:

    Will selecting multiple stylesheets be available?

  81. IEBlog says:

    We are currently locking down IE7 for shipping and I wanted to give an update on the CSS work that…

  82. disney channel asia high school musical website