W3C home > Mailing lists > Public > www-svg@w3.org > August 2010

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

From: Alex Danilo <alex@pagefire.com>
Date: Mon, 30 Aug 2010 00:15:53 +1000
Message-Id: <HM3X7L.51Z8EYV44GK@pagefire.com>
To: Doug Schepers <schepers@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Håkon Wium Lie <howcome@opera.com>, Chris Lilley <chris@w3.org>, www-style@w3.org, www-svg@w3.org
Well there is a large cost in adding it - namely how do we dispose
of Håkon's body?

Personally I originally asked for a technical reason which wasn't
answered and I don't care either way. 26+ hours sitting on a plane,
this is the last thing I want to waste any more time on.

Which also means I don't want to spend any extra time modifying
our CSS parser to _exclude_ e notation.

So keep it out of the grammar and if you're really nice add a note
that some implementations may choose to implement e notation as a
convenience but it is not normative to support it.

If anyone ever prepares a CSS test that fails expiclitly due
to support for e notation, prepare your inboxes for a tirade!

Cheers,
Alex

--Original Message--:
>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 14:18:15 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:45 GMT