Re: SVG in text/html, getting closer

On Tue, 03 Mar 2009 01:24:34 +0100, Cameron McCormack <cam@mcc.id.au> wrote:

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

Fine by me, do we want to make a decision about using the script processing model in HTML5 for SVG as well?

...

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

To have it put in the correct namespace would be acceptable to me as well.

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

Am I understanding you correctly here, is this about xlink:href attributes found outside of an svg fragment?

IMO the xmlns:xlink="" should be optional, and xlink:href should just work as if the prefix was correctly declared.

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

I agree.

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

Maybe that concern could be put in the wiki too? Or maybe we could agree on having that as a rationale for suggesting a number of new parse errors for SVG in HTML.

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

It would, if we agree on the same for a missing xmlns:xlink attribute.

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

I would think that it's not too bad to insert <html><body> for such cases, and then append the already parsed <svg> fragment to the body, and continue from there. It would mean that the <svg> is taken out of the document tree momentarily, and that it would change size when reinserted. However, given that it's a form of error correction that would be acceptable to me.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 4 March 2009 12:41:52 UTC