tags:

views:

375

answers:

2

I'm confused.

If I point by browser (Chrome or Safari on OSX) to this web site, it shows all the SVG perfectly:

http://emacsformacosx.com/

Now, if I view source on that page, copy it, and paste it into a new HTML document on my desktop, then view that with either browser, I get no SVG at all.

Why the difference?

Why does SVG work on the web site, but not in the local HTML file?

Thanks!

+8  A: 

You renamed it to HTML, and the browser assumes html content.. while the page is text/xml ..

if you rename it to .xml and open it, you will see it just fine..

Gaby
Confirmed. Reproduced and fixed using this method on Mac OS X 10.6.2
Pestilence
Interesting.Should all HTML5 documents have a .xml extension, or is this just a function of having SVG in the document?
Axeva
i just toyed a bit and it seems that both FF and Chrome also render correct with an `.xhtml` extension ... It seems plain wrong that they will not accept a definition of content from inside the file (the meta tag for instance..), but it seems to be the case..
Gaby
@Axeva, i wouldn't know .. haven't used html5 yet.. so i have no experience on it.. You could do some tests and lets us know :)
Gaby
+4  A: 

The HTTP response header information causes the browser to interpret the information as XML:

HTTP/1.1 200 OK
Date: Sun, 21 Feb 2010 02:32:02 GMT
Server: Apache/2.2.14 (Debian)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8

You see, the server that served up the page was smart enough to detect that this was an XML document, and told the browser. When you load the file from disk, your browser may not be smart enough to do this, and tend to rely on the file's extension to supply this information.

You could try inserting the following into the <head> element:

<meta http-equiv="Content-Type" content="text/xml; charset=UTF-8" />

You see what I did there? It's just a mirror of the HTTP response header that would have specified the document type and encoding.

The purpose of this tag is to make browsers think, "Hey, the server is telling me that this document is HTML, but the document is telling me it's XML. The document probably knows better than the server, so I'll trust it... ::interprets as XML::"

amphetamachine
that should be the case but unfortunately it is not.. it will still not render it correctly..
Gaby
Unfortunately, Gaby is right. It doesn't work.You've come up with an elegant solution Amphetamachine, but the browser is ignoring it.Frustrating.
Axeva
Browsers = stupid
amphetamachine