Re: Element Whitelisting

On Tue, 24 Mar 2009, Doug Schepers wrote:
> Ian Hickson wrote (on 3/23/09 11:16 PM):
> > 
> > > 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
> > 
> > Woah, how are we supposed to reason about what the parser requires if 
> > we don't actually list the tags explicitly? It seems dangerous to not 
> > make the list explicit. I'd be far more concerned about us 
> > accidentally introducing tags that we didn't intend to introduce if we 
> > didn't have to make sure we kept a list up to date.
> > 
> > This also moves the burden of listing the tag names from us to the 
> > implementors, which would inevitably be a source of bugs.
> 
> Who said it shouldn't be an explicit list?

Isn't that the proposal? That was my interpretation of the text cited 
above. If I misunderstood, could you elaborate in more detail on what the 
proposal is?


> You think the explicit list should be in the HTML 5 spec, which risks 
> getting out of sync with the SVG spec, and the SVG WG thinks that the 
> explicit list should be in the SVG specs, where the elements and 
> attributes are actually defined.
> 
> Where would the confusion and bugs come in?

If there is an actual explicit list, instead of an implicit list as in the 
proposed text above, then I am not arguing that there would be confusion 
and bugs. I am arguing that people writing text/html parsers will have an 
easier time writing conforming parsers if they can just look at one 
document and don't have to look things up in multiple other documents, 
with version shears (e.g. implementing one version of HTML which refers to 
one version of SVG while that version has been updated) and other such 
problems.

The benefits of putting the list in the same document as that which 
defines the vocabulary is purely an editorial and process benefit, it 
isn't a benefit to implementors. Benefits to implementors outweigh 
benefits to us. I personally would rather not have to maintain this list 
myself, just like I'm sure the SVGWG would rather be in control of that 
part of the HTML parsing rules instead of having to potentially have 
cross-working group discussions with each new element; but our own desires 
are the least important concern here, according to our "priority of 
constituencies" design principle.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 24 March 2009 04:59:02 UTC