[whatwg] text/html flavor conformance checkers and <foo />

[Ian Hickson]

On Tue, 26 Apr 2005, James Graham wrote:
>
> Is there a good reason that <foo /> cannot be valid HTML5?

Valid HTML5 with what semantics? The same as <foo>? In which case, what's 
the advantage?

I mean, we could make

   <foo !!>

...valid as well, but I don't see any good reason to do it.

In fact, it seems that we don't want to make <p/> valid (and mean <p>) 
since that would just be REALLY confusing to authors using HTML5 and 
XHTML5 interchangeably.


> Any parser which doesn't support <foo /> also doesn't support much of 
> the web content produced in the last 2 years.

Certainly the HTML5 spec says that <foo /> must be treated as <foo> (and 
<p/> as <p>), but that doesn't mean we have to make it valid.


> In this case a conformance checker could emit a warning (maybe only a 
> strict warning) since it's not impossible that people will expect HTML5 
> to work in a parser that's incompatible with real-world HTML4.

According to the spec as it stands now, conformance checkers must report 
it as a parse error, and implementations that don't do error checking must 
simply ignore the "/".



On Tue, 26 Apr 2005, Anne van Kesteren wrote:
> 
> Same for leaving out non optional end tags. HTML5 should define what 
> should happen to the DOM tree. Leaving them out should be invalid.

Agreed (and done).


On Tue, 26 Apr 2005, Olav Junker Kjær wrote:
> 
> A conformance checker should check conformance to the spec, not 
> conformance to the behavior of actual UA's. But new specs should 
> (arguable) be aligned with the behavior of actual UA's if they are to be 
> backwards compatible.

Agreed, with the caveat that the spec can give requirements for things it 
says aren't valid, so the two aren't always mutually exclusive.


> There have been discussions about redefining the low-level parsing of 
> HTML to bring it more in alignment with how current UA's works. If we 
> want XHTML 1.0 to be legal HTML, it would make sense to allow the 
> trailing slash in empty elements. That way, you could legally server the 
> same content as both HTML and XHTML. (You can do that now, but it won't 
> validate as HTML which is a drag. If you want to be able to serve the 
> same content as both HTML and XHTML, you would want to make sure that it 
> validates as both HTML and XHTML.)

I'm not sure it would be a good idea to have the tokeniser know which 
elements it should allow trailing "/" characters for. That seems like a 
lot of work for no strong immediate benefit.

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