[whatwg] Allow trailing slash in always-empty HTML5 elements?
rubys at intertwingly.net
Thu Nov 30 08:04:09 PST 2006
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" 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
> 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
>> > 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:
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
More information about the whatwg