- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 10 Mar 2009 20:53:53 -0400
- To: public-html@w3.org
- CC: www-svg <www-svg@w3.org>
Hi, Ian- Thanks for your quick response. Ian Hickson wrote (on 3/10/09 7:48 PM): > On Tue, 10 Mar 2009, Doug Schepers wrote: >> * The SVG WG requests that the SVG case-fixup table be removed from the >> draft. We believe that HTML5 should defer to the appropriate (SVG) >> specification(s), and that this is not something that HTML5 should >> define. > > It seems dangerous to split the definition of how to parse text/html into > multiple specifications. However, updating the list should be easy and > quick, and in practice shouldn't affect implementations (who would just > update their lists regardless of what the specs say). What is the concern? It seems riskier to bottleneck element parsing to one time-frozen specification. I agree that implementations will update their internal list of supported non-HTML elements and attributes regardless of what HTML5 says, so it doesn't seem practical to include any such list in the HTML5 spec. Let's say that 2 months after HTML5 becomes a Rec, SVG comes out with the <pony> element, which has a the @hands attribute. Obviously, all browser vendors would implement this element and its attribute, post-haste. Now, either HTML5 is out of date, or it needs to have an errata issued and ultimately a second edition. That seems like unnecessary bookkeeping, when HTML5 could simply say that the elements and attributes in the SVG/MathML/EquineML specification define their own element and attribute names, and implementations that support that language should refer to that specification for the particulars. In the worst-case scenario, some implementers (or authors) might feel gated by the whitelist of elements in HTML5, and might not implement (or use) <pony hands="13.7"/>. That would be a real shame. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 11 March 2009 00:54:11 UTC