W3C home > Mailing lists > Public > www-style@w3.org > May 2009

[CSS21] last edition: pity

From: Andrey Mikhalev <amikhal@abisoft.spb.ru>
Date: Tue, 5 May 2009 15:18:42 +0400 (MSD)
To: www-style@w3.org
Message-ID: <Pine.LNX.4.63.0905051441001.10102@master.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")

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_?!!

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

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.

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

hope you rollback mentioned trash.
hope you stop hacking mature specification for unusal css3 toys,
especially core syntax section.
please.
Received on Tuesday, 5 May 2009 11:19:26 GMT

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