Re: Proposed Design Principles updated

On Apr 3, 2007, at 6:56 PM, Karl Dubost wrote:

>
> Le 3 avr. 2007 à 16:26, Maciej Stachowiak a écrit :
>> * Constraint: Data-metadata inconsistency
>> Agents MUST NOT ignore message metadata without the consent of the  
>> user.
>> (The cited example of warning about or refusing to render a jpeg  
>> with a type of image/gif would violate Don't Break The Web and is  
>> unlikely to be implemented.)
>
> Another *real* example where browsers content sniffing is bad in  
> usability. For example, I'm writing a blog post about HTML design.  
> I want to show the source code of an HTML file. I then use an  
> object element and configure the server to send the html file as  
> *text/plain*
>
> <object data="test.html">
>    <p>Source code of a HTML document</p>
> </object>
>
> What I want to see is the source code, not the HTML.

I'd love it if browsers could respect this constraint, but even  
though it may be annoying for content authors that we don't, it would  
be more annoying for end users if we did.


>> * Principle: Error recovery
>> Agents that recover from error by making a choice without the  
>> user's consent are not acting on the user's behalf.
>> (This is opposed to Handle Errors and our charter goals to handle  
>> tag soup.)
>
> Not exactly.
> Silent recovery can be an option for the users. It is perfectly  
> possible to leave the choice to the user to see or not the error  
> recovery.

Browsers are not going to do noisy error recovery by default.

> Counter case of your argument: Web developers. It is very useful  
> for a developer to have a non silent recovery mode in a browser. To  
> help fixing mistakes at development stage.
> For example, for having well-formed mark-up one of my way to do  
> that is to give .xhtml file extension to my files, so if it is not  
> well-formed the browser is choking right away.
> It is a lot more agile method by putting the checking at the  
> development stage.
> So the Error recovery IMHO is not opposite to your principles.

I think requiring noisy error recovery as the default (or even as  
always being an available mode) is not necessarily appropriate for  
all classes of products. Silent error recovery is probably most  
appropriate for a minimalist end-user focused browser. Noisy error  
reporting is most useful for a conformance checker. Some tools might  
have aspects of both, for instance a browser with developer  
extensions or an authoring tool may include conformance checking.

I like the way HTML5 handles this, by having distinct requirements  
for browsers and conformance checkers.

I don't know that this needs to be in the principles though.

Regards,
Maciej

Received on Wednesday, 4 April 2007 04:21:39 UTC