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

Hi, Tab-

I think your arguments (along with the note by Alex) are the best 
defense I've heard for adding e-notation to CSS. I absolutely buy your 
argument.

I've been coding SVG, mostly in webapps, for about a decade.  I have 
never once, not even in test code, used e-notation; I seriously doubt I 
ever will (unless I get that action in the SVG WG).

I don't think it's a really serious issue; there are other ways of 
denoting large numbers.  I imagine that there are uses for it, 
especially in mapping (which is really picking up these days [1]), but 
it's a convenience, not a necessity, in my opinion.  My preference is to 
allow e-notation, but it's not a strong preference; to me, the pros come 
down to this:
* Some people have said they find it useful
* For good or ill, it's already allowed in CSS in SVG, so there's 
backwards-compatibility to consider
* I really want to see convergence of SVG and CSS (and HTML)
* I don't see the harm in adding it.

For me, at this point, the larger principle is this: the SVG and CSS WGs 
need to work together, and not get caught up in matters that don't help 
the community.

How many hours of valuable time has this issue consumed, during the 
face-to-face, and via email?  How much tension?  Is either position 
really worth the effort and stress this has cost over the years?  And 
how much time will it eat up in the future, when we could be talking 
about important or useful or cool things (I can think of a dozen off the 
top of my head, can't you)?

I think adding e-notation is the right thing to do.  But, for the sake 
of moving on, I am going to propose that we take a serious look at 
dropping it, not only from CSS, but from SVG 2.  For SVG, obviously, 
this would mean deprecating it rather than simply not including it.

I'll be honest, I think I'm taking the wrong technical side of this 
issue, but it's a change I could live with, and that's pretty much the 
consequence of consensus.  My heart isn't in this conclusion, but it is 
important to me that we move ahead.

What does everyone else think?

[1] http://schepers.cc/map-not-proprietary

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Tab Atkins Jr. wrote (on 8/27/10 10:03 PM):
> On Fri, Aug 27, 2010 at 2:46 AM, Håkon Wium Lie<howcome@opera.com>  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".
>>
>>    http://en.wikipedia.org/wiki/Scientific_notation#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
> values
> * 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.
>
> ~TJ
>

Received on Sunday, 29 August 2010 00:27:36 UTC