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

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

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 14 Jul 2009 04:13:55 -0400
To: "Boris Zbarsky" <bzbarsky@mit.edu>, "Doug Schepers" <schepers@w3.org>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.uw1s5hle1ejg13@sandra-svwliu01>
On Tue, 14 Jul 2009 03:32:57 -0400, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Doug Schepers wrote:
>> To meet this need, I propose a new attribute, 'parsing', which, when  
>> placed on the document root, defines the type of parsing which a UA  
>> must use when parsing the document.  The values would be "loose" and  
>> "strict", with loose parsing as the default (an omitted @parsing  
>> attribute would result in loose parsing).
> ...
>> and very little implementation cost, since browsers will already have  
>> both modes
>
> Is the proposal actually to parse part of the document (with which  
> parser?), then switch to an XML parser in some cases?  Or something else?
>
> If that's the proposal, how is that better than the existing ability to  
> select the XML parser using the MIME type?  It seems strictly more  
> difficult from an implementation standpoint (very very complex to  
> specify and implement, in fact), and the XHTML MIME type is  
> well-enough-supported by servers that I have a hard time believing that  
> someone who wants to send data with that type can't.
>
> If that's not the proposal, then we are in fact proposing a third  
> parsing mode, sounds like (with corresponding spec and implementation  
> complexity).  This might be worth it, but I just want us to be clear on  
> the costs.

It might be cool to make the *html* parser emit a yellow screen of death  
during development. That could be triggered as a browser option, or with  
@parsing.

Or, it might be cool if the browser's error console popped up and spit out  
all the errors as an option.

If it's a browser option though, you might want to be able to set the  
option per-page or per-site and be able to easily toggle it. That way, if  
you're also loading other sites, the yellow screen of death wouldn't get  
in the way on those sites.

If it's with @parsing, I think it'd be easier for the user testing the  
page than messing with options in the browser. But, an option in the  
browser would be great when you want to test a remote site you can't  
change atm. (There should be a browser option to toggle @parsing support  
too.)

Some browsers do have a "validate page" option that could go to  
validator.nu etc., but that's that the in-your-face error reporting I  
think is wanted here.

I like the idea of @parsing. FWIW, *I* would add it to pages and set it to  
strict all the time and leave it that way in situations where it doesn't  
cause a problem.

-- 
Michael
Received on Tuesday, 14 July 2009 08:14:38 UTC

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