Re: SVG in text/html, getting closer

On 3/3/09 1:24 AM, Cameron McCormack wrote:
>   * When SVG fragments in HTML are encountered, any invalid element or
>     attribute casing should be generating parse errors. Such content
>     should be non-conforming. There’s no consensus yet on whether such
>     fragments should work/render (awaiting feedback from jwatt) 

I think authors should be able to use any case for SVG element and attribute
names when the SVG markup is in HTML. It would be inconsistent with HTML not to
allow this.

>   * Should xmlns:xlink="foo" mean that xlink-prefixed attributes get put
>     in the right namespace? If you have xlink:href in the right scope
>     should that attribute be put in the xlink namespace or be a parse
>     error? 

One of the consequences of the namespaces idea I voiced at the march 9th telcon
(essentially having HTML5 provide defaults for namespaces instead of hardcode
them) would be that specifying xmlns="not-the-SVG-namespace" or
xmlns:xlink="not-the-XLink-namespace" on <svg> would mean that "SVG" elements
and "XLink" attributes would be unknown elements and attributes. As stated on
the telcon, I do *not* think this would be a problem in practice, since in HTML
authors would likely omit the declaring namespaces (or declare them correctly),
so they'd get the correct defaults, and in protean HTML-XHTML documents the
author would *have* to be specifying them correctly for when the document is
served as XHTML.

>   * Instead of requesting that unquoted attributes etc. be parse errors,
>     should we instead suggest that authors write polyglot SVG-in-HTML
>     and SVG-in-XHTML documents, and validate against both of those
>     schemas? 

I'm in two minds on whether we should be requesting markup that doesn't "look"
like XML no be a parse error. On the one hand is seems to me to go against the
nature of HTML and how authors expect to be able to author HTML documents to get
validators to flag e.g. "wrong" case. On the other hand I think inevitably
authors are going to try to move SVG markup between XML SVG and HTML SVG and
experience pain, so it would be good to encourage authors to use the canonical
case etc. even in HTML. It would therefore simply be a practical measure aimed
at reducing author headaches when using Open Web technologies (and we all know
there are enough of those).

> I’m not sure if recommending the creation of polyglot documents is a
> good idea, due to the issues of differences in XHTML depending on
> whether it is parsed as XML or HTML.  Although I don’t see where there
> would be differences for SVG content.  I think it makes more sense to
> have the conformance errors be in HTML, rather than suggesting authors
> to validate to two different languages.

I don't think suggesting that authors create polyglot/protean documents makes
any sense to me. I thought the whole idea behind requesting that HTML5 make
these things parse errors was to raise awareness of gotchas amongst authors who
are *not* currently concerned with XML, since they or others may wish to move
their HTML SVG markup to XML SVG at some point. Or does anyone have another reason?

>   * Should a missing xmlns="http://www.w3.org/2000/svg" attribute on a
>     root <svg> element be a parse error? 
> 
> Yes, that would be consistent with our other decisions.

As stated, I'm in two minds about these parse errors, but I'm okay with putting
it to the HTML WG and seeing what they say.

Jonathan

Received on Wednesday, 11 March 2009 10:28:23 UTC