Re: Core syntax error handling

Ian Hickson wrote to <www-style@w3.org> on 28 February 2003 in "Re: Core
syntax error handling"
(<mid:Pine.LNX.4.50.0302280534410.23128-100000@dhalsim.dreamhost.com>):

>> Calling random or malformed junk CSS is a problem.
> 
> Why?

Um, because junk is not CSS. The term "CSS" should mean something useful.
This is more a social than a technical issue; that does not lessen its
importance. B1FF should not dictate the progress of CSS.

>> Perpetuating this junk by requiring user agents to accept it is a
>> problem.
> 
> Why?

The reason that first comes to mind is that human beings will, for the
forseeable future, need to edit CSS in basic text editors. Requiring
computer programs to follow a syntax and a set of error recovery rules is
feasible. Requiring human beings to follow the same rules when confronted
with a bewildering mess of errors is pure folly.

>> I have repeatedly lobbied for a third alternative which I recall David
>> Baron proposing originally. This alternative would tokenize the maximum
>> initial tokenizable sequence of characters and would parse the maximum
>> initial sequence of tokens matching the current 'stylesheet' production
>> (or equivalent).
> 
> I don't see how this is any better than either the "parse or die" approach
> or the well defined "here's what to do with any set of tokens" approach.

I'll steal the rationale from SVG 1.0 [SVG-ERROR]:

    The document shall be rendered up to, but not
    including, the first element which has an error.
[...]
    This approach will provide a visual clue to the
    user or developer about where the error might be
    in the document.

A rewording is needed to work with CSS, but the concept is the same:

The style sheet shall be applied up to, but not including, the first
statement which has an error. This approach will provide a visual (or aural
or tactile) clue to the user or developer about where the error might be in
the style sheet.

The approach outlined here is more informative to the erroneous style sheet
designer than is an all-or-nothing approach. In addition, the approach
outlined here is very likely to prompt a fix by the style sheet designer,
certainly more likely than a junk-parsing approach.

[SVG-ERROR]
Jon Ferraiolo, editor.
"Error processing", Appendix F subsection 2, in "Scalable Vector Graphics
(SVG) 1.0 Specification".
4 September 2001.
<http://www.w3.org/TR/2001/REC-SVG-20010904/implnote.html#ErrorProcessing>.

Received on Tuesday, 4 March 2003 06:13:29 UTC