Re: SVGT 1.2: Appendix C3: SVG Error Processing

On Jan 2, 2006, at 1:34 AM, Jim Ley wrote:

> "Maciej Stachowiak" <mjs@apple.com> wrote in message
> news:B967F07A-7D2F-462A-9E42-548657F1DCB2@apple.com...
>> HTML specifications have historically declined to specify error   
>> recovery
>> behavior. However, the end result is that current UAs must  in  
>> practice
>> implement a large, complex, completely unspecified set of  error  
>> recovery
>> behavior based on the behavior of past dominant UAs.
>
> No, they don't _have_ to, they choose to.

They choose to because they wish to have more than the trivial number  
of users that is willing to put up with a great number of web sites  
not working. Over time there is pressure for UAs to converge in  
behavior for unspecified features that are easy to run into.

> And given that any error recovery will be large and complex all  
> you're gaining is the specified part - since a  dominant UA is  
> likely to have bugs in the error recovery you are still stuck   
> choosing either to reverse engineer the dominant UA or follow the  
> spec even when all the content relies on the dominant UA behaviour.

I disagree:

- No specified behavior could possibly be as ridiculous as the de  
facto standard behavior for HTML. For a few examples try doing a  
google search for the term "residual style". Ian and I have a lot of  
experience with these issues for HTML. This was part of Ian's point  
in his message. Write something sane while you have the chance, or  
the evolved de facto standard will be insane.

- Existence of a standard provides a club with which to beat  
laggardly UAs and content authors - consider how much work IE 7 is  
doing to improve their CSS support to comply with the standard, and  
how there is a "strict mode" where all UAs try to provide correct CSS  
behavior.

> Specifying error recovery does nothing to solve the decision of new  
> user agents deciding to ape the bugs and features of dominant UAs.

If error recovery is not specified, then some particular weird way of  
doing it is not a bug, it is a design choice. It's a lot harder to  
convince someone to change their design choices than to convince them  
to rectify a bug against a particular spec.

I don't think you have presented a convincing counter-argument to the  
experience of HTML, and the contrasting experiences of CSS and XML.  
Having done a fair amount of work on a mainstream web browser, I know  
that HTML is much harder to parse than CSS or XML as a result.

Regards,
Maciej

Received on Monday, 2 January 2006 10:30:12 UTC