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: David Singer <singer@apple.com>
Date: Wed, 1 Sep 2010 13:58:49 -0700
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org, www-svg@w3.org
Message-Id: <CCB6682F-7CC9-4324-9554-1CF753455A02@apple.com>
To: Håkon Wium Lie <howcome@opera.com>
I really still don't see the problem here.  It's reasonable to want to round-trip numbers through javascript.  It's reasonable to want uniform number handling in W3C specs, especially between SVG and CSS.  E-notation parsing is, for the most part, considered a solved problem in reasonable code size, I believe :-).  Unless it introduces problems stronger than 'don't like' / 'don't need' (e.g. the presence of the 'e' seriously complicates other parts of the grammar), we should introduce it and move on. And spent the braincycles of the group on Really Interesting Problems (TM). Please?

On Sep 1, 2010, at 13:30 , Håkon Wium Lie wrote:

> Also sprach Boris Zbarsky:
>>> (I also think there should be a way to serialize JS without suddenly
>>> switching notation.)
>> In theory, there is.  It will, generally speaking, produce decimal 
>> numbers with up to 300 digits or so, right?
> That sounds exhaustive. There is no way to set the precision? Like "%.2f"?
>> Note that JS will only switch to e-notation for numbers whose absolute 
>> value is more than 10^20 or less than 10^{-6}. [1]  While using decimal 
>> notation for the latter can sort of be ok if they're close to 10^{-6}, 
>> for the 20-digit or more ones it gets pretty silly very fast.
> Right. I can't think of a meaningful way of using numbers as small as
> 10^{-6}. At that stage, most properties would be happy with
> zero, I believe.
> -h&kon
>              Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 1 September 2010 20:59:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC