Re: SVG in text/html

Hi, Jirka-

Jirka Kosek wrote (on 10/14/2007 5:31 PM):
> Doug Schepers wrote:
> 
>> Most tools do include XML prologs and DOCTYPES in their SVG output...
>> what affect will this have on a whole-file copy-paste into HTML, in
>> terms of parsing?
> 
> Many SVG tools use internal entities in produced content.

I'm not sure that's correct.  Certainly, Illustrator does, and there's a 
lot of Illustrator content... but off the top of my head, I can't think 
of any others that are pernicious about that.  Maybe CorelDraw?  I don't 
think Inkscape does.  Can you identify other common tools that do?

My point is that a relatively small number of authoring tools would need 
to be changed to affect the majority of output... they could simply 
offer a "Save as inline SVG" option, even.


> As SVG has to be normalized before inserting into HTML -- at least
> !DOCTYPE has to be removed and entities expanded, most likely also CDATA
> section removed I don't see any compelling reason why not to "normalize"
>  HTML into XHTML before insertion of SVG fragment also. 

I don't agree with your reasoning.  Because the author might have to 
normalize one document type, they should have to normalize the other as 
well?  That's at least twice as much work, and probably quite a lot 
more: the number of changes that would need to be done to a conforming 
SVG fragment in order to align it to what's needed for HTML5 would be 
far less work than converting a conforming HTML5 text/html file to 
XHTML, and it's very likely that the HTML file would have more content 
to be converted.  A simple script could strip out the offending SVG 
detritus, and prepare the file for insertion into HTML very easily.

We've already cited the fact that there are complications to changing 
your host-language infrastructure... forcing authors to convert all 
their pages to XHTML would result in almost nobody bothering to use any 
inline SVG at all.


> That way there will be no need to mangle HTML syntax to accept
> SVG fragments.

I think "mangle" is hyperbole.


> If you really think that HTML should be able to accept SVG, MathML, ...
> fragments then HTML syntax should be defined in a more generic manner as
> an alternative seralization of XML Infoset.

The solution Henri (perhaps with input from others, like Sam, Simon, and 
Anne?) put forth seems like it may be headed in that general direction, 
but let's not jump to that conclusion.  If it can be special-cased for 
SVG, I think that would be a win even if it didn't extend to any 
arbitrary XML.


Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Monday, 15 October 2007 23:31:44 UTC