[whatwg] Allow trailing slash in always-empty HTML5 elements?

[Sam Ruby]

Hallvord R M Steen wrote:
> On 30/11/06, Anne van Kesteren <annevk at opera.com> wrote:
>> > Closing slash on void elements
>> > sounds like a good example of "this is invalid because we're sticking
>> > to our fixed ideas"[1] rather than "this is invalid for technical
>> > reasons like causing ambiguities in DOM parsing". So I support Sam's
>> > approach.
> 
>> Well, nothing per the parsing section causes "ambiguities in DOM parsing"
>> (assuming I understand what that means). So I'm not sure what you're
>> suggesting.
> 
> It's the core of the debate, namely if <img /> isn't technically a
> problem why are validators required to flag it as invalid? The counter
> examples are comparisons with <div /> which isn't parsed into the DOM
> most would expect when sent as HTML, and corner cases like
> 
> <base href=http://example.org/bar/>
> 
> - now, how do you resolve relative URLs in this document? This is the
> sort of ambiguity the DOM parsing has to take into account - caused by
> the usage of forward closing slashes within tags. If the spec can
> specify simple non-ambiguous ways of parsing that like the author
> expects I think we can relax validation requirements like Sam wants.

 From the head of this thread:

   As an additional constraint, I am explicitly suggesting that the
   "Attribute value (unquoted) state" not be changed - slashes in this
   state would continue to be appended to the current attribute's value

What this means is that the above example MUST be interpreted 
identically as:

   <base href="http://example.org/bar/">

>> > That said, HTML5 must see
>> >
>> > <input type="checkbox" checked/>
>> >
>> > as a checkbox input with a "checked" attribute.
>>
>> It does.
> 
> Included in the discussion to make sure HTML5 continues to do so even
> if the change I want (more liberal validation) is taken in.

Yes, verb tenses are problematic in the face of a fluid draft document 
and an active proposal.

The current draft indicates that the above would be a parse error, and 
would result in the exact same parse error and DOM (modulo attribute 
order) as the following:

<input checked/type="checkbox">

Clearly a fleshed out version of this proposal would preserve the 
existing specification behavior (including the parse error) for the 
checked/type example, but for the checked/> example it actually could go 
either way.  I'd personally would allow it.

- Sam Ruby