- From: Zack Weinberg <zweinberg@mozilla.com>
- Date: Tue, 9 Feb 2010 16:30:23 -0800
- To: Chris Lilley <chris@w3.org>
- Cc: www-style@w3.org
Chris Lilley <chris@w3.org> wrote: > > These comments relate to CSS Styling Attributes Level 1, W3C Working > Draft 21 January 2010 from the perspective of SVG. I can only comment on one of your points, and I do not speak for the committee. > This appears to allow unitless values ('number'), for those properties > defined to accept them, and scientific notation, for those properties > defined to accept it. However, that depends on the exact syntax of the > NUMBER token, which is apparently defined in a printed book. > > [FLEX] > "Flex: The Lexical Scanner Generator", Version 2.3.7, ISBN > 1882114213. I believe this is the citation appearing at the beginning of section G.2? If so, I think you have misunderstood the citation; my reading is that that reference only defines the _notation_ being used immediately below to define the tokenization rules. The actual definition of NUMBER is given by these lines from section G.2: num [0-9]+|[0-9]*"."[0-9]+ {num} { return NUMBER; } Thus, a NUMBER is always unitless (unitful numbers are DIMENSION tokens, syntactically {num}{ident}) and cannot (in CSS2.1 as it is today) be written in scientific notation. Mozilla's CSS parser has a special mode for all styles loaded from SVG, including inline styles on SVG-namespace elements. In that mode the above regular expression becomes num ([0-9]+|[0-9]*"."[0-9]+)(e[+-]?[0-9]+)? (as always, the "e" is case-insensitive). Numbers with this suffix are interpreted as scientific notation. A % or {ident} suffix may follow the exponent (which converts the token to a PERCENTAGE or DIMENSION token); I haven't actually read the relevant part of the SVG spec so I don't know if that's proper, but I imagine it is necessary at least for DIMENSIONs. I have been considering a formal proposal to add this to CSS generally, mainly because it would be nice to get rid of the mode bit. It might be too late for CSS Level 2, though. zw
Received on Wednesday, 10 February 2010 00:30:58 UTC