W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: ISSUE-54: doctype-legacy-compat

From: Sam Ruby <rubys@intertwingly.net>
Date: Sun, 25 Jan 2009 09:00:04 -0500
Message-ID: <497C7064.4040908@intertwingly.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: HTML WG <public-html@w3.org>

Henri Sivonen wrote:
> 
> On Jan 25, 2009, at 12:48, Sam Ruby wrote:
> 
>> Julian Reschke wrote:
>>> Henri Sivonen wrote:
>>>> ...
>>>> Thus, "about:sgml-compat" is *not* interpreted as a URI by any 
>>>> conforming HTML5 consumer. In my opinion, it is therefore 
>>>> unnecessary for it to be of the form of a URI in a registered scheme.
>>
>> What about XHTML5?
> 
> XHTML5 doesn't need a doctype and the best practice is not to use one.

I question this "best practice".  At the present time, given extant 
specifications and the status of widely deployed implementations XHTML 
is more functional than HTML in ways that are important to me (though I 
share the hopes of many in this working group that this gap can be 
addressed over time).

I also know of widely deployed user agents, including IE7 and Lynx which 
do not support XHTML.  Finally, while it is rare, I have seen instances 
where the Content-Type type I send is not the one seen by the user agent.

For these reasons alone, I would hope that best practices would be 
designed with an eye towards graceful degradation.

But more important to me is the issue that software like Venus generates 
pages without having *any* control over how that content is served. 
Knowing that many serve such output as text/html, I believe that it 
would be best for the example templates provided with Venus to include 
the DOCTYPE.

Can you site *any* issues with placing a DOCTYPE in XHTML5 that backs up 
your claim that not placing an DOCTYPE in such documents is a best practice?

For similar reasons, I'd like to include a meta charset element in my 
output.

> The concern of using a long doctype with XHTML5 only arises if one
>  * is generating markup with a legacy serializer
> AND
>  * is caching only one sequence of resulting bytes per URI
> AND
>  * is serving the same cached bytes as application/xhtml+xml to non-IE 
> clients and as text/html to IE
> AND
>  * wants to support (non-browser) XML clients that are configured to 
> process the DTD and fail if the entity resolver fails to resolve the 
> system id of the external subset.
> 
> To me, this looks like fringe case combined with AND--i.e. something 
> very improbable to be concerned with. (I do realize that as improbable 
> as it is, Planet Intertwingly happens to hit this exact combination. But 
> it's already addressed by deploying a workaround at the first point.)

To me an existence proof trumps what might otherwise seem (logically) to 
be improbable.  But in any case, given the size of the internet, the 
spec can (and does) need to consider "improbable" cases.

And, as you have already noted, I am motivated to seek and deploy 
workarounds.

>> All of this input may be useful to the editor, and I expect that he 
>> will take it all into account.  Unless I missed it, I don't see any 
>> "can't live with" problems identified by either Henri or Julian with 
>> any of the URI schemes mentioned above.  So unless I hear otherwise, I 
>> expect that both of you will be willing to live with whatever the 
>> editor may decide.
> 
> I don't have a "can't live with" level problem with 
> "urn:w3c:sgml-compat". It would cause additional registration 
> bureaucracy compared to something the WG would register anyway for other 
> reasons, though. I think "urn:w3c:sgml-compat-dtd" is undesirable, since 
> there's no DTD.

Thanks!

- Sam Ruby
Received on Sunday, 25 January 2009 14:00:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:28 GMT