Re: Understanding the "applicable specifications" clause (was: Re: Decentralised extensibility idea (ISSUE-41))

Tab Atkins Jr., Wed, 20 Jan 2010 15:15:07 -0600:
> On Wed, Jan 20, 2010 at 1:59 PM, Leif Halvard Silli
>> Tab Atkins Jr., Wed, 20 Jan 2010 12:26:30 -0600:
>>> On Wed, Jan 20, 2010 at 11:10 AM, Leif Halvard Silli wrote:

>> When did "XHTML served as text/html" disappear, then? The note about
>> "XHTML Media Types" doesn't agree [1]. It is of course clear that
>> text/HTML parsers treat anything one feeds them as text/HTML. (One
>> exception: validator.nu.) But that is a different point.
> 
> I think that's precisely the point.  There never was any such thing as
> "XHTML served as text/html".  It was always HTML through and through,
> though some people were confused about this and believed they were
> still in some essential way serving XHTML.  It was a (un?)lucky
> coincidence that many of the differences between the HTML and XHTML
> languages are ignored when the file is interpreted as HTML.  This led
> to some unfortunate confusion when people continued to assume that
> they were actually writing XHTML and used some features that were
> *not* ignored by HTML, and in fact result in a noticeably different
> DOM than what one would expect if it were interpreted as XHTML.

To the extent that someone is aware that he/she is writing a document 
with XHTML syntax, then there is a question w.r.t. whether he/she 
thinks that merely using XHTML syntax will create benefits for a 
text/HTML consumer. I think the misconceptions in this regard probably 
are much lower than claimed. Another issue, however, is that the 
"tactic" to serve XHTML as text/HTML until all UAs were able to 
interpret xhtml+xml probably should be stamped as "failed".

Now, you mention that using XHTML syntax can have some /negative/ 
effects. I suppose what you have in mind is void elements in general. 
Of course, if authors are not aware of the issues w.r.t. void elements, 
then they get trouble.

But you fail to consider if there can be /positive/ effects from using 
XHTML syntax. There are two positive effects, that I see:

1) XHTML is extensible. And as the work in this working group has 
shown: It is possible to extend text/HTML - we don't need to use 
XHTML-XML. Thus,  it is possible to use the XHTML specifications for 
defining XHTML elements which can also work as text/HTML elements.

2) XHTML syntax allows all elements to be either <void /> or 
<nonvoid></nonvoid>.  From the start, XHTML1 served as text/HTML came 
with the infamous Appendix C, which were advising us about how we could 
use valid *XHTML* syntax for void elements that text/HTML consumers 
*already* are aware of. However, when we invent *new* elements, then 
this advice must be turned: In text/HTML, all new elements *must* be 
used with non-void syntax - until "void" eventually is "turned on" for 
particular elements.

Thus, if text/HTML fails to be flexible enough w.r.t. to extensibility, 
then using XHTML syntax is an option instead. To an extent. 
-- 
leif halvard silli

Received on Thursday, 21 January 2010 14:05:21 UTC