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

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

From: Alex Danilo <alex@pagefire.com>
Date: Sun, 29 Aug 2010 14:18:14 +0000
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
Message-Id: <HM3X7L.51Z8EYV44GK@pagefire.com>
To: Doug Schepers <schepers@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 Wednesday, 1 September 2010 07:52:04 GMT

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