Re: SVG in text/html, getting closer

Hi Doug.

Cameron McCormack:
> >    * Should prefixed svg elements work (be put in the proper namespace)?
> >
> > I don’t think we need to try to support such content in HTML.

Doug Schepers:
> It's legal in XHTML, though I don't know how common in general that  
> practice is.

Neither do I, unfortunately.  My gut feeling is that it is much less
common than using the default SVG namespace.  For three blogs that I can
think off the top of my head that use SVG in XHTML, none of them use
prefixes:

  http://intertwingly.net/blog/
  http://blog.codedread.com/
  http://realtech.burningbird.net/

Anecdotal evidence only, of course.  The MAMA survey did look at the use
of SVG in XML documents:

  http://dev.opera.com/articles/view/mama-xml/
  http://devfiles.myopera.com/articles/591/nsnamelist-url.htm

Of the ~650,000 XHTML (or XHTML mis-served as text/html) pages, 19
declared the SVG namespace.  That doesn’t given an indication about
the use of prefixes, but this might indicate that the use of SVG in
XHTML currently is small enough that restricting ourselves to non-
prefixed elements wouldn’t be a problem.

I’m not aware of any authoring tool that produces SVG content with
prefixed SVG elements.

> Ideally, SVG in text/html would not be too far off from SVG in XHTML.

Ideally, I agree.

> What are the constraints that make permitting this troublesome (other
> than the general distaste for XML Namespaces)?

Just that it is more work for little practical gain, as I see it.

AFAICT, the only advantage using prefixed element names gives you is
that it the overhead of including a default namespace declaration
attribute.  This overhead is really only significant when there is a lot
of interleaving of differently namespaced elements (like in RDF/XML).  I
wouldn’t imagine that there would be enough interleaving of SVG and
(X)HTML to warrant saving the characters of the default namespace
declaration.

Disadvantages could include:

  * the implementation needing to track arbitrary prefix declarations,
    rather than a single default namespace declaration attribute.

  * the possibility of this interfering with a more general solution to
    distributed extensibility in text/html syntax, by giving meaning to
    QName SVG tag names but not others.

Implementors would be in a better position than me to continue that
list.

> This is not a critical issue to me, but I'd like to see some evidence  
> that it's a real problem, rather than an arbitrary decision.

If prefixed SVG content isn’t useful in practice, and there is
resistance to including it (as I suspect there will be), then I don’t
think we should push for it.  There are various other aspects of XML
syntax that we don’t care about (such as processing instructions,
unparsed entities); for me it’s not a critical issue either.

> >    * How do we fix our suggestion that about not generating implied
> >      <html> and <body> open tags when the <svg> open tag is the
> >      first one encountered?
> >
> > Not sure yet.
>
> Flag the MIME Type as an error for the console, and parse it as XML?  

That’s a possibility.  Would it be a violation of some web architectural
rule to override the server sent Content-Type like this?  (Maybe.)

> This would be problematic if the person wanted to have SVG as the root  
> with some text/html in <foreignObject>... But in that case, they could  
> simply make the root <html>.

True.

> 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.

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?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 9 March 2009 05:13:35 UTC