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