Re: [CSS21] last edition: pity

On Tue, 5 May 2009, Giovanni Campagna wrote:

> 2009/5/5 Andrey Mikhalev <amikhal@abisoft.spb.ru>:
>>
>> 1. Appendix G. Grammar of CSS 2.1,
>>   G.2 Lexical scanner,
>>   following production was removed:
>>     {s}+\/\*[^*]*\*+([^/*][^*]*\*+)*\/ {unput(' '); /*replace by space*/}
>>
>>   production essential for selector parsing: without it selectors like
>>   'A /**/>B'
>>   became invalid (token sequence is "ident,s,greater,ident" instead of
>>   "ident,greater,ident")
>
> I think the error is in the definition of "selector" that does not
> allow space tokens before the combinators, assuming that space is
> inside the GREATER token.

i think - in any case - tokenizer should be adequate to grammar.
hence, either:
- restore 'unput' production in tokenizer
- rewrite grammar as LL(2), allow space before combinator 
imo, first is better.

>
>> 2. 4 Syntax and basic data types,
>>   4.2 Rules for handling parsing errors,
>>   Invalid at-keywords:
>>     User agents must ignore an invalid at-keyword together with
>>     everything following it, up to and including ...
>>   following sentence added:
>>     the end of the block (}) that contains the invalid at-keyword
>>
>>   what you are talking about? _ignore_ _end of the block_?!!
>
> Change "up to and including the next semicolon (;), the next block
> ({...}), or the end of the block (}) that contains the invalid
> at-keyword" with "up to and including the next semicolon (;) or the
> next block ({...}), or up to but non including the end of the block
> (}) that contains the invalid at-keyword"

OK. reasonable, then.

>> 3. 4 Syntax and basic data types,
>>   4.2 Rules for handling parsing errors,
>>   following paragraph added:
>>     Malformed statements.
>>     User agents must handle unexpected tokens encountered while parsing
>>     a statement by reading until the end of the statement, while
>>     observing the rules for matching pairs of (), [], {}, "", and '',
>>     and correctly handling escapes.
>>     ...
>>
>>   most evil idea, violate nearly everything in chapter 4, starting
>>   from formal core syntax.
>>   in short:
>>     'unexpected token' in 'statement' cannot occur - since 'statement'
>>     is not a checkpoint (not a Real Thing, precisely).
>>     handling of parsing errors differs for selectors / declarations /
>>     at-rules.
>>     paragraph above redundant and introduce conflict with them.
>
> A declaration is not a statement. The error handling is the same for
> rulesets and at-rules, the difference is only that ";" close at-rules.
> To make it clearer we could write "User agents must handle unexpected
> tokens encountered while parsing a statement by ignoring up to and
> including the next block (or ; if the statement is an at-rule), while
> observing the rules for matching pairs of (), [], {}, "", and '', and
> correctly handling escapes".

as i said, error handling is right opposite.
unexpected token in selector invalidate statement.
unexpected token in declaration invalidate only declaration.
from now, try to write down tokens which are 'unexpected in statement',
and you got the picture.

futuremore, sentence violate following:
4.1.6
A block starts with a left curly brace ({) and ends with the matching 
right curly brace (}). In between there may be any tokens, except that 
parentheses (( )), brackets ([ ]) and braces ({ }) must always occur in 
matching pairs and may be nested
4.1.7
The selector (see also the section on selectors) consists of everything up 
to (but not including) the first left curly brace ({)

note last sentence does not enforce 'matching pairs', and, in fact, is 
prose replacemnent for
error '{'
parser directive.

worth all above formal objection?

>
>> 4. 15 Fonts,
>>   15.6 Font boldness : the 'font-weight' property:
>>     'bolder' selects the next weight that is assigned to a font that is
>>     darker than the inherited one.
>>   following sentence removed:
>>     If there is no such weight, it simply results in the next darker
>>     numerical value (and the font remains unchanged), unless the
>>     inherited value was '900' in which case the resulting weight is also
>>     '900'.
>>   [similar in 'lighter']
>>   following paragraph added:
>>     Note: A set of nested elements that mix 'bolder' and 'lighter' will
>>     give unpredictable results depending on the UA, OS, and font
>>     availability. This behavior will be more precisely defined in CSS3.
>
> It seems that this is to avoid backward compatibility problems when
> CSS3 Fonts will be published, which currently says that synthetic bold
> faces have problems with bolder/ligther. Actually, I cannot understand
> what problems, I'd like to hear from implementors.

well, i am an implementor :)