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
Anonymous
March 20, 2009
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;-)Anonymous
March 20, 2009
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 :)Anonymous
March 20, 2009
Here are a few that IE8 fails: http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/sgml-comments-000.htm http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040303-c62-percent-00-b-ag.htm http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/content-counter-006.htm http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040306-c63-color-00-b-ag.htm http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t100801-c548-ln-ht-03-d-ag.htm And this one, the one that Dean showed in his keynote, is the only one I've found so far that IE passes while Firefox fails: http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t0803-c5502-imrgn-r-02-b-a.htmAnonymous
March 20, 2009
Oh, seems like three of those failed because of ClearType. Still, two fail with ClearType inactivated.Anonymous
March 20, 2009
@David Naylor Here are some details on each of the tests you mention: http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/sgml-comments-000.htm - This is a build issue bug with the test suite. See http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0027.html">http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0027.html http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040303-c62-percent-00-b-ag.htm - This isssue most caused by ClearType being enabled. I actually pass this on all my tests machines with ClearType disabled. http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/content-counter-006.htm - This is a bug in the test case, see http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0026.html">http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0026.html http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t040306-c63-color-00-b-ag.htm - This isssue most caused by ClearType being enabled. I actually pass this on all my tests machines with ClearType disabled. http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t100801-c548-ln-ht-03-d-ag.htm - 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. http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/Anonymous
March 20, 2009
heh heh - I would state that ClearType by itself is a FAIL. Can't stand it at all.Anonymous
March 20, 2009
@David - This one fails for me in Firefox AND IE8 (compat and standards mode) http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t0803-c5502-imrgn-r-02-b-a.htmAnonymous
March 20, 2009
The comment has been removedAnonymous
March 21, 2009
@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?Anonymous
March 21, 2009
Unfortunately http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=348757 still fails, which breaks my page ('expand' links on http://philip.html5.org/tests/canvas/suite/tests/ ), 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!Anonymous
March 21, 2009
@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.Anonymous
March 21, 2009
The comment has been removedAnonymous
March 21, 2009
The tests do not just require cleartype disabled but really require the AHEM font installed to work. Download thte TTF file from here: http://www.hixie.ch/resources/fonts/ and install the download file (rightclick => install)Anonymous
March 21, 2009
@hAl: Some tests really do fail with ClearType, though..Anonymous
March 21, 2009
For the required fonts, please go to http://dev.w3.org/CSS/fonts/ahem/ The standard and authorized tests from the W3.org, not an individual.Anonymous
March 21, 2009
The comment has been removedAnonymous
March 21, 2009
@James: 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.Anonymous
March 21, 2009
The comment has been removedAnonymous
March 21, 2009
Um, why would you guys keep commenting here instead of going to the real CSS working group list and having the discussion there?Anonymous
March 21, 2009
The comment has been removedAnonymous
March 21, 2009
@Gérard: "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.Anonymous
March 21, 2009
@Mike Laverick: IE8 uses the same certificate-handling code as IE7. What is the exact text of the certificate warning page? thx!Anonymous
March 21, 2009
@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. @Gérard: 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. Thanks, -ArronAnonymous
March 21, 2009
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' samples.msdn.microsoft.com/ietestcenter/frame_holder.htm?url=./css/chapter_17/rules/table-height-algorithm-005.htm samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/table-height-algorithm-005.htm Test 6764: Setting a percentage 'height' on row computes to 'auto' samples.msdn.microsoft.com/ietestcenter/frame_holder.htm?url=./css/chapter_17/rules/table-height-algorithm-006.htm samples.msdn.microsoft.com/ietestcenter/css/chapter_17/rules/table-height-algorithm-006.htm 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érardAnonymous
March 21, 2009
@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.Anonymous
March 22, 2009
"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 : http://www.hixie.ch/tests/adhoc/css/fonts/weight/002.html 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? http://www.w3.org/TR/CSS21/fonts.html#font-boldness 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.Anonymous
March 22, 2009
@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 implementedAnonymous
March 22, 2009
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.Anonymous
March 22, 2009
@Wil: The blog code and the IE code aren't written by the same people. @hAl: 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 IE8.next page that lists only bugs that are currently exposed in IE8.Anonymous
March 22, 2009
I would like to know in what way Cleartype and/or font-smoothing would interfere with the correct rendering of the spec. Why?Anonymous
March 22, 2009
The comment has been removedAnonymous
March 22, 2009
@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érardAnonymous
March 22, 2009
"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érardAnonymous
March 22, 2009
@Gerard Talbot Keep the id's on for the current bugs and use only the href names for new bugs ?Anonymous
March 22, 2009
@Gerard for your bug #13 Is height actually a valid attribute for tbody ?Anonymous
March 22, 2009
"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." @Thomas: 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 : http://www.w3.org/TR/CSS21/fonts.html#font-boldness "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.Anonymous
March 22, 2009
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.Anonymous
March 22, 2009
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?Anonymous
March 22, 2009
@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.Anonymous
March 23, 2009
@hAl, "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.Anonymous
March 23, 2009
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) thanksAnonymous
March 23, 2009
The comment has been removedAnonymous
March 23, 2009
@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).Anonymous
March 23, 2009
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? Thanks. JohnAnonymous
March 23, 2009
The comment has been removedAnonymous
March 23, 2009
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. Thanks! JohnAnonymous
March 23, 2009
@Mark Turner: This test (http://www.hixie.ch/tests/adhoc/css/fonts/weight/002.html) 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.”Anonymous
March 23, 2009
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.Anonymous
March 23, 2009
@Arron Eicholz [MSFT] connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=361181 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. webdevout.net 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. connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=407963 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. connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=361953 webdevout.net 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. connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=354316 webdevout.net 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) b) www.hixie.ch/tests/adhoc/css/cascade/import/002.html clearly shows IE 8 limitations connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=409470 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érardAnonymous
March 23, 2009
13- tbody {height: 150px; overflow: auto;} does not work 'overflow' 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érardAnonymous
March 23, 2009
> 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érardAnonymous
March 23, 2009
The comment has been removedAnonymous
March 23, 2009
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.Anonymous
March 23, 2009
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." because
- 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
Anonymous
March 23, 2009
@hAl, "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.Anonymous
March 23, 2009
The comment has been removedAnonymous
March 23, 2009
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.Anonymous
March 23, 2009
@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.Anonymous
March 23, 2009
@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érardAnonymous
March 25, 2009
Nobody takes the SGML comment requirement seriously, not even Opera. http://ln.hixie.ch/?start=1137799947&count=1 (This shows that Opera does, at some level, understand standard/legacy trade-offs. Just not at a level that makes business sense.)Anonymous
March 25, 2009
@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érardAnonymous
March 31, 2009
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.Anonymous
April 01, 2009
John, per http://support.microsoft.com/gp/lifesupsps/#Internet_Explorer, 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.