Re: [css-style-attr] SVG WG comments on CSS Styling Attributes Level 1

On Fri, Aug 27, 2010 at 2:46 AM, Håkon Wium Lie <> wrote:
> Also sprach Chris Lilley:
>  > >> Looking back in time by reading the source code of Unix
>  > >> edition 7 which dates back _a long time_ (the '70s) I see that the
>  > >> 'C' function 'scanf' can handle parsing scientific notation.
>  >
>  > Indeed, lex allows scientific notation (as the original comment
>  > from SVG notes). CSS however uses a modified lex grammar which does
>  > not allow scientific notation.
> A better term for the notation in question may be "e notation".
> This notation is an artefact from limited i/o capabilities of
> calculators and computers. It looks quite differnet from classic
> scientific notation, though.

And yet it's still commonly used.  It's how javascript and many other
languages serialize large or small floats.  Python, which is
essentially the lingua franca of programming discussions these days,
accepts e notation natively.  You can say "x = 2e3; print x" and get
2000 printed to the output.

You call it an artifact.  I call it a ubiquitous, living notation
embraced by all the programming languages people are using today.  I
think I have more evidence for my position.

> I hope no UA starts accepting the e-notation in CSS unless it -- over
> my body -- ends up in a W3C Recommentation. For example, I don't want
> to see this in style sheet:
>  h1 { font-size: 2.6e-4em }

This is the sort of thing Chris was complaining about; no one will
ever write that.  It's a strawman.  The font-size property's range of
useful values in practice are 1-2 digits, 3 on the outside.

e notation in CSS has 3 primary use-cases, and none of them are
font-size values:

* allowing SVG authors, for whom large or small values are used more
often, to write the same style values regardless of whether it appears
in an attribute or a property
* allowing the convenient serialization of transformation matrices
from the Transforms spec, which can easily contain very large or small
* allowing authors to write values straight from javascript to CSS
without having to worry about if the value is large or small enough to
trigger e notation when serialized, or having to write a custom
serialization function to avoid that (the CSSOM Values API should kill
this case, though, as it'll eliminate the serialization step)

Across most of CSS, the range of values that are used in practice are
nowhere near the range where e notation makes sense to use.  It's not
even useful for that group of authors that optimize every byte of
their stylesheet, since e notation uses a minimum of 3 characters per
number, which is equal or greater than the amount you need to just
write the number directly in nearly all cases.

It's not helpful to bring up unrealistic fears of authors writing
unmaintainable stylesheets with e notation.  In addition to the fact
that authors can in general read e notation just fine, e notation is
of niche use in CSS.  It has at least one situation where it can be
very useful (transformation matrices), but this is mostly about
converging with SVG.  You're attempting to inflate the cost of this
change through hyperbole.


Received on Saturday, 28 August 2010 02:04:49 UTC