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
Anonymous
January 27, 2009
"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.Anonymous
January 27, 2009
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?Anonymous
January 27, 2009
If save tool of IE was fast as google chrome.Anonymous
January 28, 2009
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.Anonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
> IE8 RC1 passes all of the pragmatic “tests” we could find Bug #13 at my site pointed to UAAG 1.0 test from 2002 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érardAnonymous
January 28, 2009
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.Anonymous
January 28, 2009
I didn't see any problem with the rendering of that page with compatibility view off. Anyhow, keep up the great work Microsoft.Anonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
@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 thoughAnonymous
January 28, 2009
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.Anonymous
January 28, 2009
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...Anonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
The comment has been removedAnonymous
January 28, 2009
@frymaster: Uh, "Technical Recommendation" is the W3C term for "finalised standard". http://www.w3.org/TR/#RecommendationsAnonymous
January 28, 2009
The test at http://samples.msdn.microsoft.com/ietestcenter/css/chapter_4/Rules/numbers-units-019.htm seems to fail in IE 8 RC 1.Anonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
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.Anonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
@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.Anonymous
January 29, 2009
please: -ms-border-raidius!!!!!!!!!! :( rgba() !!!!!!!!!!!!!!!!!!!!! :(Anonymous
January 29, 2009
@EricLaw [MSFT] That does not make the boxes equal in size so it fails the testAnonymous
January 29, 2009
@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/.Anonymous
January 29, 2009
plz support more css2.1 and css3, and delay the release!Anonymous
January 29, 2009
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?Anonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
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.Anonymous
January 30, 2009
@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.Anonymous
January 30, 2009
@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.Anonymous
January 30, 2009
@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: 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
Anonymous
January 30, 2009
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 www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1601-c547-indent-00-b-a.htm www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040302-c61-rel-len-00-b-ag.htm etc.. Regards, GérardAnonymous
January 30, 2009
The comment has been removedAnonymous
January 30, 2009
The comment has been removedAnonymous
January 30, 2009
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érardAnonymous
January 31, 2009
IE8 may not be perfect but it's a huge step forward from IE7. Thanks IE8 dev team for working toward a better web.Anonymous
February 01, 2009
The comment has been removedAnonymous
February 01, 2009
The comment has been removedAnonymous
February 01, 2009
@ hAl > You should update the tables in your bugsections from the eta 2 to the RC1 Done. GérardAnonymous
February 02, 2009
The comment has been removedAnonymous
February 02, 2009
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 !Anonymous
February 03, 2009
@ 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érardAnonymous
February 03, 2009
@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 !Anonymous
February 03, 2009
@ 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 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
Anonymous
February 04, 2009
@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).Anonymous
February 04, 2009
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érardAnonymous
February 04, 2009
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 !Anonymous
February 04, 2009
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. www.damowmow.com/playground/bugs/tests/ex.html 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érardAnonymous
February 04, 2009
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érardAnonymous
February 04, 2009
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, BrunoAnonymous
February 05, 2009
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érardAnonymous
February 06, 2009
The comment has been removedAnonymous
February 07, 2009
I count around 4150 - where are the other 2885?Anonymous
February 09, 2009
The comment has been removedAnonymous
February 09, 2009
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érardAnonymous
March 16, 2009
"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?Anonymous
March 24, 2009
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?...