Element Whitelisting (was: SVG Feedback on HTML5 SVG Proposal)

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