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

Re: ISSUE-54: doctype-legacy-compat

From: Robin Berjon <robin@berjon.com>
Date: Fri, 16 Jan 2009 16:37:42 +0100
Cc: public-html <public-html@w3.org>
Message-Id: <0FB350B4-9A2C-419F-866B-4655BAEAF50A@berjon.com>
To: "Thomas Broyer" <t.broyer@ltgt.net>

On Jan 16, 2009, at 16:04 , Thomas Broyer wrote:
> On Fri, Jan 16, 2009 at 3:11 PM, Robin Berjon wrote:
>> As one who uses such tools, I would tend to think that I would  
>> expect them
>> to require updates to their HTML serialisations in order to support  
>> new
>> empty elements anyway, and therefore that tossing in a change for the
>> DOCTYPE wouldn't be much work. For the user who really wants to  
>> produce
>> HTML5 the tooling update is minimal; and if there's anyone out  
>> there who is
>> at the same time so cutting edge that they want to produce HTML5  
>> but so
>> conservative that they won't upgrade a serialisation library I  
>> would tend to
>> think that they have enough issues of their own that we don't need to
>> meddle.
> And for them, an easy workaround is to prepend a hard-coded <!DOCTYPE
> html> at the end of their serialization chain (in Java, that would
> mean plugging the attached Writer –which could probably be improved
> performance-wise– somewhere between your producer/serializer and
> output stream).
> So I totally agree with you that it's not really a problem...
> ...except for tools based on specs that do not allow outputting the
> HTML5 doctype (such as XSLT): updating the tool is not enough, the
> spec has to change too; and if it already has been superseded (such as
> XSLT 1.0) there little to no chance that it'll be updated (and that
> then tools align with the updated spec).
> So I think a "compat" DOCTYPE has to be allowed.

The entirety of your argument seems to be predicated on how hard it  
would be to produce a spec to which such processors could comply. I  
agree that updating XSLT 2.0 wouldn't work for all the people who are  
happily sticking to 1.0, and reopening 1.0 for edits would see a  
landslide of new features. But there's another way: create a "HTML  
version 5.0 Output Method for XSLT" specification. In fact, if you  
give section 16.2 of the XSLT spec a good read you'll see that it's  
probably needed, to wit: "The version attribute [ed. of the  
<xsl:output> element] indicates the version of the HTML. The default  
value is 4.0, which specifies that the result should be output as HTML  
conforming to the HTML 4.0 Recommendation". Existing implementations  
could simply be updated to support XSLT 1.0 and the HTML5 output method.

The requirements found therein are pretty loose, and globally enough  
to get things right. If we were to agree that specifying v5 output  
needn't be more detailed or stringent but just have a few changes for  
empty elements and the DOCTYPE, then give me two beers and a promise  
that this issue is closed and I'll write you that spec.

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Friday, 16 January 2009 15:38:19 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:41 UTC