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

Re: Proposal: @parsing="loose | strict"

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 14 Jul 2009 01:23:31 -0700
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Doug Schepers <schepers@w3.org>, "public-html@w3.org" <public-html@w3.org>
Message-id: <515CDAAE-CAB8-43D0-AA82-76B72441BD75@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Jul 14, 2009, at 1:06 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> ...
>> Why might it be worth it? It seems that the XML serialization of  
>> HTML5 already serves this use case. Adding a second draconian  
>> syntax doesn't seem like it adds anything. A new draconian syntax  
>> would also have several disadvantages over the XML serialization,  
>> namely it would not
> > ...
> It depends.
> One advantage is that you would actually be able to use it in the  
> real world; which you can't with XHTML (and the proper mime type)  
> because of IE.

I think it's unlikely IE would be willing to support a newly minted  
strict parsing mode but not be willing to support XHTML. It seems  
especially unlikely that they'd support the new (as of today not yet  
defined) mode earlier than XHTML. An XML MIME type has the advantage  
(if you want to be really truly draconian) that it will completely  
fail in non-supporting browsers, instead of doing loose parsing instead.

> The interesting question is: what kind of errors would it catch? For  
> instance, there's a class of errors that a non-validating XML parser  
> will not complain about, but which would be useful to diagnose (such  
> as when elements appear in the wrong place, of if attributes use a  
> wrong syntax).

That would be much more draconian than any current XML-based language.  
I had the impression that Doug only wanted parser-level errors to be  
treated strictly, not higher-level errors. Perhaps he can clarify.

> > ...
>> work with existing XML tools and it would not work as intended in  
>> any current browser. Furthermore, asking new browsers to do  
>> draconian parsing when all current browsers would parse the same  
>> content leniently seems like it would trigger a race to the bottom  
>> and neuter the feature.
>> ...
> That's indeed a problem, and would require some coordination for  
> deployment.

I think it's unlikely that browsers would be able to ship a new  
parsing mode in a tightly coordinated timeframe.

Received on Tuesday, 14 July 2009 08:24:14 UTC

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