Re: XHTML Syntax Served as text/html (Was: Decentralized poetry markup (language))

Leif Halvard Silli wrote:
> Smylers, Wed, 20 Jan 2010 18:04:09 +0000:
>> Leif Halvard Silli writes:
>>> Smylers, Wed, 20 Jan 2010 16:14:59 +0000:
>>>> Leif Halvard Silli writes:
>>>>> Tab Atkins Jr., Tue, 19 Jan 2010 12:36:42 -0600:
>>>>>> On Tue, Jan 19, 2010 at 12:23 PM, Leif Halvard Silli:
> 
>>> If we are permitted to serve XHTML as text/HTML, then it makes sense
>>> be able to validate such documents as well.
>> Sure.  But we aren't, in general, permitted to serve such documents.
>>
>> Or at least such documents will be interpreted by user-agents as
>> text/html.  So it only makes sense to check them against the rules for
>> valid text/html.
> 
> If it only were so well. If SGML-inspired HTML could be extended the 
> same way XML-rooted HTML can, then it would be so well.
> 
>>>> When content is being served in a way which will cause all
>>>> conforming user-agents to treat it as one thing, how is it useful to
>>>> check its validation as something else?
>>> Quite. Because, as you know, XHTML and HTML are quite close to each
>>> others.
>> Close, but not identical.  And where there are differences, serving as
>> text/html will cause the document to be interpreted using the HTML
>> rules.
> 
> Of course it is interpreted as text/HTML.
> 
>>  That it happens to conform to a different (though similar)
>> language in which a portion has a valid meaning doesn't affect that: it
>> still either conforms to HTML or it doesn't.
> 
> XHTML is included under the umbrella "HTML": "HTML is the family name 
> for the group of languages that form the lingua franca of the World 
> Wide Web." http://www.w3.org/MarkUp/Activity
>  
>>>> Regardless, a change in W3C Validator behaviour cannot affect what
>>>> is permitted in HTML5.
>>> My point was merely that if HTML5 refuses to become more relaxed about
>>> extensions,
>> HTML5 is very relaxed about extensions: if a community agrees that a
>> particular extension is relevant to them, then it's permitted.  (Though
>> admittedly that's more a description of how things are the real world
>> than any policy by HTML5; it couldn't really be otherwise.)
>>
>> So if a knitting community come up with a mark-up language for embedding
>> knitting patterns in webpages, and that community have HTML user-agents
>> which interpret that language (maybe through a browser plug-in), then
>> it's valid for other members of that community to serve pages which
>> makes use of it.
> 
> The evangelist.
> 
> I can only repeat what I said. What I hear from (I don't bother to 
> mention names) is not relaxed, it is frantic. And frankly, a validator 
> that refuses to validate XHTML served as text/HTML is a little bit 
> frantic as well. Although, by all means: I do see that it has a 
> (theoretical) point. (A more fruitful approach would be to validate 
> such documents as the polyglot document they are clearly intended to 
> be.)
>  
>>> then there exist another, parallel technology - namely XHTML served as
>>> text/HTML.
>> But there isn't.
> 
> I forgot what Sam uses to say - something about nuances of angle wings.

Doesn't ring a bell.  :-)

For my part: there is no proper super/subset role between XHTML5 and 
HTML5.  By that I mean that not only are there valid HTML5 documentst 
that aren't valid polyglot documents, there are valid XHTML5 documents 
that aren't valid polyglot documents.  One concrete example:

   <script src="http://www.google.com/jsapi"/>

If there is interest in working on a validator to support a polyglot 
profile, Henri has proven that he is willing to accept patches.  I'm 
interested in doing this work, but haven't found the cycles.  If the 
work were done, I'm confident that the W3C would host the result.

Meanwhile: just curious.  Is this thread going to lead to any tangible 
proposals for spec changes?  If not, can I ask that it be either wrapped 
up shortly or moved to another location?

- Sam Ruby

Received on Wednesday, 20 January 2010 19:51:25 UTC