Re: [CSS21] last edition: pity

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.

> 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"

>   @media x { /*...*/ @invalid } /*... style here belongs to what?*/
>
> 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".

> 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.

>   - changing _defined_ behaviour to _undefined_ is not an improvement.
>   - css3 reference nonsence.
>     (imo: if someone tries to turn css2 specification into
>     'css3 todo list' - shoot, don't talk)
>   - the weight metric is independent from font[family].
>     as value of independent metric, 'bolder' SHOULD result next numerical
>     value

It seems so also to me, but I don't know.

>     futher - as a hack for non-perfect world - it MAY (or MAY NOT)
>     yield to next available font's weight.
>     what was unclean here? why you killing primary objectives of
>     property/value, leaving only hack description?
>
> [...]

Giovanni

Received on Tuesday, 5 May 2009 12:23:59 UTC