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

[Henri Sivonen]

On Dec 3, 2006, at 11:00, Mike Schinkel wrote:

> All I've heard is that people are saying and doing things that are
> incorrect. That means you are assuming that, above all else,  
> whatever people
> say and do must be correct. In this specific case, I challenge that
> assumption. I think the results of taking the medicine you are  
> proposing
> will be far worse than living with the disease.

First, there's XHTML--all of it the way it works as application/xhtml 
+xml. I'll call it XHTML_all. Then there's a subset of XHTML that  
when served as text/html to a browser that handles text/html  
according to requirements imposed by the real-world legacy still  
appears to "work" for the casual observer. I'll call this  
XHTML_compatible.

At this point, it is important to realize that pro-XHTML advocacy is  
based on reasoning derived from the properties of XHTML_all when it  
is processed as application/xhtml+xml. This reasoning is then applied  
to XHTML served as text/html. This is logical and intellectually  
honest if and only if XHTML_all equals XHTML_compatible.

I'll name the difference of XHTML_all and XHTML_compatible as  
XHTML_incompatible. Lachlan gave examples that indicate that  
XHTML_incompatible is not empty. Hence, XHTML_compatible is a proper  
subset of XHTML_all.

Now if you wish to serve your documents as text/html, it follows that  
you can't just happily do things that guarantee that your documents  
are members of XHTML_all. Instead, you have to *make an effort* to  
make sure that your documents fall into XHTML_compatible. The  
equality of XHTML_all and XHTML_compatible is not true--it is  
political obfuscation to hide an inconvenient truth. If your  
documents fell into XHTML_incompatible, things would *break*, which  
would be *bad*. This means that you lose any benefits that hinge on  
you only having to ensure targeting XHTML_all.

If you are making the text/html compatibility effort, you might as  
well adjust your effort to producing HTML5 instead of  
XHTML_compatible, unless you specifically want to participate in  
upholding a political appearance that doesn't match the technical  
reality and in doing so confuse newbies into believing that the  
political obfuscation is the truth (which leads them to waste time on  
finding out the truth the hard way).

> If I am correct in my assessment then the best thing for all  
> parties would
> to be make their *values* clear to each other.

My values involve acknowledging legacy realities, wanting ability to  
use XML tools with conforming HTML5 documents after a lossless  
conversion and eschewing political obfuscation of technical realities.

> That's an excellent point. My answer is that I was sold on the  
> benefits of
> XHTML, and I still believe in them so I don't want to give up on  
> the hope
> that I can eventually get there.

What was sold to you was XHTML_all. Not that you you have to know how  
to avoid XHTML_incompatible.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/