- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 5 Mar 2009 15:02:35 +1100
- To: Erik Dahlström <ed@opera.com>
- Cc: public-svg-wg@w3.org
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