W3C home > Mailing lists > Public > www-style@w3.org > February 2010

Scientific notation in numbers

From: Zack Weinberg <zweinberg@mozilla.com>
Date: Wed, 10 Feb 2010 12:44:15 -0800
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20100210124415.37958283@mozilla.com>
One implementor's comments on the scientific notation issue (please
keep in mind that dbaron may disagree with me):

Mozilla has a mode switch in the CSS lexer.  In "SVG mode", the syntax
for the core NUMBER production becomes

  ([0-9]+|[0-9]*"."[0-9]+)(e[+-]?[0-9]+)?

This also affects DIMENSION and PERCENTAGE tokens.  A NUMBER token with
a scientific-notation suffix is always treated as having a fractional
component, regardless of whether it does in a mathematical sense (that
is, it is not acceptable in contexts that require an integer) but is
otherwise not special cased.  "SVG mode" applies to style attributes on
SVG elements, but not to full style sheets linked from or embedded
within SVG documents.

The modified lexical rule is NOT consistent with the forward- 
compatible (section 4) grammar, because of the optional plus sign.
"1.24e+23" is one token in "SVG mode" but three tokens in the
forward-compatible grammar.

Two characters of look-ahead are required, because when "124e+" is
encountered, the plus will not be consumed if the character after that
is not a digit. This is not a new requirement on implementations;
dbaron is mistaken. Ignoring URI which is a special snowflake, the
character sequence "-\" also requires two characters of look-ahead (if
there is a newline or EOF after the backslash, the dash is a DELIM, not
the beginning of an identifier) and the sequence "<!-" requires three
(if a dash follows, this is a CDO token, otherwise the less-than sign
is a DELIM).

I actively want to eliminate the mode switch; it adds extra branches to
a hot path in the lexer, and it is the only such wart in the lexical
rules.  To do so, scientific notation must either be accepted
everywhere that NUMBERs are accepted, or forbidden everywhere.  I don't
much care which, but I am opposed to howcome's compromise proposal of
allowing scientific notation only in property values where it is
"necessary".  That would *not* eliminate the mode switch, it would add
extra complexity to the parser (which would now have to toggle the
switch on particular properties, and might have to care about whether
SVG disagrees with CSS-proper about whether scientific notation is
necessary in some context), and it strikes me as a documentation
nightmare.

I do not want lexical rules that forbid DIMENSION or PERCENTAGE
suffixes on scientific notation.  That would require *variable*
length look-ahead; the only current instance of that is URI and
I intend to submit a proposal to eliminate that Real Soon.  I would
be okay with making scientific notation plus % an automatic *parse*
error (kinda like INVALID partial-string tokens), but I don't think it
buys us anything.  And I think scientific notation plus a DIMENSION
suffix is probably useful in some circumstances, and should be
allowed, if scientific notation is allowed at all.

I don't buy the assertion that scientific notation will enable
browser-sniffing.  NUMBERs can only appear in a property value
(per the appendix G grammar) so the most aggressive differentiation
between implementations that you can achieve with scientific notation
is to wipe out one property declaration.  How's that different from
feature-sniffing for novel property values, which we encourage?

I'd like to point out that css3-selectors already broke the
forward-compatible grammar by introducing new match operators. That
enables more browser-sniffing than this does, since you can wipe out an
entire ruleset with an ill-formed selector.

zw
Received on Wednesday, 10 February 2010 20:44:51 GMT

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