Re: SVG in text/html, getting closer

Cameron McCormack:
> >   * 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.

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

In SVG Core or whatever?  Yes I think it’s a good idea to have them both
work in the same way.  Handling scripts in HTML is more complex, due to
async/defer attributes and document.write(); we wouldn’t have to deal
with that, I guess.

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

I was thinking more about inside an svg fragment but without an
xmlns:xlink="" attribute on an ancestor-or-self.

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

Optional and thus not a parse error if it doesn’t exist?

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

Yes, it could be rationale for having any new parse errors for SVG in
text/html, rather than relying on validation to XHTML+SVG too.  And we
want these parse errors to exist when SVG is used in HTML that can’t be
parsed as XHTML, too.

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

That, but also consistent with a general desire to have parse errors for
things that wouldn’t work when copying the SVG fragment out into an
image/svg+xml document.

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

Yeah, it’s a possible approach.  I think that’s Henri’s suggestion in
his mails on www-archive earlier today/yesterday.

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

Received on Thursday, 5 March 2009 04:03:30 UTC