IE 8 is platform complete
I know I’ve gotten behind on browser testing, but I’ll definitely be reserving some time in the next couple of weeks to run the newly released IE 8 release candidate through the gauntlet, as well as bringing the Firefox and Opera information up to date. Safari might even get some love, if I can find enough time to get it all done.
January 28th, 2009 at 13:23 UTC
I tested the betas, and could see CSS bugs popping on and off. I’ve also found a regression (I can’t seem to post a comment any more, and I’ve been locked away from their bug reporting tool since forever) in RC1 compared with Beta 2 (to be fair, said regression was present in the leaked Partners build).
I’m looking for anyone who could reproduce the issue on his machine (my XP is running inside a VM; this image has seen better days); said regression is test case 3 on my regression tests page.
It’s a nasty one, dealing with margins collapsing computation on box container resize if one of those margins is negative.
Posted using Mozilla Firefox 3.0.5 on Linux.
January 30th, 2009 at 14:58 UTC
IE7 RTM was different to IE7 RC1 so I think you should wait until IE8 RTM is released. Testers have already identified some regressions, so I think there surely will be some polish to IE8 before release.
By the way, are you currently working on your tables? For Firefox 3 there’s a small mistake. The bug where “a left-floated box with a right-floated child and computed width of ‘auto’ expands to the container’s width” (and vice versa) seems to be fixed in 3.0
@Mitch: I will look into you testcase and file a bug if necessary after I went through my own testcases. Sadly RC 1 regressed a few things..
Posted using Mozilla Firefox 3.0.5 on Windows.
February 1st, 2009 at 15:36 UTC
@Daniel: thank you. I’ve seen your comment on the IEblog. Interestingly, it’s the second bug I find in IE that is new, and where I need somebody’s help to record (first one was reported and simplified by Gérard Talbot); every time I try to create a reporting account, or to log a bug, I get an ASP server error. Maybe I need to open said account through IE/Win…
I found a few regressions inside the Partners’ build, but they fortunately went away in RC1. I haven’t tested RC1 more thoroughly yet, though.
Posted using Mozilla Firefox 3.0.5 on Linux.
February 8th, 2009 at 10:03 UTC
IE8 is feature complete and allthough the RC1 version might still have some minor bugs in CSS (as have all browsers) it should go high in the nineties percentile for CSS2.1 support now.
That would really leave only limited rechecks for de the final release.
Posted using Internet Explorer (Windows) 8.0 on Windows.
February 8th, 2009 at 10:13 UTC
At least it now passes all your gathered IE7 bugs on this page
http://www.webdevout.net/testcases/ie7-mass/
Posted using Internet Explorer (Windows) 8.0 on Windows.
February 13th, 2009 at 15:52 UTC
@hAl: As I said some time ago, I think one test in this testcase is wrong. I’m talking about the tests that looks for an empty attribute to become attr=attr;
Firefox, Safari and Opera have moved their behaviour to HTML5’s definition which says that attr should become attr=”".
Posted using Mozilla Firefox 3.0.6 on Windows.
February 13th, 2009 at 20:54 UTC
My test case is correct on the empty attribute feature. It’s testing against the HTML 4.01 standard, which is an SGML language and follows SGML parsing rules. HTML 5 is not an SGML language, and it deviated from SGML on this issue. Browsers should follow the HTML 5 rules on documents deemed to be HTML 5 documents, but they technically should follow the HTML 4/SGML rules on documents with an HTML 4 doctype.
The only “error” here is the fact that the specifications of HTML 4 and HTML 5 demand different parsing rules. Unless the W3C, in a finalized Recommendation, explicitly states that browsers are to use the HTML 5 parsing rules on existing HTML 4 documents, my test case remains correct.
Posted using Mozilla Firefox 3.0.5 on Linux.
February 14th, 2009 at 15:04 UTC
I understand your point of view, it’s true that HTML 4.01 is an SGML application. However, for this topic not only technical facts need to be considered.
Technically, browsers should render accroding to the doctype, but they actually render simply what’s implemented. Thus technically, browsers parse HTML 4.01 as SGML and HTML 5 as HTML 5. But actually, browsers parse both HTML 4.01 and 5 as one and the same thing.
HTML 5 defines what HTML 4.01 didn’t when it was already clear that browser vendors won’t implement SGML. And look, only one year ago, the case discussed above had 4 different parse results. Due to HTML 5, all except one engine do the same thing.
IE changed it’s behaviour from totally wrong to SGML-half-wrong. Which is completely inconsistent with decisions like implementing other HTML 5 features.
I don’t really mind it, because it’s an edge case, it simply shows that IE is not yet completely on the right way.
By the way: When the W3C HTML working group decided to base their work of HTML 5 on the Web Applications 1.0 spec, they agreed that
Posted using Mozilla Firefox 3.0.6 on Windows.
February 27th, 2009 at 19:06 UTC
Any preliminary findings ?
Like a big hole in IE8 css support somewhere ?
Posted using Internet Explorer (Windows) 8.0 on Windows.
February 27th, 2009 at 20:29 UTC
@hAl: Depends on who you ask. Surely, their CSS 2.1 implementation is great. But like other implementations, it got some bugs.
I personally think it’s bad that IE 8 still accepts CSS files that are not sent with the text/css media type. That’ll make IE the only browser that has this bug and will have it for the next decade.
IE also continues with the bad habit of restricting the @import rule to 3 levels of nesting.
On the other hand, IE 8 excels in rendering border-collapsed tables. A part of the spec that’s not very well implemented in other browsers.
Posted using Mozilla Firefox 3.0.6 on Windows.