Bring up this site in IE7. The entries are neatly and consistently indented under the titles. And there is a Nav Bar on the right.
Bring up this same site in Internet Explorer 8 Beta 1. The first entry is indented under the title. The remainder are bizarrely indented. And the Nav Bar is no where to be seen.
So much for X-UA-Compatible, in either the HTTP header form or the meta
tag form, as this site currently sports both.
Bring up this site in IE7. The word intertwingly at the top doesn’t show. The page isn’t exactly gorgeous. But the entries are neatly and consistently indented under the titles. And there is a Nav Bar on the right.
Bring up this same site in Internet Explorer 8 Beta 1. The word intertwingly still doesn’t show. The page still isn’t exactly gorgeous. The first entry is indented under the title. The remainder are bizarrely indented. And the Nav Bar is no where to be seen.
So much for X-UA-Compatible, in either the HTTP header form or the meta
tag form, as this site currently sports both.
Yes, this site was busted for several hours while I was experimenting. Lessons:
Well, I actually think the switch works but maybe the “IE7 emulation” is broken: if I force IE7 emulation in IE8b1, I have the exact same behavior you describe.
Moreover, typing javascript:alert(document.documentMode)
in the location bar alerts “7”.
In brief, the switch works, but IE8’s “IE7 standards renderer” seems not be the one shipped with IE7. Sigh...
Sam, have you opened the developer tools?
It seems that in the first article, the SVG is parsed as in IE7 (i.e. there’s an empty SVG
element followed by 2 PATH
elements and a /SVG
empty element). In the following articles, the SVG is parsed differently (don’t ask me why, I still don’t have found the pattern), i.e. there’s an svg
element (note the lowercase tag name) containing the path
and circle
elements. The problem then is that the SPAN
containing the SVG isn’t “closed”, so the article content is within that SPAN
, which has style="width:5.625em; height:6.25em; float:right"
.
Even more bizarre, starting with the fourth article, the articles are embedded within each others: the fourth article is the last child of the third one, the fifth one a child of the fourth one. But starting with the sixth article, they’re all siblings (children of the fifth article)... and the SVG is correctly parsed! (parsed as “namespaced”, and the containing span
or div
is correctly closed before the article content).
The aside
is a child of the fifth article too, so you can see the nav bar at the very end of the page, although, strangely, the links are not working.
I suspect the “namespace support” is still being use at the parsing level (the “IE7 mode” is said to be about the User-Agent string, version vector and layout engine, not the parser...) and something makes your articles being parsed within the SVG namespace (so the nav bar links actually are in the SVG namespace, so they’re not recognized as links). Actually, starting with the fifth article, there are no more link or formatting (everything’s probably parsed in the SVG namespace).
I believe there should be a way to tweak you inline SVG to make IE8 parse it without messing up with the rest of the page.
(note that this is confirmed by the Live DOM Viewer, using the developer tools to set the compatibility mode to "Strict(Internet Explorer 7)")
have you opened the developer tools?
Nope. In fact, for the moment, IE-8 beta is uninstalled. But good detective work. It appears that the parser in the beta needs a bit of work. Hopefully somebody from Microsoft will use this page as a test case.
I found that the x-ua compatible tag does trigger IE7, but it must be located right after your HEAD tag. Further down after page title etc and it doesn’t trigger.
That said, the IE7 mode in IE8 does not seem to render identically to IE7. I found several problems on some of my sites that we never had with IE7, even in compatibility mode. And IE8b is buggy in the extreme. I installed it on two machines and it crashes all the time on both. Now I know it is beta, but Firefox betas never do this to me, I have always used them and found them pretty reliable (even from beta 1). I have FF3b5 running as I write this, and it works great - it is production quality.
I would agree that the x-ua tag is not the ideal solution to cross browser support, but i understand why MS have done it. And as a web developer, at least we have options to deal with the new browser until they make it work properly and render like Opera, Firefox and Safari (which I never seem to get problems with). IE8 has real issues with floated divs and quite a few other rendering problems.
Hopefully in maybe 5 years time we can forget about non-compliant browsers as all will be standards compliant.