Microsoft submits thousands more CSS 2.1 tests to the W3C


The Internet Explorer 8 Release Candidate is the last major IE8 testing milestone. It indicates that we believe that IE8 is implementation complete for CSS 2.1. We also believe IE8 RC1 has the most complete implementation of the CSS 2.1 specification in the industry.

The only way to know if a browser has correctly implemented a specification is to develop a comprehensive set of tests for the specification. These can be used to determine both the support for a specific part of the spec and the behavior of a specific browser. Web developers can also use these test pages as examples of how to combine various layout properties and elements in their pages and know that their page will interoperate well across all the browsers that pass those tests.

Today, the IE Team is submitting 3784 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 Beta 2. This brings Microsoft’s contribution to the CSS 2.1 Test Suite to 7005 tests. IE8 RC1 passes all of these tests today. All but 52 of these cases also pass in at least one other major browser. We’re working closely with the CSS working group to swiftly include these in the official test suite. For now, these tests are available at the Windows Internet Explorer Testing Center. The last key element to web layout interoperability is actually passing the tests. IE8 RC1 is the first browser to pass all valid tests in the suite thus meeting the interoperability requirements in the 2.1 spec.

It’s important that the spec, the browser, and the tests all agree on a behavior. This is when web developers really win. While developing these test cases, we found instances where all other browsers implemented something a specific way. That syntax pattern was in pages all over the web, creating a broad dependency on that behavior. In those cases, we proposed a change to the spec and developed an associated test case to ensure the web continues to work and browsers can implement the spec as written. We sincerely hope this helps the committee finish the 2.1 spec and move it into the Recommendation phase.

There is also a variety of unofficial, unsanctioned “tests” posted around the web as well. These range from quirky web pages that someone developed to show off a bug in a browser to complex degenerative web scenarios that combine CSS 2.1 properties and elements in unlikely ways. Some of these are pragmatic tests that actually demonstrate a real-world situation where there are inconsistencies across major browsers. IE8 RC1 passes all of the pragmatic “tests” we could find, although new combinations can always be developed. I strongly encourage those test authors to submit their cases 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.

Jason Upton
Test Manager – Internet Explorer

Comments (61)

  1. Rik says:

    "IE8 RC1 is the first browser to pass all valid tests in the suite thus meeting the interoperability requirements in the 2.1 spec."

    That is not true. Those tests (highly appreciable) are not yet validated to be part of the W3C Test Suite.

  2. RW says:

    So you’re saying IE8 will have less rendering bugs than any other browser currently on the market.

    It’s kind of hard for me to believe this after years of Microsoft-induced pain, so I’ll be holding judgement for a while longer.

    Now that you’ve finished off the CSS2.1 implementation, does this mean you’ll have time to begin work on SVG and CSS3?

  3. Saad says:

    If save tool of IE was fast as google chrome.

  4. RBJ says:

    Can you guys please fix the zooming in/out when viewing huge images?

    it lags a lot, firefox 3 doesn’t have this problem.

    here is a picture for example:

    http://spaceflight.nasa.gov/gallery/images/shuttle/sts-109/hires/sts109-729-072.jpg

    open it in IE8 RC1, wait for it to load completely then see how extremely laggy zooming get.

  5. I’d argue that many of those 7,000 test cases are surfeit and unneccessary. For example, you have around 50 test cases specifically testing an absolutely positioned element that is offset to the left, and some are actually invalid.

    "IE8 RC1 passes all of the pragmatic “tests” we could find…"

    There are a number of test cases at http://idreamincode.co.uk/ie8-final-release-bugs that IE8 RC1 (and even the final build) will *not* pass, and also many at Gerard Talbots pages.

    "It indicates that we believe that IE8 is implementation complete for CSS 2.1"

    IE8 final build will certaintly *not* full support Level 2.1 – there are some fairly major spec violations that you guys have already said you will not fix.

  6. Standards says:

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

    "This bug has been closed by the IE team and will not be fixed for the release of IE 8 final."

    With so many bugs unfixed and many spec violations, how can you even claim to be CSS2.1 compliant? Is this some kind of joke? Just watching the video of Dean and Jason shows how arrogant and clueless MS is when it comes to standards support. Jason should be embrassed since he claims to come from an "engineering background".

    It’s clear enough that MS doesn’t care about code quality at all and is only finishing up IE8 to be able to ship on time with Win7, whether it works in line with the specs or not or properly supports the standards as defined by the W3C doesn’t matter at all.

  7. > This brings Microsoft’s contribution to the CSS 2.1 Test Suite to 7005 tests. IE8 RC1 passes all of these tests today.

    This is not true. Maybe close but not perfectly true.

    Many cursor: url() tests fail: probably because the resource, probably incorrectly defined, is not fetched.

    Anyway, cursor: url(); without a generic cursor at the end of the list must be parsed correctly (see #201 in my list

    http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/CustomCursor-2.html ).

    samples.msdn.microsoft.com/ietestcenter/css/chapter_6/Rules/atimport-004.htm

    fails in IE 8 RC1 because

    http://samples.msdn.microsoft.com/ietestcenter/Support/atimport-004.css

    has div {color: red;}; Firefox 3.x passes this one.

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-015.htm

    is another one that IE 8 RC1 fails. 1ex is not necessarly 0.5em: many have explained that before.

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-019.htm

    fails in RC1 while it passes in Firefox 3.x

    "

    It would be wonderful to implement, provided that it was consistent in cross browser performance. Unfortunately, this is not the case.

    After testing in Firefox, using ex seemed to perform just right. After getting used to ex it seemed as though it was an effective way to determine font-sizes. Testing in Opera proved otherwise. All of my fonts were extremely small and almost impossible to read. After looking into this, it seems as though Opera and IE render 1ex as 0.5em which is the cause of all the trouble. Further investigation lead me to believe that the cause of this wasn’t Opera or Internet Explorer, but a limitation of the Windows OS somehow.

    "

    mondaybynoon.com/2006/03/13/effective-style-with-em/

    http://www.cs.tut.fi/~jkorpela/x-height.html

    brunildo.org/test/xheight.pl

    http://www.barrypearson.co.uk/articles/text/aspect_values.htm

    http://www.damowmow.com/playground/bugs/tests/ex.html

    Etc.. There are many bugs at connect IE beta feedback which have been closed and postponed and which are appropriate CSS 2.1 tests. #81, #133, #134, #141, #201, #211, etc at my IE 8 bugs webpage and a few Ian "Hixie" Hickson CSS 2.1 testpages too.

    Regards, Gérard

  8. > IE8 RC1 passes all of the pragmatic “tests” we could find

    Bug #13 at my site pointed to UAAG 1.0 test from 2002

    http://www.w3.org/WAI/UA/TS/html401/cp1001/1001-THEAD-TBODY-TFOOT-OVERFLOW.html

    IE 8 RC1 does not support overflow: auto on dimensioned tbody. I did not originally stress on that bug (by reporting it at connect) because Opera and Safari still do not support/pass such test/scrolling capability in tables.

    Another IE 8 RC1 failure (it’s a regression because it worked in pre-RC1):

    3- <colgroup> visibility with border-collapse: collapse test

    of this testpage:

    bugzilla.mozilla.org/attachment.cgi?id=147933&action=view

    Clicking on a radio button will trigger IE 8 RC1 to automatically switch into backward-compatible rendering mode (setting is Tools/Internet Options/Advanced tab/Browsing category/Automatically recover from page layout errors with Compatibility View is checked by default)

    There are others, I’m sure. It’s just a matter of searching a bit. A good start is Ian "Hixie" Hickson CSS 2.1 testpages.

    Regards, Gérard

  9. Acid says:

    http://en.wikipedia.org/wiki/Acid3

    http://img222.imageshack.us/my.php?image=lolja1.png

    Check out IE8 RC1’s funky rendering of this Wikipedia page and compare to Firefox 3.0/3.1/3.2 or Google Chrome 1.0/2.0. Standards compliant? I THINK NOT.

  10. sonicdoommario says:

    I didn’t see any problem with the rendering of that page with compatibility view off.

    Anyhow, keep up the great work Microsoft.

  11. Speednet says:

    @Jason,

    Great post, it’s obvious that you guys are taking a lot of pride in your work.

    Please keep hammering away and nail down all the loose ends (like Gérard’s 2 posts above).  I know that your team has to live up to unfair high expectations, but at least you get to be a developer on the web browser that will be used by more people around the world than any other — not too shabby.

    Also, when the CSS team starts work on the next new features, can you *please* make that feature the CSS3 opacity attribute?  

    Also, after doing some Safari work for iPhone pages, I’m envious of the CSS3 features like multiple background images, rounded borders, rgba() colors, and customizable borders.  Can you guys like double the size of your team and add those too?  😉

    -Todd

  12. hAl says:

    @Gerard Talbot

    You should update the tables in your bugsections from the eta 2 to the RC1 as most of items in those tables seems to render correct now.

    Not all of them though

  13. Doug says:

    There seems to be an automatic assumption that because a bug test or other browser does things differently, IE must be wrong.

    Maybe, just maybe, is it possible that IE is getting some things right that the other browsers are not?

    Just an observation.

  14. Adrian says:

    I think the IE team needs to wake up. All the other browsers have implemented parts of the CSS 3 spec, but you start bragging about 2.1

    And if you come with a different approach to rendering just because "it’s the right way" and all the other browsers have a "wrong" implementation of some part of 2.1 spec, how do you think this will help web developers? It will be back to the "all the others are doing it this way, and now IE8 will just do it differently, because suddently you are are standards advocates now". Riiight…

  15. Elean says:

    Ah, yes. And whats about Acid-3? 20 of 100.

  16. frymaster says:

    @acid:

    From that wikipedia page: "It includes several elements from W3C CSS3 working drafts that have not made it to candidate recommendations yet."

    This blog post is about css 2.1, that page is about css 3.  css 2.1 hasn’t been finalised yet, but at least it’s at recomendation stage

  17. Karellen says:

    Adrian > If IE8 does it right, and all the other browsers do it wrong, then the other browsers should fix their damn implementation!

    Which other browsers should IE copy? What if Firefox gets it wrong one way, and Safari another, which should IE copy? What if FF and Safari get it wrong in the same way, but Opera gets it right? Which should IE follow? What about Chrome – shoule the IE devs pay attention to what it does?

    What about the people who want to write new browsers? The browsers available today are not all the browsers that will ever be written. How should the authors of new browsers decide what to write?

    What about web authoring tools? How do they know what code to output? Should they code to the spec, or to one particular set of browsers?

    No, the *only* way to help web developers in the long run is to get *all* implementations correct according to the spec. That way browser authors, content generators and web devs all only need to look at the spec to figure out what they need to do.

    If a browser is off, then the users of that browser should either pressure their vendor to fix their product so that it works according to the spec, or they should move to a browser that already does work.

    That’s the only way to get out of the truly, excruciatingly painful mess we’re in at the moment.

    (Disclaimer: I truly loathe MS for what they’ve done to the web and internet standards over the last 12 years. They’re going to be on my "naughty" list for a *very* long time because of that alone. But if they can raise the bar for conforming implementations, and get everyone else to play catch-up and get all the others to improve *their* implementations, then IMHO that’s good for everyone, and something to be cheered.)

  18. Karellen says:

    @frymaster:

    Uh, "Technical Recommendation" is the W3C term for "finalised standard".

    http://www.w3.org/TR/#Recommendations

  19. Phil says:

    Funny how my IE8 RC1 fails miserably (20/100) on Acid 3, yet OPERA 10 -ALPHA- passes completely…

  20. hAl says:

    Looking at the acid 3 results (which are visible after the test has completed by clicking on the word ACID) it seems most issues are with an unsupport script properties or methods.

    It could wel be that only very few unsupported jscript elements cause a ton of the tests to fail.

    Which could be unsolvable if Microsft has no intention to support those scripts element (for instance if they were from the proposed but cancelled Ecmascript 4 spec)

    I can’t find anyone who has actually properly analyzed why IE fails so many tests in ACID3.

  21. Acid says:

    I’m not talking about the Acid3 test. I’m talking about the Wikipedia page and I included a screenshot to show that IE8 RC1 isn’t rendering it correctly. I not sure why most people here think I’m talking about the Acid3 test even.

    http://img222.imageshack.us/img222/3883/lolja1.png

    IE7 emulation mode also renders it wrong, although with a different kind of wrong. It doesn’t look like that in Firefox or Chrome.

  22. Phil says:

    @Acid – I mentioned the Acid3 test without seeing your post, that might have something to do with it.

    Bottom line, looks like IE8 still sucks, no matter how many stupid web slices or accelerators you throw into it.  Give me compliant rendering and a download manager, I’ll move away from Firefox, Opera and Safari… oh wait no I won’t, I use Linux 😀

  23. Mike says:

    I am impressed at this work however sometimes I think the aims of the IE team are at odds with designers.

    I almost think this full implementation of css2.1 is more aimed at litigation issues with the EU to prove that IE8 is the one of the most standards compliant browsers.

    The fact is IE8 is the only modern browser that does not support css opacity. The alternative -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"

    produces ugly jagged text because anti-aliasing is destroyed.

    Likewise rounded corners not in css2.1 but really important in making nice designs without resorting to having to use lots of background images or complicated hacks.

  24. EricLaw [MSFT] says:

    @Chris: You must disable the "Compatibility View" feature to get the CSS2.1 test cases to render correctly; otherwise, IE8 will render the tests as it did in IE7.

    By default, *.Microsoft.com is currently in the Compatibility View list.

  25. Rodrigo Cardoso says:

    please:

    -ms-border-raidius!!!!!!!!!! :(

    rgba() !!!!!!!!!!!!!!!!!!!!! :(

  26. hAl says:

    @EricLaw [MSFT]

    That does not make the boxes equal in size so it fails the test

  27. SylvainG [MSFT] says:

    @hAl: in order for testcases to pass reliably across browsers and operating systems, they often use the Ahem font. Without this font installed for your system tests like this one will always fail.

    See http://dev.w3.org/CSS/fonts/ahem/README”>http://dev.w3.org/CSS/fonts/ahem/README.

    Then http://dev.w3.org/CSS/fonts/ahem/.

  28. J says:

    plz support more css2.1 and css3, and delay the release!

  29. Tino Zijdel says:

    Where can I find an overview of the testresults for all major browser?

    > While developing these test cases, we found instances where all other browsers implemented something a specific way. That syntax pattern was in pages all over the web, creating a broad dependency on that behavior. In those cases, we proposed a change to the spec and developed an associated test case to ensure the web continues to work and browsers can implement the spec as written.

    That’s insinuating that the other browservendors deliberately ignored the specification, but what was IE’s (<8) behavior in those cases?

  30. @ Doug,

    There are cases where IE 8 RC1 gets it wrong. And there are cases where other browsers get it wrong too. Serious testers do not presume one way or another: ultimately, thorough testing and excellent understanding of the spec (and that can be quite difficult: eg sections 9.5.1, 9.5.2) decide

    I still maintain that

    samples.msdn.microsoft.com/ietestcenter/css/chapter_6/Rules/atimport-004.htm

    fails in IE 8 RC1 in **_print preview_**; the test is not written for testing media print. I’m not dreaming this up:

    bug 354316 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=354316

    was closed and the testcase I submitted came directly from CSS 2.1, section 6.3 The @import rule

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-015.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-019.htm

    will convince serious testers that the ex unit is not accurately implemented in IE 8 RC1

    Invalid cursor: url() declarations are incorrectly parsed: filed as bug 407963

    Sized tbody with overflow: auto (scrollable tbody): not supported, not tested, not implemented

    horizontal line <hr> still implemented as inline-level element: see bug #210

    list-style: none on <li>: see bug 407932

    :hover class reactive when hovering border and content but not padding area. Eg, visit http://www.gtalbot.org and hover mouse over border and padding area of W3C image-button

    Bruno Fassino’s RC1 list:

    http://www.brunildo.org/test/IE8beta-CSS-bugs.html

    (although I would say vertical-align: middle is now accurately implemented)

    – Some failures in CSS 2.1 test suite:

    http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t0803-c5504-imrgn-l-05-b-ag.htm

    http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1604-c541-word-sp-01-b-a.htm

    etc

    Regards, Gérard

  31. peter says:

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-015.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-019.htm

    work fine in ie 8 RC 1 as soon as you have the font installed.

  32. Will Peavy says:

    @IE dev team – great work on these tests! I’m looking forward to seeing what you come up with as HTML 5 develops.

    FYI for everyone who has commented: CSS 2.1 only became a Candidate Recommendation in 2007. The CSS 3 spec is still under development.

  33. gsnedders says:

    @Gérald:

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-015.htm

    is valid, because it relies on the Ahem font which is defined to have a x-height equal to 0.8em. The 0.5em clause of that test-case relies upon the clause of the spec which says, "In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em should be used". Therefore, for that test case, one of 0.8em and 0.5em should be identical to 1ex.

  34. @Peter

    > samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-019.htm

    > work fine in ie 8 RC 1 as soon as you have the font installed.

    I have Ahem font installed and am in standards mode: this test fails (XP SP 3 here).

    1ex == 0.8em for Ahem font;

    1ex != 0.5em  for Ahem font.

    Like I said before, 1ex is not necessarly 0.5em: in fact, it is very rare that 1ex == 0.5em

    Eg

    1ex == 0.422em for Courier New font.

    ———-

    The height of the lower case letter "x" in Ahem font is 80% of the font-size, not 50%. That is why I say

    samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-015.htm

    fails.

    @gsnedders

    You said it yourself: "Ahem font which is defined to have a x-height equal to 0.8em" but, in that numbers-units-015.htm test, 1ex is rendered by RC1 as 0.5em. So, you can’t say RC1 uses the x-height when the test offers the correct rendering (0.8em) as an optional rendering and the fallback (0.5em) as defined by the CSS 2.1 as another optional rendering.

    This fallback is under review in CSS 3:

    http://www.w3.org/TR/css3-values/#ex

    Other tests on ex also show that IE 8 RC1 does not use the height of letter "x".

    Regards, Gérard

  35. Test failures (very highly due again to ex implementation):

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/height/height-083.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/height/height-084.htm

    http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1601-c547-indent-00-b-a.htm

    http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040302-c61-rel-len-00-b-ag.htm

    etc..

    Regards, Gérard

  36. Another (7th so far) test failure (line-height defined with ex unit) in IE 8 RC1 build:

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/line-height/line-height-080.htm

    Regards, Gérard

  37. 2 other conclusive test failures for ex unit:

    Test 2 at:

    http://www.richinstyle.com/test/keyconcepts/ex.html

    (the "x"s should be as high as the dark greenish rectangle images on their right side. The test is similar to the first/top part/section of

    http://www.damowmow.com/playground/bugs/tests/ex.html

    and also test 3 at the same webpage.

    As soon as 1997 (11 years ago), it was known that IE was not accurately implementing ex unit (as the height of the letter "x" in the font used) and Microsoft was made aware of this:

    lists.w3.org/Archives/Public/www-style/1997Dec/0214.html

    Regards, Gérard

  38. Min-height, max-height, width (and possibly many others) tests with specified ex unit values all fail in IE 8 RC1:

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/min-height/min-height-083.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/max-height/max-height-083.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_10/properties/width/width-083.htm

    msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.unittype.aspx

    and

    msdn.microsoft.com/en-us/library/ms531211(VS.85).aspx

    both mentions to support ex unit as the height of the lowercase "x" character. And not that ex unit resolved as half the font-size is good enough…

    [Unless otherwise specified, the length units are supported as of Microsoft Internet Explorer 3.0 or later.  (…) ex The height of a lowercase "x".]

    msdn.microsoft.com/en-us/library/ms531211(VS.85).aspx

    "those Microsoft test cases are actually wrong… per the CSS spec, if the

    font does not have an xHeight specified, the rendering engine should try and

    compute it from an actual x, thus the xHeight for Ahem is 0.8 rather than 0.5.

    "

    bugs.webkit.org/show_bug.cgi?id=16362#c6

    Regards, Gérard

  39. woot says:

    IE8 may not be perfect but it’s a huge step forward from IE7. Thanks IE8 dev team for working toward a better web.

  40. SylvainG [MSFT] says:

    Gerard,

    [Note: the following does not attempt to determine whether these tests fail or which ones represent a bug. All these tests pass using the latest builds on my system. I will double-check using RC and partner builds.]

    The CSS 2.1 specification for x-height is not so clear-cut. From http://www.w3.org/TR/CSS21/syndata.html#ex :

    "The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristics is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em should be used."

    If xHeight is not available, UAs *may* determine it in other ways. As a specified behavior usually *must* be followed, this is significant. Then, it may use *a lowercase glyph*. Not x. A lowercase glyph. (Not all fonts and scripts have an x). The example actually suggests using an ‘o’.

    As a fallback, UAs *should* then use .5em.

    So if anything, we should fix our MSDN doc everywhere it refers to x-height in the context of CSS 2.1 (Confusingly, the first document you link refers to CSS1 which I’m not sure even defined ex…).

    Hope this helps,

    S.

  41. @Sylvain and others

    Good news. A friend of mine emailed me and asked which version of the Ahem font I was using. I had the old one, the original one, the May 24th 1999, not the March 2006 (modified Ahem font to include x-height information). So, that’s my mistake, a very unintentional one.

    So, with the March 2006 Ahem font installed, all the tests (except 2) pass in IE 8 RC1.

    ex unit tests which still fail:

    ==============================

    http://www.damowmow.com/playground/bugs/tests/ex.html

    http://www.richinstyle.com/test/keyconcepts/ex.html

    It may be – I would bet on this – that the x-height metric info are not in the font used (usually older ones; pre-2005 ones?). Despite that, Firefox 1.x, Firefox 2.x and Firefox 3.x are able to figure out the x-height metric… and IE 8 RC1 is not.

    ———–

    > If xHeight is not available, UAs *may* determine it in other ways.

    Over here, it looks like IE 8 RC1 does not even try to determine x-height if the xHeight info is not there. This is also what the Apple developer suggested in bugs.webkit.org/show_bug.cgi?id=16362#c6

    > may use *a lowercase glyph*. Not x. A lowercase glyph. (Not all fonts and scripts have an x).

    "x" characters are shown in the 2 ex unit tests which still fail in IE 8 RC1.

    > As a fallback, UAs *should* then use .5em.

    The problem with this "optional-rendering-fallback" is that a web author then can NOT use *reliably* ex unit for a myriad of situations (where a length can be used to specify propertie like [min|max]height, [min|max]width, letter-spacing, word-spacing, font-size, etc.) and elements in any webpage. Eg a web author can not design the dimensions of a container and then think/say/write/warn his webpage visitors that such box can be 300px or it can be 187px.

    Eric Meyer knew in december 1997 that IE 4 did not implement ex unit correctly:

    lists.w3.org/Archives/Public/www-style/1997Dec/0217.html

    CSS 1 spec did not explicitly, formally, clearly define the ex unit, you’re right.. although it was a concept known in typography and the CSS 1 example says "1ex /* x-height, ~ the height of the letter ‘x’".

    Regards, Gérard

  42. @ hAl

    > You should update the tables in your bugsections from the eta 2 to the RC1

    Done.

    Gérard

  43. SylvainG [MSFT] says:

    Gerard, glad you were able to fix your Ahem font !

    We will look into those two tests. But reading the actual wording of the spec with its ‘mays’, ‘possible heuristics’ and ‘should’ indicates this metric is in fact not easy to specify strictly and reliably across all fonts, platforms and scripts. (And my still limited understanding has shown that it’s not).

    With all due respect to Mr Papirovski, there is no such requirement in the spec; the latter indicates his implementation choice to be a valid one, but it does not invalidate IE’s. Read the definition above one more time, paying attention to the most important verbs in standard documents(they even have their own RFC at http://www.ietf.org/rfc/rfc2119.txt).

    There is no requirement here for UAs to ‘try’ anything if the font does not define its own x-height; nowhere does it say that UAs ‘shall’ or ‘must’ try anything. It *may* determine x-height *from a lowercase glyph* and an ‘o’ is in fact suggested. (Why not an x, I’m not exactly sure but I’d like to know why that was chosen when common practice and the very name suggest an ‘x’ should be used; it could be a typo or it could be deliberate. Do you know ?).

    Per CSS 2.1, UAs may in fact skip this when, for instance, it is ‘impractical’ for them to do so; what that means is undefined, but one can imagine performance costs e.g. on a small device with limited memory ?

    Then, whether they have tried or not – both are in fact OK – they *should* use .5em. Not must. Should.

    Now I think what you and Mr Papirovski may also be saying is this : in the absence of a clear-cut standard definition, de facto standards, as implemented, establish the baseline. Standards, after all, are only a means to and end and that end is interoperability. And if one can argue in this case that the de facto approach of the most popular browser is suboptimal wrt to other specified alternatives then yes, you may have a very reasonable request.

    So if this is what you’re saying, then you and I are in violent agreement on principles. We and the CSS WG pay a great deal of attention to existing practice. We shall do likewise here.

    Although I’m not sure we can bring absolute certainty to web designers, who may still end up serving content to future browsers or devices that choose to skip this ‘impractical’ step and fall back to .5em. Given that the spec specifically states this *can* in fact happen, a designer should not rely on font metrics or the height of a lowercase x to be the only possible outcomes. Such an assumption is strictly speaking invalid until such time as the spec’s definition is changed.

    Or are you saying the spec is wrong and should be corrected ? We would love to hear from you at www-style@w3.org !

    PS: btw I do not believe the post you linked to to indicates Mr Meyer ‘knew’ that IE4 did not implement ex correctly. His post asks ‘is that what they did ?’ – ‘they’ referring to Microsoft – as a response to someone describing MSIE4’s behavior. But even if Mr Meyer or anyone else ‘knew’ way back when, it doesn’t make our current implementation any more invalid wrt CSS 2.1; it does establish, however, that x-height is and has been understood as being much stricter and clearer than it actually is. This in itself is valuable input.

  44. SylvainG [MSFT] says:

    Gerard,

    re: http://www.damowmow.com/playground/bugs/tests/ex.html

    This testcase looks correct for me using the latest builds, but I notice that on the same system Firefox 3.1b2 maps different fonts.

    re: http://www.richinstyle.com/test/keyconcepts/ex.html

    In the second test, the last X (Impact font) is definitely taller than the image but the latter does not look like it’s .5 em either. I’m investigating. Again, thank you for the feedback !

  45. @ Sylvain

    > There is no requirement here for UAs to ‘try’ anything if the font does not define its own x-height

    Firefox 1+ tries to determine it and it goes further: it seems to be able to achieve this for many fonts, including those without x-height info embedded into font file. Apple/WebKit

    bugs.webkit.org/show_bug.cgi?id=16362

    wants to determine it too: that is how I understood the comment "the rendering engine should try and

    compute it from an actual x".

    As for the spec, yes, there is no requirement. So

    1ex == 0.8em for Ahem font and

    1ex == 0.5em  for Ahem font

    is valid.

    But, x-height is 0.8em for Ahem font, is 0.422em for Courier New font, etc.

    I hope this changes in CSS 3 for non-small-screen-devices (for any devices where determining x-height would impact performance), otherwise ex as a length unit should be removed from the spec.

    > Given that the spec specifically states this *can* in fact happen, a designer should not rely on font metrics or the height of a lowercase x to be the only possible outcomes.

    I agree and already mentioned so. If, say, 15ex can be resolved and rendered in 2 distinct, separate manners, then the ex unit should not be used because it is not reliable (interoperability speaking).

    Regards, Gérard

  46. SylvainG [MSFT] says:

    @Gerard

    Yes, Firefox does this; and the general intent is to do this when no x-height is specifically defined by a font(not sure why you’d want to do it if the font file specifies it but I’m no expert in this area).

    WebKit doesn’t do this yet and I can’t tell from your link whether it will or when (Priority P3, severity Minor, patch posted in 05/08…). The stated rationale is still wrong imo – CSS does not mandate this at all – and, of particular interest for this feature, WebKit also has to consider an environment where this type of optional optimization might actually matter for performance: Safari on the iPhone.

    As for CSS3, I wonder how we can word an ‘opt-out’ clause both general enough yet strict enough to assert that, say, IE and Safari are not compliant but iPhone Safari and IE Mobile are.

    Assuming it were even desirable to specify a relative length unit with varying conformance criteria depending on what device renders the content, I’m not sure how this helps the web author who still has to deal with interop issues; full-fidelity smartphone browsers may be as important to his client’s business as personal computers are. The problem is still there.

    Ultimately, IE, WebKit and Firefox all comply with CSS 2.1 today as far as I can tell.

    Now, if you have a specific testcase where you know that a) the font being used specifies x-height and b) IE reliably ignores that x-height and falls back to .5em, I do apologize for still not understanding which one I should look at but I want to because that is not what we should be doing. Can you clarify ?

    Thank you !

  47. @ Sylvain

    > if you have a specific testcase where you know that a) the font being used specifies x-height and b) IE reliably ignores that x-height and falls back to .5em, I do apologize for still not understanding which one I should look at but I want to because that is not what we should be doing.

    I would first need to find and use a font/typographic inspecting software which would tell me that this font but not that font has/specifies the x-height info embedded into the font file. I don’t have such font/typographic inspecting software. I’m sure this sort of font inspecting software exists.

    According to Bruno Fassino, only the recent fonts from Microsoft (those for Windows 7 and for Vista; but not those for XP) have such x-height measurement info in the font files.

    ———

    Serious bug [409478]: <col></col> can make a webpage become blank

    Steps to reproduce:

    1- Load

    http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/col-can-make-webpage-blank.html

    2- Zoom in it from 100% to 125% by clicking once the magnifying glass on the far right of the status bar

    3- Then move the mouse inside, within the browser window viewport

    Actual results in RC1 build 18372 (XP SP3):

    The page becomes blank or a yellow balloon warning pops up saying "A problem displaying mozilla.org caused Internet Explorer to refresh the webpage using Compatibility View" depending on whether "Automatically recover from page layout errors with Compatibility View" (in Internet Options/Advanced tab) setting checkbox has been checked or unchecked.

    Regards, Gérard

  48. @Gerard

    > I would first need to find and use a

    > font/typographic inspecting software

    Did you try ttfdump ? (available here http://www.microsoft.com/typography/tools/tools.aspx)

    It shows that some fonts have in the OS/2 table a "sxHeight" value (use: ttfdump filename -tOS/2 -nx -h).  This might be the info used by IE8 (of course I’m sure about this).

  49. Hello Bruno :)

    I got ttfdump.exe ()

    sxHeight is defined here:

    partners.adobe.com/public/developer/opentype/index_os2.html#xh

    > use: ttfdump filename -tOS/2 -nx -h

    I would never have found that on my own. Thank you very much!!

    Regards, Gérard

  50. SylvainG [MSFT] says:

    Gerard, Bruno,

    Windows fonts – since well before XP – specify x-height. This is one of the reasons IE doesn’t do this optional x-height computation step: it is a relatively expensive code path that in practive occurs extremely rarely.

    I’ll try to reproduce the issue you’re reporting above. Thank you again !

  51. All of my fonts (except one) do not specify sxHeight when I use ttfdump. All of my fonts have OS/2 version == 0 or 1 and not == 2 or 3.

    http://www.damowmow.com/playground/bugs/tests/ex.html

    http://www.richinstyle.com/test/keyconcepts/ex.html

    Those 2 webpages use the generic font-family serif, sans-serif and monospace which refer by default to "Times New Roman" (TIMES.TTF), Arial (ARIAL.TTF) and "Courier New" (COUR.TTF) and none of them on my system specify the sxHeight according to ttfdump.

    I wonder where the yStrikeoutPosition is in comparison to the x-height: it should not be far from the x-height.

    Regards, Gérard

  52. If IE 8 RC1 is able to support vertical-align: middle (where half of x-height must be computed) for OS/2 version 0 and version 1 fonts, then why should it be difficult to determine sxHeight?

    Regards, Gérard

  53. Gérard,

    I confirm that NO one of the fonts included in XP have that sxHeight info (and have ‘OS/2’ version = 1).

    The versions of those same fonts included in Vista usually have ‘OS/2’ version = 2 or 3, and contain the sxHeight info.

    But it remains true that even in Vista and Windows 7 beta NOT all fonts contain that info.

    I made a guess of the method used by Firefox to get the xheight (which does not involve that sxHeight field) here http://archivist.incutio.com/viewlist/css-discuss/103861

    Best regards,

    Bruno

  54. Test 6572 seems wrong:

    A percentage ‘height’ value on a table cell computes to ‘auto’.

    samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/table-height-algorithm-005.htm

    but, in such case, the expected results should be

    "Test passes if the blue and black boxes below ARE (instead of are not) the same height."

    Test 6573

    samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/table-height-algorithm-006.htm

    is also wrong

    Regards, Gérard

  55. Test 6655: Floating a cell can cause it to not be a cell anymore

    samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/table-visual-layout-024.htm

    goes like this:

    {

    Test passes if the "Filler Text" below does or does not overflow the blue box.

    }

    If the expected behavior/result is not specified, then maybe the test is not really required.

    On top of that, the test has a validation markup error.

    Regards, Gérard

  56. I count around 4150 – where are the other 2885?

  57. samples.msdn.microsoft.com/ietestcenter/frame_holder.html?url=./css/chapter_17/rules/border-spacing-applies-to-001.htm

    samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/border-style-inset-002.htm

    fail and the test is also wrong. If you want to test border-style: inset, then the expected results should say "look as though it were embedded in the canvas." and not "look as if they are popping out of the canvas".

    IE does not support border-style: inset | outset | ridge | groove for black color. This was already explained, documented at richinstyle.com as soon as 1999:

    "

    Bug 6: 3D styles rendered as solid when border-color is dark

    Because IE applies the 3D border styles by applying a darker section, all of the followingborder styles will appear as solid when the border color is black or very dark:

    ridge

    groove

    outset

    inset

    "

    http://www.richinstyle.com/bugs/ie5.html#border

    also

    http://www.richinstyle.com/bugs/ie5demo.html

    Regards, Gérard

  58. There are at least 4 tests that, at least, fail (test 6406 is wrong on top) starting with this one:

    Test 6405:

    samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/border-style-inset-001.htm

    All borders do not have 3D look or relief look because they are black.

    This one (test 2486):

    samples.msdn.microsoft.com/ietestcenter/css/chapter_8/rules/border-style-rendering-003.htm

    maybe the pass condition should be reviewed, could be made less equiprocal.

    Regards, Gérard

  59. rpflo says:

    "Maybe, just maybe, is it possible that IE is getting some things right that the other browsers are not?"

    You don’t really develop websites do you?

  60. Microsoft released the final version of IE8 last week (3.19.2009); your users will soon be automatically upgraded unless auto-updates have been explicitly blocked. Are you ready?…