W3C home > Mailing lists > Public > public-html@w3.org > March 2010

(unknown charset) Re: Re-registration of text/html

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 11 Mar 2010 05:08:08 +0100
To: (unknown charset) Sam Ruby <rubys@intertwingly.net>
Cc: (unknown charset) Henri Sivonen <hsivonen@iki.fi>, Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, HTMLwg <public-html@w3.org>
Message-ID: <20100311050808773482.266aea42@xn--mlform-iua.no>
Sam Ruby, Wed, 10 Mar 2010 18:29:06 -0500:
> Leif Halvard Silli wrote:
>> 
>> But, can I ask you, as co-chair of this WG, what the problem with 
>> such an development is supposed to be? Not the '"interesting" Last 
>> Call' thing, but by allowing XHTML1.1 to be served as 'text/html'? I 
>> bet that most of XHTML1.1 on the web today *is* served as 
>> 'text/html', so it should be very close to reality to allow it.
> 
> Let's be precise.
> 
> A noticeable percentage of the web is served with an XHTML doctype, 
> and including a xmlns attribute on the html element that matches the 
> namespace defined by the XHTML specification.
> 
> I will further observe that a substantial portion of such content is:
> 
>   1) Served with the text/html MIME type
>   2) Not valid according to the XHTML specification
>   3) Not well formed according to the XML specification.
> 
> Given this situation, a number of distinct questions can be considered.
> 
> (1) Does it make any sense to call invalid, non-well-formed, content 
> served as text/html as XHTML 1.1?

Why does it make less sense than calling it XHTML 1.0? The reason one 
is using XHTML 1.1 is to be able to use the feature that XHTML 1.1. 
has. They are at least Ruby. And also RDFa. (But no @lang attribute ... 
) New elements via XHTML 1.1 served as text/html are as good or badly 
supported by user agents as new elements via HTML5 served as text/html. 
And, besides, this group has the change to specify Ruby in HTML5 to be 
identical with Ruby in XHTML 1.1.
 
> (2) Does it make any sense for two specifications using the same MIME 
> type to assigning different meaning to the same document?  Co-chair 
> or not, as a member of this working group, I personally would object 
> to such a situation persisting.

So where do they assign different meaning? We can observe that some 
extra elements are present in XHTML 1.1: Ruby, for instance. Are there 
others? Isn't HTML5 about "taking in" the Web? The Web, except the 
XHTML 1.1 Web, then?
 
> A final set of observations:
> 
> My weblog is served as valid XHTML5 to Opera, Firefox, and Webkit.  
> It is served as valid HTML5 to IE and Lynx.  The same content is 
> served in both cases.
> 
> Choosing a different MIME type has a very real consequence in each of 
> these five consumers.

Some documents of the XHTML2 WG was rescinded last year. I am not 100% 
sure why. But I thought it was because of critic about the document's 
accuracy. I did not notice many principal objections - it was about 
lack of review etc. (But I don't claim to have seen all or understood 
all - and I don't know about the behind the scenes.) 

The underlying XHTML syntax of XHTML+RDFa is XHTML 1.1 - with a special 
RDFa doctype. I had a quick look at the announcement about sites using 
RDFa at www.rdfa.info. I think all of them used XHTML 1.1. I also 
checked and found that they used the @lang attribute, despite that 
@lang isn't part of the XHTMl+RDFa/XHTML 1.1 spec ... 

So the success of RDFa happens on the world web web and it - supposedly 
- happens using a XHTML 1.1 syntax.

Surely, it is good that some order is brought into this? Or are there 
some parts of the text/html web that we should just ignore? I did not 
think that HTML5 was about _that_.

This group needs to take XHTML 1.1. a little more seriously.
-- 
leif halvard silli
Received on Thursday, 11 March 2010 04:08:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC