Re: css3-background: grammar issue

On 17/2/10 16:46, Yves Lafon wrote:
> On Wed, 17 Feb 2010, Bert Bos wrote:
> 
>> On Saturday 09 January 2010 09:11:53 Yves Lafon wrote:
>>> Hi,
>>> In this example:
>>>
>>> background: /10em
>>>
>>> It is parsable according to [CSS21 section 4] but not according to
>>> the grammar in appendix G
>>
>> The grammar in appendix G is an approximation of CSS level 2 only. We
>> don't have a grammar for level 3, but we do have one for the whole of
>> CSS, viz., in chapter 4. The rule above conforms to that grammar.
> 
> I never said the opposite. Just to mention that '/' as an operator in a
> parser that is mostly written for CSS21 is easy to do, but adding an
> extra case for _starting_ 'background' with a '/' is far more painful.

The CSS WG just decided that it is not very user-friendly to have a "/"
with nothing before it. The WG will decide next week if it wants to
retract the current CR and change the spec to disallow a size without a
position immediately before it. In fact, it wants to try first how it
looks with a keyword instead of a slash. Something like:

    ... || <bg-position> [ "as" <bg-size> ]? || ...

>> There is no reason to disallow it on syntactical grounds, but one could
>> argue that it looks confusing. However, I don't think it is a very
>> strong argument.
> 
> Ok, so why is CSS3-background disallowing
> background: url("foo.png") / 10em black 10em
> and not
> background: url("foo.png") 10em black / 10em

Because requiring the position to come before the size was the smallest
change to the spec that was sufficient to make the grammar unambiguous,
and it's a relatively simple rule for users to remember.

But, as I said, the WG now leans to making the grammar even more
restricted, to make it more user-friendly, and
easy to explain: you can have a position, or a position and a size, but
not a size on its own.

> 
> There is nothing confusing in those two cases, and the generalisation of
> the simple rule "/ <bg-size>  immediately followed by <bg-position>" into
> "<bg-position> must not occur before '/ <bg-size>" seems like a strange
> decision as well. Just saying that 'background' can't start with
> '/ <bg-size>' is in the same range of text-based constraint.
> 
>>>
>>> 2/ outlining the grammar change to appendix G in the CSS3 Background
>>> and Borders document (as in other CSS3 specs when such things occur),
>>> but it doesn't solve my issue on how to report the error in the CSS
>>> validator...
>>
>> Appendix G says explicitly that it contains a grammar for level 2. I
>> don't see how we can make it any more explicit.
> 
> So why some CSS3 specs (like image) refers to this appendix G of CSS21?
> Please provide a revised grammar, like it was done for mediaqueries, for
> example.

If a CSS3 module refers to appendix G, then that is probably an error. I
don't see a reference to appendix G in css3-images.

Each module contains grammars for the restrictions it imposes beyond the
generic syntax. For most modules that just means grammars for each
property value. But we don't have a complete level 3 yet, we don't know
what parts of the syntax of CSS will not be used in level 3.

> 
>> Whether the validator prints an error for 'background: /10em' depends on
>> the profile that the user chose. The declaration is invalid if the
>> chosen profile is level 2. But if user chose level 3, or no profile at
>> all, then the declaration is valid and there should be no message.
>>
>> The declaration 'background: / black' gives an error under all profiles.
>> It's currently not valid in CSS at all.
> 
> Ok, so on that case, a validator should say "you're on your own, it's
> invalid" or be more explicit to guide and help the user? (which leads
> to... what kind of error is it).

I'd say there are the following kinds of errors:

1) Parsing errors for which no recovery rules are defined in CSS. These
are the most dangerous errors, because different implementations may do
different things. Illegal Unicode code points, such as U+0000 or U+FFFE,
fall in this category.

2) Parsing errors for which recovery rules are defined. They are errors
and will always be errors, but most implementations will skip the same
amount of surrounding text. An example is 'foo { not a property: bar }'.
This is a parsing error that can be detected at the "a" (at least in a
left-to-right parse), and CSS says that the recovery in that case is to
ignore everything from the "not" up to and including the "bar" and so
this error is less dangerous than errors of type 1.

3) Syntactically valid text that is meaningless in current CSS. Such
text is reserved for future use. An example is 'foo { speed: high }',
which is parsed as a normal rule, but contains a property that doesn't
yet exist. Of course, some things are more likely to be used for future
extensions than others, but it would be difficult to define what factors
make something likely...

4) Features that are not required for conformance to some profile or
some media. E.g., an implementation of the mobile profile or of level 1
need not support 'text-shadow'. If the validation is explicitly against
a specific profile or media, the message should tell the user that the
feature is valid in itself, but not part of the requested profile. It's
not an error, because there can be good reasons to have the feature
anyway (e.g., if the style sheet is shared among several media), but it
should be reported, because the user of the validator explicitly asked
for it.

5) Constructions of doubtful use or features that are often used
incorrectly. Some heuristic rules can find features that have high
chance of not doing what the user expected. E.g., using 'display: none'
and any other declaration together makes that other declaration useless.
The user may want to do it anyway, e.g., because another, more specific
rule changes the 'display' for specific elements and the user likes to
write things this way, but a warning could also help him find a mistake.
Another example is using selectors that can never match, such as ':root
:root' or '#id #id'. Maybe they are there on purpose for some Javascript
trick, but they are just as likely to be mistakes. It is a good idea to
let the user turn these heuristic checks off.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 18 February 2010 13:53:19 UTC