It’s just data

“Improved” Namespace Support

Internet Explorer 8 Beta: The Features: Internet Explorer 8 simplifies the use of standards-compliant XML-based webpages that support namespace features like scalable vector graphics, XML user interface language, mathematical markup language, and others.

To see the above text, click on “Faster, Easier”.  Intuitive, I know.

Let’s give it a spin.  First on my full-on XHTML version of my front page, complete with SVG: IE8b2 will helpfully ask you if you wish to download it.

Now lets try another version of that page which is served as text/html to IE, again with embedded SVG, and marked as X-UA-Compatible: IE=7.  Whereas previously, it wasn’t all that compatible, IE8b2 at least attempts to be more compatible (complete with the invisible h1), until it gets to the SVGized W3C logo.  As SVG images go, you can’t get much simpler than this: two consecutive path statements.  But apparently, that’s beyond the limits of what IE8b2 supports, and it basically gives up parsing markup on the rest of the page.  Converting the self-closing path elements to use explicit open and close tags works around the issue.

Finally, lets try something really simple.  No SVG.  No X-UA-Compatible.  Served as text/html.  The result: no CSS support for elements introduced in HTML5.  While one can coax such support out of IE7 — and IE8 will even emulate that behavior when told to do so — I’m not aware of any equivalent mechanism for IE8.

Note: none of these pages were adjusted in any way to make IE8 look bad.  They existed well before the beta was made available, and today was the first day I had access to IE8b2.


Just so I’m sure I understand:

<ol>
<li>XHTML not supported in IE8 (already knew this)</li>
<li>IE8 in Standards Mode no longer allows the createElement hack?</li>
<li>Inline XML has to have explicit closing tags?</li>
</ol>

Posted by Jeff Schiller at

I don’t believe that I have enough data to draw the third conclusion.  In particular, the SVG icon that I’ve included on this post also consists exclusively of two self-closing path elements, and doesn’t seem to cause IE8 any problems.

Posted by Sam Ruby at

Is it just me, or do the first two test cases presented here not display properly in Firefox 3?

Posted by Scott Johnson at

<q>XML user interface language</q> surely isn’t abbreviated “XUL”, what do they mean with it?

Why are the screenshots so huge (1920x1200 white padding)?

Posted by hdh at

Scott: can you describe what problem you are seeing?  Firefox 3.0.1 is my primary browser, and I see no problem.

hdh: I’ve now cropped the screenshots.  As to Microsoft’s level of understanding of the technologies they purport to enable... that’s something you will have to take up with them.

Posted by Sam Ruby at

Sam:  Here’s a Firefox screenshot.

Posted by Scott Johnson at

Forgot to add this:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Posted by Scott Johnson at

Will IE8 be the new IE6 ?

submitted by henryprecheur [link] [2 comments]...

Excerpt from programming: what's new online at

I’ve got the exact same setup:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I’m not seeing the problem.

The symptoms are consistent with that page not being served as application/xhtml+xml, as the default behavior of at least two browsers (Firefox and Opera, IIRC) would not see the closing svg tag as closing all the intervening “self-closing” tags.

But you haven’t mentioned seeing that on my main blog — where I do the same thing, and try to do content negotiation.  And that wouldn’t explain you seeing something odd on the third test.

Posted by Sam Ruby at

But you haven’t mentioned seeing that on my main blog — where I do the same thing, and try to do content negotiation.  And that wouldn’t explain you seeing something odd on the third test.

I do see it on the main blog as well as the Rails version.  I just tried switching to a different proxy here at work, and that seemed to clear up the problem.  I’m thinking that the proxy I’ve been using is mangling the content type.  Further testing and/or complaints to proxy vendor will ensue.  :)

Posted by Scott Johnson at

[link]

Posted by Anne van Kesteren at

Look at Tools -> Page Info.  Type should be application/xhtml+xml.

Posted by Sam Ruby at

Try “X-UA-Compatible: IE=EmulateIE7” instead of "X-UA-Compatible: 7.0000"?

Posted by Joe Chung at

Ack, never mind, you’ve got a lot more going on in this page than correcting the X-UA-Compatible header will fix.

Posted by Joe Chung at

Sam, I’m probably dense from tech editing, but I can’t see the text you reference, or even the link to click to get to the text. Is it still there? If so, I’ll have a cup of coffee and look again.

Posted by Shelley at

This is what I’m serving:

$ curl -s --head http://intertwingly.net/blog/ | grep UA
X-UA-Compatible: IE=7

(Note: this is quite different than what you reported)

I did a test of this:

$ curl -s --head http://intertwingly.net/blog/ | grep UA
X-UA-Compatible: IE=EmulateIE7

And produced this.

My read is that the header I’m providing is causing IE8b2 to attempt to emulate IE7, but it falls short.

But I must say that I’m honored that you stopped by, and will attempt to address any suggestions you might have.

Posted by Sam Ruby at

Shelley, it looks to me like I should have taken a screen shot of that page too, as that text is indeed now completely gone.

Posted by Sam Ruby at

Update: According to the IEBlog, IE8 intends to support both; the difference being that IE=EmulateIE7 considers the HTML5 DocType to be a “quirks DOCTYPE” and will inexplicably no longer recognize foreign markup in such pages the way that IE7 used to.

The bug reported by Phillip Taylor and mentioned here by Anne van Kesteren is spot on.

Posted by Sam Ruby at

Still up for grab. <a href="http://hdh.dyn-o-saur.com/pic/OMG-IE8b2-supports-XUL.png" title="pardon the filename">screenshot</a>

Posted by hdh at

Look at Tools -> Page Info.  Type should be application/xhtml+xml.

I just got around to confirming the issue that I mentioned above.  I am definitely seeing ‘text/html’ though the proxy where I saw the strange formatting.  And I’m definitely calling that proxy vendor on Tuesday to complain, 'cause I had already asked the proxy to not mess with my Content-Type headers.

Posted by Scott Johnson at

I am definitely seeing ‘text/html’ though the proxy where I saw the strange formatting.

That should be "through the proxy".

Posted by Scott Johnson at

How odd. When I access the bug page with Firefox, I can see the page. When I access the bug page with IE8b2, I get an error that I don’t have permission to access the page.

I’m still trying to find my way through the convoluted patterns of access that IE8 implements. What am I doing wrong?

Posted by Shelley at

I think I answered my own question. I had a LiveConnect account to turn in bugs on Expression Media, and when I access the bug page, it remembers me and asks if I want to sign out.

I try, and I also deleted cookies, et al, but Microsoft does not actually delete the LiveConnect cookies, and that LiveConnect cookie is keeping me from seeing the bug in LiveConnect.

So no matter what I do, I’ll never be able to see this page, or get rid of the cookies Microsoft itself set.

Bad browser. Bad, bad, browser.

Posted by Shelley at

IE8 beta 2: First Experiences

My first experiences with IE8 beta 2 have been mixed. On the one hand, I like the fact that compatibility mode no longer requires restarting the browser. However, I’ve found it virtually impossible to tell when I have compatibility mode turned on...

Excerpt from Burningbird's RealTech at

Wow.  There now are six modes.

Posted by Sam Ruby at

Add your comment