[whatwg] Allow trailing slash in always-empty HTML5 elements?
hsivonen at iki.fi
Mon Dec 4 14:02:09 PST 2006
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.
>> 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:
>> Instead, you have to *make an effort* to
>> make sure that your documents fall into
> 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
> 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.
hsivonen at iki.fi
More information about the whatwg