- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 4 May 2007 14:57:40 -0700
- To: Chris Wilson <Chris.Wilson@microsoft.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>
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