More Web Standards Tests Submitted to the W3C

Internet Explorer 8 represents a leap forward in support for web standards.  We believe that IE8 has the first complete implementation of CSS 2.1 in the industry and it is fully compliant with the current CSS 2.1 test suite.

The only way to know if a browser has correctly implemented a specification is to develop a comprehensive set of tests for the specification.  Those tests are the best reference for how a browser will behave when you’re writing a web page. 

Today, the IE Team is submitting 196 new test cases to the CSS 2.1 Working Group for inclusion into the CSS 2.1 test suite. These cases were developed since IE8 RC. This brings Microsoft’s contribution to the CSS 2.1 Test Suite to 7201 tests. IE8 passes all of these tests today as well as the rest of the tests in the current official CSS 2.1 test suite.  We’re working closely with the CSS working group to include the new tests in the official test suite. For now, these tests are available at the Windows Internet Explorer Testing Center.

I encourage other browser vendors to contribute to the W3C’s CSS 2.1 test suite so those tests may be used by any browser under the W3C’s license. Only then will those tests broadly benefit web developers.

If you have specific feedback on any particular test case, I strongly encourage you to provide it on the W3C’s CSS 2.1 Working Group’s mailing list. That will ensure the test case reviewers have your comments in context as they add these pages into the suite.  I'd like to thank everyone that provided feedback on the previously submitted tests.  We made changes to tests based on that feedback. 

Thanks for all the great support and feedback. Enjoy IE8!

Jason Upton
Test Manager – Internet Explorer

Comments (63)
  1. Hi, you’ve done great work on standard-compliance! It’s great relief for all web developers – Thank you for that! Are you planning to work on ACID3 test now? Your score in this test is currently very low in comparison to other browser vendors. But I’m sure that you can turn that in the next version;-)

  2. Daniel says:

    You have done great work.

    However, there are bugs in the implementation, even if it’s complete.

    If IE8 passes all those tests (which as far as I know, isn’t true at the moment), the test suite is incomplete.

    But don’t worry, everyone got bugs, and we’re going to file all of them 🙂

  3. David Naylor says:

    Oh, seems like three of those failed because of ClearType. Still, two fail with ClearType inactivated.

  4. Arron Eicholz [MSFT] says:

    @David Naylor

    Here are some details on each of the tests you mention: – This is a build issue bug with the test suite. See”> – This isssue most caused by ClearType being enabled. I actually pass this on all my tests machines with ClearType disabled. – This is a bug in the test case, see”> – This isssue most caused by ClearType being enabled. I actually pass this on all my tests machines with ClearType disabled. – This isssue most caused by ClearType being enabled. I actually pass this on all my tests machines with ClearType disabled.

    Also take a look at the other test case issues that have been raised on the official test suite. There are some test suite bugs in the official test suite that fail and need to be corrected.

  5. Julius says:

    heh heh – I would state that ClearType by itself is a FAIL.

    Can’t stand it at all.

  6. Julius says:

    @David – This one fails for me in Firefox *AND* IE8 (compat and standards mode)

  7. Mmm, great standards. After an upgrade IE8 no longer recognises my self-signed certificates from an internal ROOT Microsoft CA. My root CA certificate is on the list of trusted CAs – but still my website comes back with the standard warning. Perhaps a reboot is in order. Or perhaps I shouldn’t have upgraded after all. I notice when I race Google Chrome against the same website as IE8. Guess who opens quicker – substantially quick. Yes, its Google Chrome…

  8. Dave Nand says:

    @Arron Eicholz [MSFT],

    I have completely disabled ClearType in WinXP via the Display properties AND Internet Settings advanced section, and the characters displayed are clearly jaggy, but the test cases still fail in IE8. Any idea what more I need to do ?

    And to everyone else, anyone else can confirm that disabling ClearType can make IE8 pass those tests under WinXP SP3?

  9. Philip says:

    Unfortunately still fails, which breaks my page (‘expand’ links on ), so I guess the CSS 2.1 test suite isn’t as comprehensive as it possibly could be 🙂

    Still, it’s always nice to see tests and to see IE passing them – good work, and I hope this continues!

  10. zzz says:

    @Arron Eicholz [MSFT]

    I already had ClearType disabled, but to make sure I enabled and disabled it again. There was no effect on 64 bit Vista SP2RC with IE8 RTM. All the "This isssue most caused by ClearType being enabled" tests failed.

  11. zzz says:

    I even tried rebooting, and tests still fail. ClearType looked pretty bad even after tuning it. I’d take 184 DPI display over ClearType any day and just scale the bitmaps and text accordingly where necessary to maintain the size. ClearType is just a convenient excuse preventing the need to do release high DPI.

    Dead pixel issues also would go away with 184 DPI since the pixels would be so small as you wouldn’t notice a few dead pixels.

  12. hAl says:

    The tests do not just require cleartype disabled but really require the AHEM font installed to work.

    Download thte TTF file from here:

    and install the download file (rightclick => install)

  13. Daniel says:


    Some tests really do fail with ClearType, though..

  14. Font says:

    For the required fonts, please go to

    The standard and authorized tests from the, not an individual.

  15. Honestly, who are you guys trying to fool?

    IE8 does *not* fully support the CSS 2.1 spec. I have compiled a list of bugs in this final release at (there are more to be added).

    Please don’t release information like this, unless it’s actually true.

  16. gsnedders says:


    1, 4, 11a (you have two numbered 11), and 12 are not CSS 2.1 violations (1 is not defined anywhere, 4 is only a bug per the HTML 5 draft (and quirks mode detection may well change again…), 11a is not a violation because the glyph used is undefined, and 12, well, "CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them.".).

    Also, there is a subtle difference between full support and bug-free support. The likelihood of ever having bug-free support is low, as writing perfect code is somewhat hard.

  17. @gsnedders

    > 1 is not defined anywhere

    I have updated the testcase to reflect more closely the HTML 4.01, section 17.9.1 and quoted the relevant excerpt.

    From the beginning, IE Team has been receptive and has acknowledged in bug report (bug 348575) at connect’s IE beta feedback that this was a real bug which they wanted to fix. They reactivated bug 348575 yesterday.

    If you follow the letter of the spec, then focusing a checkbox should not activate it, should not toggle it… unless it is said so somewhere (I’ll do more searching later). But focusing a text input should make it focused like it can be focused in the Windows platform: ie blinking caret (I-bar) inside textbox should appear; same thing with any/all other focusable form input controls like textarea, radio buttons, etc.

    I just have to add

    input:focus {outline: 2px dotted lime;}

    and I’ll be able to report more variants of this bug.

    > 4 is only a bug per the HTML 5 draft

    No. A perfectly valid webpage using perfectly valid markup code, perfectly valid CSS code should render CSS width, CSS height and CSS padding properties of a block-level element as specified in the code. CSS 2.1 specification does not mention and does not specify to choose this or that broken CSS 1 box model anywhere in the spec. "Quirks" mode, "backward-compatible rendering mode", etc.. are nowhere mentioned in the CSS 2.1 spec.

    IE 7 and IE 8 are the only visual web browsers, claiming to be CSS compliant browsers, who refuse to render the CSS width, CSS height and CSS padding properties of a block-level element as specified in the code of the testcase in a compliant manner…. just because of such particular SGML comment.

    Yesterday, IE Team reactivated bugs 382800 and 354956 and for the correct reasons.

    > 11a is not a violation because the glyph used is undefined

    CSS 2.1 spec. clearly indicates that the initial, default list-stype-type must be a disc.

    "Glyphs are specified with disc, circle, and square. Their exact rendering depends on the user agent."

    The rendered list-marker in the provided testcase with IE 8 does not even have the shape of a disc!

    On top of that, it certainly looks like a regression from IE 7. The section on list-style-position even provides an example of how may look a disc list-marker (it is a small filled disc)

    and this is what IE 7 was using too, how IE 7 was rendering a list-marker disc. So, why would you refuse to view this as a bug and a regression then?

    regards, Gérard

  18. Bob says:

    Um, why would you guys keep commenting here instead of going to the real CSS working group list and having the discussion there?

  19. Discussing tests (valid|invalid, correct|incorrect) in a CSS 2.1 test suite (complete|incomplete) is one thing. Right now, Arron Eicholz [MSFT] claims that IE 8 passes all of the valid tests in the CSS 2.1 conformance test suite.

    Having real bugs in IE 8 (reported by real people – Batiste Bieler, Ingo Turski, Philip A. Hagen – regarding real webpages) fixed is another and is equally important: it’s about real, practical web development.

    regards, Gérard

  20. gsnedders says:


    "So, why would you refuse to view this as a bug and a regression then?" — I never said they weren’t bugs. I said they weren’t CSS 2.1 bugs.

    With regards to one, the question is what having focus means: does clicking on an element give it focus? It’s certainly internally inconsistent with other IE behaviour in terms of IE’s behaviour, and it certainly violates HTML 5, and should certainly be fixed, but it isn’t a CSS 2.1 bugs.

    All browsers violate CSS 2.1 for certain conforming documents (try the HTML 4.01 Transitional DOCTYPE with no system identifier — that triggers quirks in all browsers, yet is entirely conforming). Quirks mode in general does not exist outside of HTML 5, but the vast majority of the web relies upon it, so can’t realistically be changed. There are going to be certain conforming documents that trigger quirks mode, as there are in other browsers, which is inevitably non-conforming (by definition). HTML 5’s parsing algorithm is starting to settle down so hopefully we’ll start to get interoperability on quirks mode triggers soon. I don’t regard it as a CSS 2.1 bug as it involves quirks mode, which is needed for compatibility and cannot really be changed, and with nothing specified about it I regard that as an issue with the specifications (namely, HTML and CSS, though HTML 5 rectifies it from an HTML POV).

    Finally, for 11a, as you quote, glyphs are specified with those three values. What glyph, however, is not specified. I see nothing in the spec that requires a disc-like glyph to be used for "disc". This is what I believe the second sentence you quoted to mean (i.e., a user agent can use any glyph is wants for one of those identifiers). Needless to say, it is blatantly a bug (and will effect real websites, and really should’ve been fixed for RTW), but not a CSS 2.1 conformance issue as far as I can see.

  21. EricLaw [MSFT] says:

    @Mike Laverick: IE8 uses the same certificate-handling code as IE7.  What is the exact text of the certificate warning page?


  22. Arron Eicholz [MSFT] says:

    @Dave Nand & zzz:

    In order to run all the test suite cases you will need to install the Ahem font in addition to disabling ClearType and font smoothing.


    You are correct I am stating that we pass all the valid test cases from the official W3c CSS 2.1 test suite along with the additional 7201 cases I have submitted to the W3c CSS 2.1 test suite.

    @James Hopkins:

    We committed to passing the official W3c CSS 2.1 test suite. I would recommend that you submit your cases to the CSS test suite and get them accepted into the official test suite.



  23. Arron Eicholz,

    Some tests appear or may be too unspecific regarding expected layout results. I mean here that the expected results may be quite tolerant, lenient.

    Some tests assumed something that isn’t in the spec. 2 examples:

    Test 6763: Setting a percentage ‘height’ on cell computes to ‘auto’

    Test 6764: Setting a percentage ‘height’ on row computes to ‘auto’

    There is nothing in the spec indicating how or where the extra space should be going, allocated, how they should be distributed.


    CSS 2.1 does not define how extra space is distributed when the ‘height’ property causes the table to be taller than it otherwise would be


    So, in tests 6763 and 6764, the

    blue and black boxes could be using/occupying the same height. In fact, that is what happens too when in Trace Style, the user removes the declaration (for #row) height: 25% or changes it to height: auto.

    Bug 414815 lists 4 tests which, as written, defined, testcase-ed, fail in IE 8. I tried to provide an alternative in my 19/02/2009 comment.

    IE 8 final release (build 18702) does not support media-dependent @import rules (section 6.3): that’s bug 354316.

    regards, Gérard

  24. hAl says:

    @Gerard Talbot

    Now that a final version has been released it would be better to archive the solved bugs and

    on your page display only the actual bugs.

    The page is now very misleading stating over about 230 bugs for IE8 whilst it might be actually only 40 or 50.

  25. Mark Turner says:

    "We believe that IE8 has the first complete implementation of CSS 2.1 in the industry and it is fully compliant with the current CSS 2.1 test suite."

    WRONG, passing the current CSS 2.1 test suite that tests only less than half of the CSS 2.1 specs does NOT mean you have a complete implementation of CSS 2.1 NOR full CSS 2.1 spec compliance, SO

    "fully compliant with the current CSS 2.1 test suite" Yes

    "complete implementation of CSS 2.1" NO

    "Internet Explorer 8 is fully compliant with the Cascading Style Sheets (CSS), Level 2 Revision 1 (CSS2.1) specification" A BIG LIE

    For example, IE8 still fails a simple test of the font-weight property :

    So how can IE8 have "complete implementation of CSS 2.1" or "fully compliant with the Cascading Style Sheets (CSS), Level 2 Revision 1 (CSS2.1) specification" when it still isn’t fully compliant with a simple CSS property like font-weight?

    BTW, I know no other browser pass this font-weight test yet, and this simple font-weight test is not included in the currnet offical (and far from complete) CSS 2.1 test suite, but the point is, IE8 should ONLY claim "it is fully compliant with the current CSS 2.1 test suite", but NOT "the first complete implementation of CSS 2.1 in the industry" NOR "fully compliant with the Cascading Style Sheets (CSS), Level 2 Revision 1 (CSS2.1) specification"

    Full compliance with the current official (but incomplete) CSS 2.1 test suite does NOT equal to full compliance with the CSS 2.1 specs. Thank you.

  26. hAl says:

    @Gerard Talbot

    Looking at some of the remaining bugs on your page.

    I do not see what is wrong with this bug:

    13- tbody {height: 150px; overflow: auto;} does not work

    I do not see what is the expected result on this bug:

    14- document.getElementById(SelectList[SelectIterator]).add(objOption, null);

    Is lacking support for something a bug:

    16- Support for cssFloat

    And could you reference where this bug violates the specs:

    29- Formatted alternate text is not implemented

  27. Wil says:

    The answer is NO. This is not a W3C valid page…

    You might wonder, why sends in the tests to the W3C, and who doesn’t validate the website.

  28. Thomas says:


    The blog code and the IE code aren’t written by the same people.


    The testcase in Gérard’s bug 13 quotes the spec that allows this. However, it is true, that this shouldn’t work per the current CSS 2.1 CR.

    @Mark Truner:

    Complete means that every property is supported. It doesn’t meant that there are no bugs. Every browser got bugs. And only filing them in a useful manner will lead to a fix for those bugs.

    @Gérard Talbot:

    I agree with hAl, that your IE8n page is full of no longer useful information. I suggest to create a page that lists only bugs that are currently exposed in IE8.

  29. Richard Fink says:

    I would like to know in what way Cleartype and/or font-smoothing would interfere with the correct rendering of the spec.


  30. eghost says:

    THANKS! A lot of hard work by the IE Team,  Now I do have to admit I will not be using it.  For me it has to many short comings,

    A) With the UI; hopefully Microsoft will unlock the UI in IE9, but some how I doubt it.  

    B)Web Standards compatibility, it close, but not quite there compared to the competition.

    C) Lastly plug-in’s   Fire-Fox, has IE blown away with Plug-in’s.

    In closing, Still great job, you can’t please everyone….

    Now here’s the real question, when or where can I down load the alpha of IE9……. 🙂

  31. @hAl

    > better to archive the solved bugs and

    on your page display only the actual bugs.

    I entirely agree with you. I have been wondering how to do this… because bugs have their own bug numbers (id="bug34") and links may fail if I change the numbering.

    regards, Gérard

  32. "what is wrong with

    13- tbody {height: 150px; overflow: auto;} does not work"

    The test should create a scrollable tbody where the thead and/or tfoot information remains "in view".

    "expected result on

    14- document.getElementById(SelectList[SelectIterator]).add(objOption, null);"

    It should create a select with 6 options. Instead, IE 8 pops up a Web error critical message (assuming you have script debugging enabled and display notification about every script error option checked)

    16- Support for cssFloat: I need to explain better what is this bug about

    29- Formatted alternate text is not implemented

    If alternate text is to be rendered as inline, then it should inherit from its parent the inheritable properties, including font-size. Another point where IE is quite guilty IMO is that there is the setting "Tools/Internet Options…/Advanced tab/Accessibility section/Always expand ALT text for images" and it does not "work" unless "Show pictures" has been unchecked. It’s really counter-intuitive, anti-user-friendly.

    I may need to rewrite or edit that test.

    regards, Gérard

  33. hAl says:

    @Gerard Talbot

    Keep the id’s on for the current bugs and use only the href names for new bugs ?

  34. hAl says:

    @Gerard for your bug #13

    Is height actually a valid attribute for tbody ?

  35. Mark Turner says:

    "Complete means that every property is supported. It doesn’t meant that there are no bugs. Every browser got bugs. And only filing them in a useful manner will lead to a fix for those bugs."


    you are being ridiculous here. By your logic, even if a browser renders font-weight:bold as normal, and font-weight:normal as bold, it just means it’s a bug, but the property is supported? honestly that’s nonsense. sure, ALL issues are bugs, but some are so blatant and severe that it simply means the property is NOT supported per the CSS 2.1 specs.

    rendering something inside "<div style="font-weight: 900;"><div style="font-weight:lighter;">" as bold is not just a bug, it’s a very basic case that clearly and completely goes against what’s EXPLICITLY stated in the specs :

    "The ‘bolder’ and ‘lighter’ values select font weights that are relative to the weight inherited from the parent"

    and we don’t even have some multi-level or complicated inheritance here, just one parent, one child, two divs. if IE8 can’t support that, it means it’s not compliant with what’s EXPLICITLY stated in the specs even in the SIMPLEST forms, which means it does NOT support the font-weight property per the CSS 2.1 specs.

    In terms of software engineering, EVERY problem is a bug, some are just too big that it means the lack of the most basic support of the specs.

    "And only filing them in a useful manner will lead to a fix for those bugs."

    LOL, many people and I have filed this bug (and many other bugs) "in a useful manner" already, whether and when Microsoft will fix them is up to them. Microsoft has their bug tracking system, which is not this blog. So my point HERE is NOT about "lead to a fix for those bugs", but that Microsoft should NOT make FALSE CLAIMS and LIES regarding IE8 on their official pages, kbs and blogs.

    That particular "bug/issue/problem/non-conformance/whatever you want to call it" is just an example that clearly shows that IE8 does NOT support the font-weight property per CSS 2.1 spec, thus it does NOT have a "complete implementation of CSS 2.1", NOR is it "fully compliant with the Cascading Style Sheets (CSS), Level 2 Revision 1 (CSS2.1) specification". And Microsoft should NOT make those false claims and lies, that’s my point HERE. Thank you.

  36. Robert says:

    while other vendors work hard implementing CSS 3 features in their stable releases, IE is submitting CSS2.1 test cases! neat. and IE even fails them.

  37. Evil Dr Rouchie says:

    Its too little, too late.

    CSS 2 should have been fully implemented in IE7.  And *if* IE8 is as good as MS say, who is going to persuade the millions of IE6 users to finally upgrade?

  38. hAl says:

    @Evil Dr Rouchie

    Noone offers full implementations of CSS 2.1

    But at least IE8 now has about he fullest implementation of CSS 2.1 out there.

    According to Webdevout the CSS 2.1 support provided by IE8 is 98% while FF3 and Opera 9 are at 93% and 94% respectivly.

    And as for CSS3, even frontrunner FF3 only supports only about a third of CSS3 specs a lot of which are still being developed or finalized in W3C workgroups.

  39. Mark Turner says:


    "But at least IE8 now has about he fullest implementation of CSS 2.1 out there."

    nope, the only thing we can say with confidence is that IE8 now has the fullest compliance of the current W3C CSS 2.1 test suite, but since the current test suite only tests less than half of the CSS 2.1 specs, it’s really pointless to say who has the fullest CSS 2.1 implementation just based from the W3C CSS 2.1 test suite results.

    And "fullest compliance of the current W3C CSS 2.1 test suite" is exactly the only thing IE8 can truly claim.

  40. trevor says:

    I have to admit – I hate IE8 for development – it got worse.

    1.) The script error dialog has NO option to clear any individual or all error messages

    2.) "Object expected", "Unknown runtime error" are not very descriptive or useful error messages.  Anytime anything goes wrong in JavaScript it will be due to a runtime error because some object, method or property either wasn’t there, or was an unexpected datatype.

    3.) I used to have the Microsoft Script Debugger installed/enabled, but in IE8 RTM it is no longer available? (hence noting the 2 issues above) How do I re-enable this? (and don’t anyone suggest any Visual Studio tool – I have no intention of ever installing it)


  41. bill says:

    I too have issues with script debugging in IE8.

    I want to use the built in debugger but IE simply won’t let me do so!

    This is the dialog I get when I turn on script debugging:

    Perfect, YES I want to debug!

    In fact, don’t show me this dialog again, just do it.

    BUT as you can see, as soon as I check the box, the dialog is disabled and I can’t continue!?!?!?

    WTF!?!?! If this dialog pops up on every single error (heaven forbid a loop of errors) I am going to go nuts clearing this dialog.

    Please tell me there is a workaround or a patch available for this.


  42. hAl says:

    @Mark Turner

    The fullest compliance claim based on the W3C CSS 2.1 test is a Microsoft claim (verifiable) but also the indepedant Webdevout results confirm that claim finding that the CSS 2.1 support for IE8 now surpasses the conformance results of FF3 and Opera9.

    And even the font-weight is implemented in IE8 allthough it might have some issues/bugs when using certain fonts (as every font can have its own individual different spread of fontweight levels associated with it which can be fairly arbitrarily associated with font-weight values making that spec part open for a lot of interpretation).

  43. John Hrvatin [MSFT] says:

    Hi Trevor,  

    I agree those error messages are typically not that useful.  Have you noticed times when those error messages are displayed in IE8 but IE7 provides a better message?  

    You should be able to still use the Microsoft Script Debugger.  It’s possible IE8’s built-in script debugger affected the old registration.  Can you try reinstalling the Microsoft Script Debugger?  



  44. Arron Eicholz [MSFT] says:

    @Richard Fink:

    ClearType/Font smoothing interferes with tests only because of the anti-aliasing of the fonts. This is the correct behavior for ClearType and IE. This aliasing is done for readability reasons. Unfortunately it makes using a font in test cases difficult.

    The Ahem font is a specially created measuring font that is used in many test cases. When it is used it is also altered by ClearType anti-aliasing. This can create a reddish line or slightly colored lines on the edge of each character possibly making the test fail because of the aliased line.

    It is recommended that ClearType and Font smoothing be disabled to prevent any aliasing interfering with the test cases.

  45. John Hrvatin [MSFT] says:

    Hi Bill,

    If you want to automatically break on script errors, open the tools by pressing F12, switch to the ‘Script’ tab, and press ‘Start Debugging’.  You’ll then break on any script error *within that IE sessions*.

    There’s no way to always break on a script error.  We felt this was an uncommon scenario since many people browse to production sites that have script errors and yet don’t want to debug.  

    The checkbox you’re checking to not show that dialog disables script debugging entirely.  That’s why it disables the ‘Yes’ button.  It’s meant for non-devs or devs who had debugging enabled but are now just browsing.



  46. Arron Eicholz [MSFT] says:

    @Mark Turner:

    This test ( is actually incorrect per the CSS 2.1 spec. The test needs to be updated to properly account for correct implementation of all font levels 100-900 and the ‘lighter’/‘darker’ keywords.

    The spec states (section 15.6):

    "The values ‘100’ to ‘900’ form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor."

    The key here is "…at least as dark as its predecessor". This means it can be the same darkness.

    The first part of this test is testing that the mapping of the fonts is working correctly when a particular font does not support all the weights. This seems to be working correctly. Since each of the heavier weights is "at least as dark as its predecessor".

    The next part of the test is checking how the keywords ‘lighter’ or ‘darker’ function. This is where the test has a bug in it.

    Let’s discuss the ‘lighter’ keyword part of the test. The ‘darker’ keyword just works in the opposite direction.

    The test assumes that the ‘lighter’ keyword will always jump back to the ‘lighter’ rendering of the font. This visually isn’t true.

    The spec states that:

    "’lighter’ is similar, but works in the opposite direction: it selects the next lighter keyword with a different font from the inherited one, unless there is no such font, in which case it selects the next lighter numerical value (and keeps the font unchanged).".

    Since there is no different font from the inherited font then the keyword the selection part of the scenario isn’t valid and we need to use the numerical value. The numerical value is then changed to (current specified level – 100). With this new setting the font can still render just as bold as the right hand column. Note: that functionality is reversed for numbers under 400 and when the keyword ‘darker’.

    In the end this all comes down to the part in the spec that states:

    “There is no guarantee on how a UA will map font faces within a family to weight values. The only guarantee is that a face of a given value be no less dark than the faces of lighter values.”

  47. Jeffrey Gilbert says:

    First sentence is incorrect. It should read "Internet Explorer 8 represents a leap forward in support for web standards <i>for microsoft</i>." The only browser which seems to have trouble keeping pace with standards support and playing fair with standards bodies (ECMA4?) doesn’t need to be lecturing anyone on support of CSS 2.1. You know what would be awesome? Not being the slowest browser on the block with a track record of security errors, standards disobedience, and stagnating software development until mozilla made it matter. What would also be stellar is if MSIE wasn’t the only rendering engine that was unsupported on the mac or linux in even so much as an offshoot browser.

    Invest more. Hype less.

  48. @Arron Eicholz [MSFT]

    I filed the bug, then wrote twice (after 2 beta development releases) to say that the bug was still there and suddenly, someone, just came on march 14th, closed the bug as resolved. Still today, it is NOT fixed. CSS support grid/conformance results does not see a problem for IE 8 with font-size with his tests when there is at least one.

    I personally filed this one since 2005 (in channel 9 blog) and it’s still there. This one was closed as wont-fix, you see, and it’s currently not on IE Team’s radar or to-fix-list. CSS support grid/conformance results does not report any problem whatsoever for IE 8 for font-family but there is one since it must not contain unescaped parentheses. CSS support grid/conformance report gives a perfect Y for @import … but

    a) media-dependent @import rules is not supported in IE 8 (section 6.3 even provided an example)


    clearly shows IE 8 limitations

    rules="all" triggers unexpectedly border-collapse: collapse. Have you queried the CSS work group on that one?

    IMO, the most serious, severe and damaging bug which was not fixed during the beta development is bug 366200. Still today, no plan to fix that one.

    There are also accessibility bugs or UAAG bugs in IE 8 which have not been addressed.

    border-width: inherit test (bug #105) fails in IE 8.

    regards, Gérard

  49. 13- tbody {height: 150px; overflow: auto;} does not work


       Applies to:   non-replaced block-level elements, table cells, and inline-block elements

    overflow is actually not a valid attribute for tbody. So, this isn’t a bug.

    regards, Gérard

  50. > why sends in the tests to the W3C, and who doesn’t validate the website.

    Wil has an excellent point. When IE Blog announced the final release of IE 8 on march 19th 2009, the IE Blog had 3079 validation markup errors. Over 3 thousands! And that is not even considering the CSS parsing errors themselves. A normal, reasonable person would be fully justified to wonder why a major web software development corporation has so many validation markup errors and CSS code errors in its own websites, fully under its own control, and how it can make such big, strong, resounding claims/statements about compliance, conformance, interoperability, etc.. and still several thousands of errors.

    regards, Gérard

  51. hAl says:

    The markup of this blog sure is a disgrace.

    As is the limited features of the blog itself.

    The whole blog experience of the MSDN blogs seems like that of junk blog software from the nineties.  

  52. Disap says:

    IE 6 and 8 should be recalled. By releasing such buggy and behind-the-curve products, you make Microsoft look bad, and slow technological advancement of the web. Do us all a favor and invest more money and effort into this important technology. IE8 fails on almost every competitive metric. This is the last time I install a Microsoft product.

  53. I do not like and do not use words like "BIG LIE", "ridiculous", "nonsense", "lies": I think they are inappropriate, unsuited, too harsch (abrasive) and unneeded anyway.

    But I equally can not adhere blindly to statements like

    "only filing them in a useful manner will lead to a fix for those bugs."


    – it was impossible to file bugs regarding IE between 2000 and early 2006. And even today, filing bug reports at connect IE beta feedback is not fun.. and when it isn’t offline

    – several bugs (and I can list several of them) have been lingering on and on and on for over 10 years and there were people already documenting such bugs in articles in their own blog.

    I found 2 while closely scrutinizing the CSS 1 test suite.

    – I personally had to send emails to see some bugs correctly understood and reopened accordingly, even though a reduced testcase had already been provided and was available, accessible

    – initial reaction of IE Team in some bug reports (and I can list several of them) was that such behaviors were by design: so other people had to convince (document, explain, etc) IE Team in community feedback to reopen and fix such bugs

    – some bugs are closed as wont-fix or by design when the comment from IE Team clearly suggests they require to be fixed. Eg: bugs 366200, 361181, 407963

    – some beta testers had to re-file and re-report bugs again after august 2006: a big, unjustified and unjustifiable waste of beta testers people’s time, energy.

    regards, Gérard

  54. Mark Turner says:


    "The fullest compliance claim based on the W3C CSS 2.1 test is a Microsoft claim (verifiable) but also the indepedant Webdevout results confirm that claim finding that the CSS 2.1 support for IE8 now surpasses the conformance results of FF3 and Opera9"

    nope, you need to distinguish between "the fullest W3C CSS 2.1 test suite compliance" (which is verifiable), and "the fullest W3C CSS 2.1 standards compliance" (which is NOT verifiable, unless there’s some existing test suite that actually tests the full specs, instead of just less than half of the specs)

    So what CSS 2.1 test suite is Webdevout using? If they use the same W3C CSS 2.1 test suite, then the only claim they can confirm is that the W3C CSS 2.1 test suite support for IE8 now surpasses the conformance results of FF3 and Opera9, which does NOT mean "the CSS 2.1 support for IE8 now surpasses the conformance results of FF3 and Opera9", given the current very incomplete state of the W3C CSS 2.1 test suite.

    That’s what I’m saying all along, you can say IE8 has fullest compliance of the current (very incomplete) W3C CSS 2.1 test suite, but you should NOT say IE8 has "the fullest implementation of CSS 2.1" just based on results from the current incomplete W3C CSS 2.1 test suite, when it only tests less than half of the CSS 2.1 specs. Thank you.

    "And even the font-weight is implemented in IE8 allthough it might have some issues/bugs when using certain fonts (as every font can have its own individual different spread of fontweight levels associated with it which can be fairly arbitrarily associated with font-weight values making that spec part open for a lot of interpretation)."

    Of course the font-weight IS implemented in IE8, and font-weight IS implemented in IE7 and IE6. Actually font-weight is implemented since IE4. The point here is that font-weight in IE8 is NOT implemented as per the CSS 2.1 specs, so it means IE8’s font-weight implementation is NOT CSS 2.1 compliant, so it’s not a "complete implementation of CSS 2.1".

    And that has nothing to do with "certain fonts", it’s an issue/bug with ALL fonts, which means it’s an issue/bug that shows it’s does not have a CSS 2.1 implementation.

    You should not talk like "issues/bugs" are different from incomplete CSS 2.1 implementation. Those issues/bugs exactly shows that IE8 has NO complete CSS 2.1 implementation. It’s the same as IE7, IE7 also has its CSS 2.1 implementation, just that it has more issues/bugs. IE8 has improved a lot on that, but that doesn’t mean those standrards conformance issues/bugs left in IE8 are any different from those standrards conformance issues/bugs in IE7. They are ALL "just" issues/bugs, just that IE8 has less and IE7 has more.

    So currently we only know that IE8 has a better CSS 2.1 implementation than IE7, and it has the best score in the current incomplete W3C CSS 2.1 test suite, but whether it has fuller CSS 2.1 implementation than Firefox and Opera, it’s currently unknown and unverifiable, unless you can come up with a FULL CSS 2.1 test suite that tests the FULL CSS 2.1 specs, instead of just testing less than half of the specs.

  55. emanual says:

    @Gérard Talbot++

    Dealing with Microsoft Connect (or the lack of it) has been a never ending nightmare.

    for starters that fly-over tooltip thing DOES NOT WORK!!! IN ANY BROWSER!!!

    An **EFFECTIVE** bug tracking system has the following properties.

    1.) Open, public access

    2.) Way fewer required fields.  15min to fill in a basic bug report is a waste of everyones time.

    3.) Profiles! – Every single bug I would file would be on the same box, under the same conditions. e.g. Always WinXPSP3, always no-addons.

    4.) Public attachments. Do NOT bother opening a system that all users can’t see. Reproducing issues, creating reduced test cases, or having other users find bugs in the sample code will save tons of time and make bug triage much easier.

    5.) Status updates. Submitters need to know what is going on with a bug. Leaving it open for months on end without a word about the status is NOT how to "Listen" to your customers.

    6.) If a bug is not being addressed right away, do NOT close it, do NOT mark it as WONT-FIX.  These are permanent statuses that imply you have no intention of ever dealing with the issue.  Public bug tracking requires a bit of Public Relations.  By all means mark a bug as "Postponed" or flag it as targeted for another release but closing a bug that is truly a bug makes Microsoft look like a company that doesn’t care and (based on the Mix09 keynote) isn’t the story that Dean wants to spread around the world.

    7.) A description and reproduce steps are the only 2 textareas you need on a bug report.  "What did you expect to happen", "What did happen", "what should have happened" as REQUIRED fields were 3 of the most ridiculous fields on a bug report.  Almost all had giberish added just to get around the validation.

    8.) Allow editing of Titles.  Release names change, and during triage a bug title might get/need revising

    9.) The emails sent on bugs were very anoying. 12-18 lines of text and NOWHERE in the emails was there either a SUBJECT or a DESCRIPTION of the bug… you had to click on the link and log in EVERY time

    10.) Searching for bugs in Connect is slow, painful, and not user friendly.

    Finally, there are dozens of BETTER, FREE bug tracking tools out there.  There is absolutely no excuse to keep using Connect.  Cut your loses and move onto a better platform.

  56. emanual says:

    Oh one last one.

    11.) NEVER, EVER do a blanket closing of all open bugs with a generic statement: "This is now fixed.  Well it isn’t but we can’t be bothered to test it ourselves.  Since we blindly updated all open issues and marked them as closed.  When you discover that we’ve shafted our free QA team please re-open this bug and we might look at it again"

    We don’t like getting slapped with wet fish after spending hours testing your software for you.

  57. hAl says:

    @Mark Turner

    Actually I read from Arron Eicholz that your example test for showing font weight was not conforming was actually not accurate and does not show that the font weight property is failing in IE8 at all.

  58. @emanual

    >fly-over tooltip thing

    Yes, it’s very annoying, useless, irrelevant, hogging CPU and RAM resources, duplicating the info already available, it interferes with right-click contextmenu, etc. Many have already demanded to remove that but in vain.

    > 1.) Open, public access

    I am actually for a restricted access for several reasons I explained in the past in IE Blog. Eg some people can not word clearly what the bug is about, can not create a reduced testcase, do not read bug writing guidelines, won’t search for duplicates, etc.

    I still think a full access to anyone to submit bugs is a big mistake.

    > 2.) Way fewer required fields.  

    URL, steps to reproduce, actual results, expected results **MUST** be required, mandatory fields.

    > 4.) Public attachments.

    I am not against public attachments. But I do not believe this prevents people from filing good bug reports. You want web authors, web developers to write bug reports… so they should have some web space available somewhere for their tescases…

    > 5.) Status updates.

    Yes, it would be nice… but when there are several thousands of bug reports, then it takes time, personel, energy, bandwith,.. and there are people who never will accept that a bug may be postponed or futured or put in a lesser-priority-list or closed for whatever reasons you could provide.

    > 6.) Public bug tracking

    All public bug tracking systems I know of have much much more bugs which are incomplete, not-reproducible, without a testcase, which look dupeme, not confirmable, etc.. and which must eventually be closed because they can not be fixed than bugs that eventually get confirmed and fixed. If your userbase is several hundreds of millions of users and if you don’t dispose of infinite amount of money, then you must put restrictions, control mechanisms somewhere, .. because you want quality bug reports, carefully weighed/edited bug report, a good signal/noise ratio, not duplicates, not impossible-to-reproduce bugs, etc.

    > 9.) The emails sent on bugs

    Bugmail should be more terse. Agreed. Ideally, just 1 email for bug changes, not 2 emails (1 for status, 1 for resolution).

    > BETTER, FREE bug tracking tools

    Agreed. I proposed already bugzilla.

    regards, Gérard

  59. Duke of New York says:

    Nobody takes the SGML comment requirement seriously, not even Opera.

    (This shows that Opera does, at some level, understand standard/legacy trade-offs. Just not at a level that makes business sense.)

  60. @Philip

    I agree, confirm and validate your testcase in bug 348757.

    One important detail though: when hovering the link, the tester’s mouse cursor must come from bottom, not from top of the onmouseover reactive link-sentence. When hovering the mouse from the top side, IE 8 renders expected results.

    Btw, I have personally asked that your bug 366200 be reopened, reactivated.

    regards, Gérard

  61. John says:

    Can you please do a blog post that gives us an approximate date when MS will finally end support for IE6 officially. I know the lifecycle is tied to the servicepacks and products IE6 is shipped with, but wading through that list is tedious.

    With IE8 out now, it would be a good signal from MS to announce an end to IE6’s lifecycle to show the world the days of IE6 are are numbered.

  62. EricLaw [MSFT] says:

    John, per, IE6 support on the prior version SP (e.g. XP SP2) ends on 13-Jul-2010.

    However, based on the extended support phase for XP, it looks as if IE6 will fully expire for XP on 31-Dec-2011.  Naturally, expiration of support does not mean that IE6’s prevalence in the wild will drop to 0%.  For instance, while IE6 SP1 support for Windows 2000 has expired (with the retirement of that OS) there are still a small number of users on that platform.

    Of course, it is our hope that the vast majority of users will upgrade to IE8 in the near future to benefit from our significant investments.

Comments are closed.

Skip to main content