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

[Henri Sivonen]

On Dec 4, 2006, at 13:14, Mike Schinkel wrote:

> Henri Sivonen wrote:
>> At this point, it is important to realize that
>> pro-XHTML advocacy
>
> Who are the pro-XHTML advocates; those one who want divergence, or  
> those who
> want HTML5 to interoperate with XHTML as much as possible?

The usual kind of pro-XHTML advocacy is the kind that talks about the  
benefits of XHTML without specifying what they are but implicitly the  
reasoning is based on a different set of possible documents than what  
the reasoning is being applied to.

Note that some pro-XHTML-as-text/html opinions on this mailing list  
and on Sam Ruby's blog advocating only XHTML_compatible with the  
reasoning based on the properties of that set in particular are  
different from run-of-the-mill XHTML advocacy. However, those  
opinions should be considered strictly with the merits of  
XHTML_compatible--not broader XHTML--in mind.

>> 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.
>
> That is too abstract for me to follow.

Following it is essential.

It was pointed out to me that XHTML_all was a bad label. XHTML_xml  
would be a better label. It doesn't include XHTML_bogus which  
purports to be XHTML, appears to work when processed as HTML but  
wouldn't work when processed as XHTML. Most XHTML on the Web is in  
the XHTML_bogus set.

http://hsivonen.iki.fi/img/xhtml-venn.png

>> 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.
>
> I'm sorry but may I please ask for a reference? I unfortunately  
> don't know
> where to find that needle in the haystack.

I was referring to this very thread:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/008272.html

>> Instead, you have to *make an effort* to
>> make sure that your documents fall into
>> XHTML_compatible.
>
> That's fair and reasonable to require.

That may be, but the point is that it undermines the usual XHTML  
argument relating to the "Benefits of XHTML" on the markup  
*production* side. The usual "benefit" is that you can use "XML  
tools". However, having *generic* XML tools does not guarantee that  
they only produce documents that are in XHTML_compatible. Once you  
make sure that the tools *aren't* generic but instead it guaranteed  
that the output belongs in XHTML_compatible, the work you will have  
done is almost the same as tuning an XML toolset to produce HTML5.

>> If your documents fell into
>> XHTML_incompatible, things would
>> *break*, which would be *bad*.
>
> I'm not sure that I agree with the assertion that it would be bad  
> (or that
> it would be worse than the alternative currently proposed.)

You don't agree that it is bad if stuff breaks? As in "does not even  
appear to work".

>> This means that you lose any benefits
>> that hinge on you only having to
>> ensure targeting XHTML_all.
>
> That is a sweeping statement that minimally discounts the significant
> benefit of having less for people to learn. That benefit is so huge  
> it can't
> even be easily calculated.

How is learning to target XHTML_compatible less for people to learn?  
It isn't enough to understand how HTML processing works and it isn't  
enough to understand how XML processing works. Rather, one would need  
to understand both these and how to avoid the differences in the  
associated CSS and scripting behavior.

>> 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).
>
> From where I sit the only reason it would be untrue is because of a
> contigent trying to make it untrue and not willing to steer HTML5 in a
> direction more compatible with XHTML.
>
>> 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.
>
> I'm in 100% agreement with those, which means that there must be  
> further
> hidden values where he differ, possible unconscious values even.

Judging from your messages to this mailing list, it appears that we  
do not agree on the legacy point 100 percent. It seems to me that you  
believe that Hixie has more freedom in defining HTML5 then he  
actually has. The constraints placed by legacy content and browsers  
already out there are not open for the editor of the spec to overrule.

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