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

Re: ISSUE-54: doctype-legacy-compat

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 17 Jan 2009 18:03:36 +0100
Message-ID: <49720F68.5010900@gmx.de>
To: Robin Berjon <robin@berjon.com>
CC: Sam Ruby <rubys@us.ibm.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>

Robin Berjon wrote:
> 
> On Jan 16, 2009, at 14:48 , Sam Ruby wrote:
>> One such tool is mentioned in the bug report[8] cited in my prior email:
>>
>> [8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6336
>>
> 
> 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 

New empty elements are indeed a problem; we have a separate thread for 
this discussion (it might be over on the WHATWG mailing list, sigh).

The difference here is that right now, XSLT 1.0 can not generate a 
*single* valid HTML5 document, except by resorting to optional features 
(which do not work in FF, for instance), or workarounds (which wouldn't 
work for XSLT done in the browser).

Not being able to produce certain new HTML5 features is a problem as 
well, but only for those who need them.

> 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.

As far as I can tell, nobody is working on upgrading JAXP yet, for 
instance. Even then, to be useful in the real world it would need to be 
available for JDKs >= 1.5.

Also, nobody seems to work on upgrading XSLT 1.0 either.

> At the end of the day, the above means that I could live with any 
> option. But really, I think we'll be better off with having just the one 
> option, and have it as short and simple as possible. Ideally I would 
> live best with whichever option closes this small issue as fast as 
> possible, even if it takes a formal vote.
> ...

If there's no other way to make a decision: indeed.

BR, Julian
Received on Saturday, 17 January 2009 17:04:21 GMT

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