W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Support Existing Content

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 4 May 2007 14:57:40 -0700
Message-Id: <8EDFE6AB-E793-4FD3-AFAC-E2A6CDF3BBD7@apple.com>
Cc: Jeff Schiller <codedread@gmail.com>, Gareth Hay <gazhay@gmail.com>, James Graham <jg307@cam.ac.uk>, "matt@builtfromsource.com" <matt@builtfromsource.com>, "public-html@w3.org" <public-html@w3.org>
To: Chris Wilson <Chris.Wilson@microsoft.com>


On May 4, 2007, at 2:44 PM, Chris Wilson wrote:

> Jeff Schiller [mailto:codedread@gmail.com] wrote:
>> Though I wonder, if a UA mistakenly implements proposed error  
>> handling
>> in WHATWG's HTML5 and content starts depending on it, isn't that
>> roughly the same problem?  You're still going to have a UA improperly
>> implementing a spec, content depending on it, and other UAs motivated
>> to emulate this incorrect behavior.
>
> Or, more to my point, what happens when you don't specify some  
> error-handling rule in the spec because you don't think of it, and  
> due to different architectures multiple vendors do different things  
> and ship them without realizing it.

The spec describes what to do with every possible stream of input  
characters. It may be that the set of test cases will be  
insufficiently exhaustive and UAs will do something different in a  
particular case. But it seems to me that if we try to make a test  
suite for the error handling behavior, then (a) such cases are likely  
to be obscure and (b) we can fix it in the spec and in some of the  
respective UAs, unless all UA vendors decide they care more about  
backwards-compatibility with themselves than about interoperability.  
This says to me that we can converge closer and closer to identical  
handling of all token streams without an inherent need for bug modes.

Yes, it's possible UAs will have bugs and some may not be flushed out  
for a long time. But while HTML error fallback is tricky, it's not  
nearly as complicated as, say, CSS layout or JavaScript execution,  
and we still try to spec those.

In contrast, under a draconian policy, (a) cases where errors are not  
flagged may not be all that obscure, since the test suite of  
nonconforming content will be unlikely to be exhaustive; and (b) we  
can't fix the spec to better match UA behavior without changing what  
content is considered conforming.

Thus, defined graceful error handling is a track towards eventual  
convergence on parsing behavior that matches between UAs and the  
spec, more so than a draconian policy.

Regards,
Maciej
Received on Friday, 4 May 2007 21:57:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC