SVG in text/html, getting closer

Hello WG.

I’ve incorporated Erik’s points he raised into the SVG in text/html
proposal wiki page:

  http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html_2009

So, to particular points from that page that need addressing.


  * There’s a comment in the HTML5 spec [[<!–XXXSVG need to define
    processing for </script> to match HTML5’s </script> processing –>]]
    Could the HTML WG please clarify what is required with regards to
    that?

This has been clarified by Simon and Henri:

  http://lists.w3.org/Archives/Public/www-archive/2009Feb/0153.html
  http://lists.w3.org/Archives/Public/www-archive/2009Feb/0154.html

and that seems reasonable.  I think we can remove this point, then.


  * 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 am happy for these fragments to work and just be parse errors.  That
is consistent with other decisions we’ve made.


Then, the points under the “unresolved issues (no consensus)” section:


  * 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? 

I am happy for this to remain a parse error but still place the
attribute in the correct namespace.  Another question is whether an
xlink:href="" attribute without an xmlns:xlink declaration in scope
should cause a parse error.  Tracking whether the declaration is in
scope is just one bit of information that needs to be tracked in the
stack of open elements, but it is something.  What about requiring it to
be declared on the root <svg> element, for xlink:href="" in the subtree
to be not parse errors?  That would just need a flag in parser, rather
than carrying around bits in the stack of open elements.


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


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


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


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


Let’s try and get resolutions on the above issues soon.

Thanks,

Cameron

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

Received on Tuesday, 3 March 2009 00:25:12 UTC