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

Re: Re-registration of text/html

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 11 Mar 2010 19:37:37 -0800
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Henri Sivonen <hsivonen@iki.fi>, Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, HTMLwg <public-html@w3.org>
Message-id: <9FC7CF8E-7AF5-43F2-85AD-0953593720A6@apple.com>
To: Sam Ruby <rubys@intertwingly.net>

On Mar 11, 2010, at 7:09 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Mar 11, 2010, at 6:13 PM, Sam Ruby wrote:
>>> I can't help but wonder if one small change to HTML5 that would  
>>> reduce this confusion, and yet would have zero inpact to browser  
>>> vendors.  This change would be to change the definition of the  
>>> xmlns attribute on the html element from a talisman to a trigger  
>>> of a few additional, yet simple, validation checks.  To start  
>>> with, it would trigger validation errors when elements are  
>>> implicitly closed.  Other checks could also be considered.
>>>
>>> A few notes: the intent is not to guarantee well-formedness, nor  
>>> to change browser behavior, but merely to provide a means for  
>>> someone who wishes to opt in to a more strict syntax to indicate  
>>> their desire to do so.  This also clearly would have no impact on  
>>> those who advocate the use of a more minimal syntax.
>> Seems like validators can do that without any changes to HTML5.
>
> I'm not certain I understand your point.  The working group could  
> certainly remove all requirements for conformance checkers and leave  
> everything unspecified.
>
> I am suggesting that it would be useful to specify some additional  
> conformance requirements.

Putting it in the spec would require a bunch of negotiation over the  
exact set of rules and would likely lead to controversy no matter what  
set of rules is picked. Whereas a validator could just do it. On the  
other hand, if a validator actually did it first, then we'd have a  
concrete set of additional checks as a starting point. And would have  
some data on whether the extra checking is beneficial and whether  
there is a significant audience for it. Or if we can't persuade anyone  
that it's worth their time to add it to a validator, then maybe we  
conclude that it wasn't such an awesome feature after all.

(My concern here is that just checking for implied close tags would  
not be nearly enough for those who may want such a feature, and that  
we could end up consuming a lot of the Working Group's time if we try  
to work out a compelling set of extra rules in the context of the  
spec, let alone try to forge consensus that the spec should mandate  
this extra checking at all.)

Regards.
Maciej
Received on Friday, 12 March 2010 03:38:12 UTC

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