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

On Wed, 29 Nov 2006, Leons Petrazickis wrote:
> 
> This rigmarole is going to repeat on every site that has converted to 
> XHTML sent as text/html. People are emotionally invested in the idea of 
> trailing slashes. Websites have complex codebases, and going through 
> them removing trailing slashes on singleton elements would be very hard.

Various things are worse noting here:

XHTML is a minority on the Web. Looking at just which elements specify the 
XHTML namespace on their <html> element, XHTML has at most 15% 
penetration, for example.

Nothing is going to stop people from continuing to use XHTML1, HTML4, 
HTML3.2, HTML2, or whatever their existing content uses. HTML5 is a new 
language, that happens to be backwards-compatible with all of those. There 
are probably near zero documents on the Web today that are 
HTML5-compliant, simply because the DOCTYPE is new. That's fine. Just 
getting new documents to be compliant would be fine. WordPress, for 
example, will eventually create new templates, and those could be based on 
HTML5 (though of course WordPress would have a harder job there due to its 
hardcoding of markup, but that's another story).

If people want to make HTML5 syntactically compatible with XHTML1, such 
that XHTML1 documents don't cause syntax errors in HTML5, we'll have to do 
a whole lot more than just allowing trailing /s. I don't really see why 
that would be a goal, though. Going further, if we want to make documents 
in general compliant with HTML5, then we've got our work cut out for us -- 
at least 78% of documents are syntactically incorrect today (not counting 
things like trailing /s in attributes, or missing DOCTYPEs -- if you 
include those, the number is more like 93%).

In general, people don't migrate to new versions of HTML. They only use 
new versions for new documents. Which is fine, since HTML5 UAs are going 
to be backwards-compatible (by design).


> They've already reaped all the benefits of XHTML -- cleaner, more
> readable, more maintainable code.

It's a myth than XHTML gives you those benefits, by the way, especially if 
you don't actually use an XML pipeline (which WordPress doesn't).


> The very idea of HTML5 is to not demand that the Web be scrapped and 
> rewritten. We need the people who have rewritten all their pages so that 
> they validate on the W3C validator -- they have the fire and the zeal 
> and the will to spread our format. We need to make the migration from 
> invalid XHTML to valid HTML5 very, very easy for them. We can't require 
> them to dig through PHP spaghetti. And that means that, no matter how 
> it's achieved, <br/> needs to be valid HTML5.

I don't really understand this argument. Those who use XHTML1 because it's 
"the latest thing", are as likely to use HTML5 because it's "the latest 
thing", regardless of how complex that is. After all, they made the 
transition to XHTML, why wouldn't they make the transition to HTML5?

I'm being devil's advocate here. As I noted earlier, I don't have an 
opinion on this yet; I'm interested in what people are saying.

What would be most helpful is if it could be clearly stated what the 
proposal is exactly (trailing /s are already handled by the parser, is 
the proposal just to make them not raise an error in some cases? What 
cases, exactly? How would this change the parser spec?), what the reason 
for this proposal is, and what the pros and cons are.

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

Received on Wednesday, 29 November 2006 11:49:11 UTC