Re: SVG in text/html

Hi, Henri-

There's a small chance that I'm not as conversant in the details of the 
HTML5 parser as you, so I don't know the constraints that it has when 
dealing with SVG (or any XML, for that matter).  However, I was able to 
follow the steps you described, even if I'm not fully aware of the 
rationale behind all of them.  Thanks for the detailed analysis... it 
was both edifying and encouraging.


Henri Sivonen wrote (on 10/13/2007 10:43 AM):
> 
> Do you mean you'd like to bring in the complication of arbitrary 
> namespace prefixes? 

Not necessarily.  I'm fine with imposing certain limitations on SVG 
content, assuming that it's a set of limitations that can be easily 
obeyed by authoring tools (and which, preferably, existing authoring 
tools abide by anyway).  The most important thing for me is that SVG 
fragments from an HTML+SVG (SVG-in-HTML) compound document could be 
extracted as standalone SVG documents; the second most important thing 
is that the most likely content from standalone SVG documents should 
work as an SVG fragment in HTML (this is second because I think it is 
likely that this will be the case, given existing SVG content-creation 
tools).


> I'd like make the following deviations from
> SVG-as-XML syntax:
>  1) I'd like to minimize the need of tokenizer parametrization to 
> toggling case folding behavior and, if we must, CDATA sections. 

Strictly speaking, CDATA sections are not required in SVG, but as you 
know, script will break in an XML parser it if doesn't escape its "<" 
and "&" characters.  The majority of SVG authoring tools, I suspect, are 
not script-aware: they are just drawing apps that export to SVG; people 
savvy enough to be scripting can be expected to take precautions and 
read FAQs to resolve their problems there.

Even drawing tools, though, are likely to use CSS, and may automatically 
enclose it in a CDATA section "just to be safe".  It would be worthwhile 
to look at the survey of tools and see if they do this, and if so, if 
they can be encouraged to change this practice.

I would prefer that CDATA be allowed, but it's not a deal-breaker.  I 
confess I don't know why it's a problem in the HTML parser, though, if 
you care to explain.

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?


> Specifically, I think attribute tokenization should run the same code as 
> attribute tokenization for the HTML parts of text/html.

Could you elaborate on that?  What are the implications?


>  2) I'd like to avoid supporting arbitrary namespace prefixes both in 
> order to sidestep issues in shipped IE versions and in order to relieve 
> authors of namespace syntax. (xlink: should probably be considered 
> non-arbitrary and hard-wired.)

I think it's reasonable both to limit arbitrary namespace prefixes in 
HTML+SVG, and to hard-wire the XLink namespace.  That SVG-fragment 
content will still work as expected in a standalone SVG UA, and most 
people trying to do clever things in namespaces will probably be using 
XHTML+SVG anyway.


> The above trial balloon proposal is designed to optimize SVG integration 
> in text/html in *future* browsers in a way that would create a 
> namespace-aware DOM that current DOM-based SVG implementations would 
> grok immediately but would at the same time remove namespace declaration 
> syntax from the sight of authors. The proposal specifically isn't 
> designed to clone the colon-based namespaces-in-text/html mechanism of 
> IE. OTOH, it shouldn't interfere with it, either, except perhaps for 
> xlink:href, which could be worked around by introducing href.

I'm still on the fence about 'null:href'.  Can you explain in detail why 
this is so problematic in HTML5 (especially given that SVG isn't 
natively supported in IE anyway)?


> The approach outlined above could be used for MathML as well. However, 
> in that case, the tokenizer should probably me modified to switch to 
> MathML entity tables when the tree builder is in a MathML scope.

I agree it's a good idea to look at the most common XML presentation 
formats and generalize the solution.


> I agree it would make sense to talk about it at the Tech Plenary.

I'll coordinate with the respective chairs and try to lock down a time 
and day.  We can communicate offlist about who would be good to have 
around and what their attendance schedules are.

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

Received on Saturday, 13 October 2007 20:21:09 UTC