Re: Element Whitelisting

Hi, Ian-

Ian Hickson wrote (on 3/10/09 9:16 PM):
> On Tue, 10 Mar 2009, Doug Schepers wrote:
>>  >
>>  >  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.

You haven't really addressed this point.


>>  Let's say that 2 months after HTML5 becomes a Rec, SVG comes out with the
>>  <pony>  element, which has a the @hands attribute.
>
> I assume you mean more something like fePony with a jazzHands attribute,
> since all-lowercase names would work fine.

Yes, for filters in particular, it would be inconsistent (therefore 
confusing) for us to change the naming scheme.  In this case, we want 
the SVG specs to be the normative source for SVG elements and attributes.


>>  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.
>
> By the time HTML5 becomes a REC, it will have been out of date for a long
> time. I would fully expect work on HTML6 to be in full swing by then, and
> HTML6 would be able to track the new features easily.
>
> Adding a new attribute or element name requires a careful study of
> existing content, which is far more work than any sort of editing of a
> spec. I think worrying about which spec the list is in is optimising the
> easy part while ignoring the real bottlenecks.
>
> Note that nothing stops a future version of SVG adding names and
> attributes to the list anyway, acting as a kind of errata to HTML itself,
> should it be found that the HTML working group at the time is no longer
> responsive to feedback of this nature.

You don't cite technical reasons to keep the whitelists of SVG elements 
or attributes in.  You seem to suggest putting off the burden to some 
potential future spec, for no apparent gain, while the SVG WG proposes a 
much cleaner model of extensibility: referring to the normative source.

This issue seems to come down to a matter of preference.  The SVG WG 
sees disadvantages in such whitelisting, and doesn't see value in it. 
Modulo some technical reason, we still oppose the inclusion of 
whitelists, and ask instead that wording similar to what we've proposed 
be used to solve the issue. [1][2]

[1] 
http://dev.w3.org/SVG/proposals/svg-html/html5-mod.html#svg-attribute-name
[2] http://dev.w3.org/SVG/proposals/svg-html/html5-mod.html#svg-element-name

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 24 March 2009 02:34:39 UTC