Re: [CSS21] last edition: pity

On Thu, 7 May 2009, Bert Bos wrote:

> On Tuesday 05 May 2009, Andrey Mikhalev wrote:
>> 1. Appendix G. Grammar of CSS 2.1,
>>     G.2 Lexical scanner,
>>     following production was removed:
>>       {s}+\/\*[^*]*\*+([^/*][^*]*\*+)*\/ {unput(' '); /*replace by
>> space*/}
>
> This indeed looks like a mistake. But the unput() wasn't correct
> either, because it allowed 'A/**/B' without any combinator.
>
> The change was made in response to an issue[1] that was raised on this
> mailing list. When we discussed it, we noticed that the grammar in
> appendix G and in the Selectors module were different. We thought the
> latter looked better and copied it. It seems now that the Selectors
> module wasn't correct either.

1. unput() solution, even is a hack, is _correct_
    (note s+ in regexp, A/**/B is not allowed)
2. issue 5[1] specific to css3. my primary concern is that csswg
    decide to 'fix' stable css2 for experimental css3 things
    (copy grammar which 'looks better'? hmm...)

> There were also errors in the resolution of issue 104[2]. The first of
> the changes is meant to fix that.

issue 104[2] mention minor syntax errors in yacc code.
no reason to touch tokenizer, at least in css2.

> [1] http://wiki.csswg.org/spec/css2.1#issue-5
> [2] http://wiki.csswg.org/spec/css2.1#issue-104
>
>> 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
>
> I think we meant "up to the end of the block (}) that contains the
> invalid at-keyword" rather than "up to and including." The intention
> was precisely to make it clear that the "}" should *not* be ignored.

this was already clarifed in the list, but i should mention that you made 
spec worse anyway:

it was obvious, but from now, since explicitly specifed
for at-rules and NOT explicitly specified for ruleset (4.1.7),
i should handle them differently, e.g.:
   @media x { bad selector } { block of bad selector }

>> 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.
>
> The intention is that the rule for malformed declarations takes
> precedence over that for malformed statements, as it comes
> first in the spec. Thus an unexpected token in a declaration
> causes just the declaration to be ignored, not the whole statement.

hmm... where is 'rules of precedence' for w3c documents interpretation
defined? css itself claims right opposite order.

> The new rule about malformed statements is a generalization of
> that in 4.1.7 about errors in selectors: not only an error in a
> selector causes a statement to be ignored, but also an error that
> occurs after an at-keyword, e.g:
>
>    @media @error {...}

then the at-rules error handling section is the place for 
sentence? something like this:
unexpected token outside block brackets should invalidate whole
at-rule; invalid construction inside block should be ignored.

> In fact, although it may not be very clear from the text (which is
> kept as short as possible), but hopefully from the examples, if an
> unexpected token occurs anywhere where a statement *could* occur,
> then that token is ignored together with the next statement. E.g.,
> the whole 1st line is ignored in this:
>
>   } h2 {color: orange}
>   h1 {color: green}

OK, this is the case, i miss it.
imo, better choice is mention that everything which is not at-rule 
should be interpreted as ruleset, somewhere in 4.1.7
(if this behavior really desired, not alternate).

even if discussed text added, it remains unclean that i should
accept '})]' tokens as opening ruleset, hence treat examples 
as specification bug (they claim token sequence
is ruleset while it isn't according both to formal grammar and
prose)

>> 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'.
>
> The text about taking the next available weight or the next
> numerical value if there is no next weight available dates from
> the old CSS2 REC, and assumed that the computed value was a number.

exactly. the only _implementable_ spec.

> But it didn't define what happened for elements with more than one
> font family, so it's likely that taking the next numerical value
> isn't actually a good idea.

1. it shouldn't define.
    font fallback works on per-character basis with codepoint priority
    and may ignore any specified/computed property/value
    (including font-family list itself).
    what e.g. all lengths expressed in 'ex' are doing
    in specification? "what happened for elements with more than one
    font family"?
2. for me, it is the only good idea. works fine.

Received on Friday, 8 May 2009 13:47:11 UTC