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

Maciej Stachowiak wrote:
> 
> 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 
 > ...

I agree with that. But in this case, as it's a new attribute, IE does 
not *need* to support it in order to be potentially useful.

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

Of course that's desirable. But IE does not support XHTML, nor do we 
know when it will, so how does this help in the foreseeable future?

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

Not if the XML-based language has a concept of "validity" (such as by 
use of a DTD or another schema language).

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

The parsing mode could ship, but could be turned off in the default 
configuration.

BR, Julian

Received on Tuesday, 14 July 2009 08:30:20 UTC