Re: Element Whitelisting

On Mon, 23 Mar 2009, Doug Schepers wrote:
> 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.

Ok:

> It seems riskier to bottleneck element parsing to one time-frozen 
> specification.

I agree that bottlenecking element parsing to one time-frozen 
specification would be risky. However, nobody is proposing to do this.


> 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.

I agree that implementations will update their internal list of supported 
non-HTML elements and attributes regardless of what HTML5 says, so it 
seems simpler to just have the normative list in the HTML5 spec.

(I don't think the conclusion clause in either statement follows logically 
from the premise given in the first clause, so I don't think saying "so" 
is appropriate in either sentence.)


> You don't cite technical reasons to keep the whitelists of SVG elements 
> or attributes in.

There can't be a technical reason, this is a completely editorial and 
process issue.

The reason is simply that people writing text/html parsers will have a 
much 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 and other such problems.

In practice this is basically a non-issue for us (the standards and 
specification authors), and the HTML design principles say we should put 
the needs of implementors ahead of the needs of spec authors.


> 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.

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

Received on Tuesday, 24 March 2009 03:16:45 UTC