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