W3C home > Mailing lists > Public > www-style@w3.org > March 2011

[CSS21] malformed statement handling (esp. @import) (Re: WD 4.1.6, 4.2: parsing of blocks

From: Peter Moulder <peter.moulder@monash.edu>
Date: Mon, 07 Mar 2011 16:34:04 +1100
To: www-style@w3.org
Message-id: <20110307053404.GB17954@bowman.infotech.monash.edu.au>
On Fri, Jan 07, 2011 at 07:40:42PM +0000, I wrote:

> The text for "malformed statements" says that one should "read until
> the end of the statement", but doesn't say what to do with [content]
> encountered either prior to or after the illegal token.

The right answer in general depends on the statement type and where the
error occurs.

Interestingly, it seems that after an opening brace, the question of
what to do with errors "while parsing a statement" never occurs for
purely CSS 2.1 UAs: it seems that such errors are always considered to
be local to a declaration or sub-at-rule (or part of a future
statement, if after the matching closing brace).

(Nevertheless, 4.2 does need changing such that "while parsing a
statement" excludes such errors.  Copying & adapting the last paragraph
of the following at-rule case might be one way of doing this.)

4.1.7 addresses the case of an error occurring within the selector
(i.e. prior to any open brace), namely that the whole statement is

For @charset, 4.4 already specifies that the statement must be ignored
if it contains any spurious token.

For @media, 7.3 gives what I believe to be a complete specification of
what to do for errors occurring before any opening brace.  (Sometimes
it ignores the whole statement, sometimes just the erroneous bit.)

For @page, the relevant section (13.2 and its subsections) isn't clear
as to whether there are any valid page selectors other than :left,
:right or :first, and if so whether they should be considered to match
or not; though this is only a technical error, and in practice I expect
all authors & implementors would assume unknown page selectors to
result in ignoring the whole at-rule.  Still, this technical error is
cheap to fix, and I suggest adding a paragraph saying that an @page
rule must be ignored if it has an unrecognized page selector, or does
not in fact conform to the grammar given in the "An @page rule consists
of ..." statement near the top of 13.2.

The only remaining case in CSS 2.1 that I'm aware of where the problem
of what to do with the rest of the statement arises is for parsing
errors occurring in @import statements.  Unfortunately, the section on
@import statements (6.3) doesn't say how to handle errors or what
the provisions for forward-compatible parsing should be (at least for
CSS 2.1 user agents that don't support css3-mediaqueries).

I suggest that 6.3 give error-handling rules for @import, and that
4.2 try to defer to the documentation for rulesets and individual
at-rules for what effect if any the non-erroneous parts of the
statement have.  Though I suggest that the wording should be such that
there's some sort of provision (e.g. ignore the whole statement by
default) for any cases where the documentation for the more specific 
statement type doesn't say what error handling to apply.  E.g. perhaps
worded as "ignore [hyperlinked to "#ignore"] ... unless ...".

(I expect that in most cases, the "unless" part would already be
covered by the proposal that ignored invalid components aren't
considered to be an error while parsing a statement; but it
nevertheless seems safer to include the "unless" part just in case
something isn't covered by that.)

Does the test suite already contain tests for @import error-handling
behaviour on which an error-handling specification for 6.3 could be
based, or could something from the text or test suite of
css3-mediaqueries be used?  (Or have I missed something already in
CSS2.1?  The only text I'm aware of in CSS2.1 that could be read as
specifying what constitutes an "error while parsing an (@import)
statement" is the grammar in grammar.html, but that's non-normative,
and in any case may well be stricter than we want; though OTOH I note
that @media does use similarly strict error handling behaviour.)

Incidentally, 6.3 has some simple editorial issues in its definition
of when the media list matches: (i) it should use an "if and only if"
construction, or in some other way specify when the media list doesn't
match; (ii) it should say "one or more" instead of "one"; (iii) it says
"when one of the items ... *is* the target medium" when it means
*matches* the target medium (e.g. an item of "visual" should be
considered to match a screen target medium, even though visual isn't
any (target) medium at all but a media group).

I suggest that chapter 7 (media.html) give a definition of when a
media list is deemed to match, and that 6.3 link to that definition.
Incidentally, 6.3 might also link to chapter 7 (a few paragraphs
before 7.3.1) as part of specifying its error-handling behaviour
[assuming that we do in fact want the same handling of errors in media

Received on Monday, 7 March 2011 05:34:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT