- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 25 Aug 2009 17:16:47 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Cameron McCormack <cam@mcc.id.au>, HTMLWG WG <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Henri Sivonen <hsivonen@iki.fi>
On Aug 19, 2009, at 11:48 PM, Maciej Stachowiak wrote: > I can see how this seems a little weird. I don't think it's > completely illogica on the face of itl. Here's my thinking on this. > HTML5 defines several things: > > A) A serialization independent vocabulary defined in terms of DOM > elements and attributes. > B) Scripting interfaces for the resulting DOM. > C) A serialization form that can handle this vocabulary, plus a few > select others (MathML, SVG), specifically the text/html serialization. > > I think it's plausible to include C without necessarily requiring > implementation of the behavior for all parsed vocabularies. An > analogous situation is XML - an XML parser has to put the > appropriate elements into the HTML or SVG namespace I meant to say: ... - an XML parser has to put the appropriate elements into the HTML or SVG namespace, but it is not required to implement all of the scripting interfaces and behavior of HTML and SVG, just to be a conforming XML parser. > > What I think could make sense is a requirement that IF a UA supports > SVG at all, it MUST also implement SVG behavior for SVG elements > parsed from text/html. I am not sure if such a requirement exists > today. > > I think this should be raised as a separate bugzilla bug or issue > tracker issue. SVG folks, do you think my proposed approach above is > sound? I think HTML5 requiring full implementation of some version > of SVG might be a bridge too far, but there should be at least a > clear conditional requirement to hook the parsing up to whatever > implementations do exist.
Received on Wednesday, 26 August 2009 00:17:30 UTC