Re: SVG in text/html, getting closer

Hi, Cam-

Cameron McCormack wrote (on 3/9/09 1:12 AM):
>
>>  I don't see a real use-case here
>
> The use case, as we originally discussed during the F2F, was to overcome
> two issues that would arise if an SVG document were accidentally served
> as text/html rather than image/svg+xml:
>
>    * That the<svg>  element is placed under a<body>  means that it is a
>      CSS replaced element, and that strange sizing will take place that
>      makes the SVG fragment not take up the whole browser window if the
>      <svg>  element has width="100%" height="100%" (the defaults), as it
>      would if it were served as image/svg+xml.
>
>    * That script in the document that assumes document.documentElement is
>      the root<svg>  element will break, since document.documentElement is
>      the root<html>  element.
>
> with a bit more emphasis on the first point than the second.  It was
> thought that if the<html>  and<body>  elements weren’t created when the
> first open tag encountered was<svg>, that it could solve both of these
> problems.  We recognised that this solution would be problematic if HTML
> content were encountered at a place within the SVG fragment that would
> need to break back out to an HTML context, since there’d be no<body>
> element on the stack of open elements.  Henri followed through on this
> idea and suggested a way to get around that problem, namely the
> reparenting of the<svg>  to newly created<html>  and<body>  elements, if
> such broken content were encountered.

To clarify: I don't see a compelling use-case for doing this 
*purposefully*.  Situations where the server is misconfigured, where the 
author accidentally gave the file an "*.html" extension instead of 
"*.svg", etc. are a different matter that I am inclined to treat more 
sympathetically.

Henri was pretty clear that he wasn't trying to solve the borken case, 
as we discussed, but rather to propose some new behavior. [1]  And even 
he didn't claim to be advocating for it, just noodling out a possible 
solution.


> Having said that, I’m still not sure if making whole-SVG-document-
> served-as-text/html work properly is worth the effort, since:
>
>    * Anne did point out that a particular CSS rule in a user agent style
>      sheet could solve the first point without having to make the<svg>
>      the root, but I can’t seem to find the mail/IRC link at the moment.
>
>    * Scripts that assume document.documentElement is an<svg>, in
>      documents that are pasted in the middle of an HTML document, would
>      need to be fixed up anyway, since there’s no sane way to make
>      document.documentElement return the<svg>  element in this case.
>
>>  and tying ourselves to a drastic solution like Henri proposed seems
>>  like it will make it more difficult to code cleanly in XML-next, with
>>  more permissive error recovery.
>
> Could you elaborate?

No.

:)

Or rather, I just don't see the benefit in doing this on purpose, so I'm 
not particularly eager to invest energy catering to that case.

I guess my thought are vaguely along the order of... if something is 
codified in HTML5, and down the pipe the XML community changes XML to be 
permissive-but-not-identically-to-HTML5 (as I think is likely), but 
there is already some sort of established back-door practice where 
people just use HTML5 algorithms for parsing SVG, then SVG is forked in 
multiple incompatible ways.  Or something.

But it's late here, and I'm not feeling very articulate.

[1] http://lists.w3.org/Archives/Public/www-archive/2009Mar/0011.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 9 March 2009 06:09:13 UTC