RE: Scientific notation in numbers

> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Håkon Wium Lie
> Sent: Wednesday, February 10, 2010 2:11 PM
> To: Zack Weinberg
> Cc: fantasai; www-style@w3.org
> Subject: Re: Scientific notation in numbers


> I'm all for removing complexity. And I get a headache from trying to
> read style sheets like this:
> 
>    h1 { font-size: 2.6e-4em }

This looks more like a testcase than a use-case to me but let's go with that. This remains a matter of opinion. Fwiw, I do in fact understand the above immediately but I still can't parse:

 border-radius: 2em 1em 4em / 0.5em 3em;

...without looking it up, and then I still have to do some mental processing to figure out what it'll look like. 

Another example: in its current form, your border-clip proposal in GCPM results in things like:

 border-clip-top: 3fr 10px 2fr 10px 1fr 10px 10px 10px 1fr 10px 2fr 10px 3fr; /* Example XL */ 

...which I'm positive will remain unreadable to everyone who isn't a fiendish user of the feature.

The common CSS2.1 shorthands - font, border, background - have become much more readable with normal practice but still manage to trip me up when I write them. Now, I'm not an experienced author like Tab or Brad. I'm quite possibly the least knowledgeable member of the group, if not this entire mailing list. But that does at least qualify me to state that there are quite a few elements of CSS value syntax that have been and remain much harder for me to parse than standard scientific notation. And that's before we even get into advanced selectors.

Lastly, there is no reason to expect people will start writing 120e-2 instead of 1.2em just because they *can*. 

>  2) it can be used as a browser switch

I can't disagree that this is a risk. As a representative of the browser vendor with the largest market share and the oldest shipping browser still in the field, I believe I had a responsibility to make this explicit and so I did. But this is a risk we already have. As long as browser are on different release schedules, there will be CSS features that allow browser selection. Selectors are quite powerful in this respect: no vendor prefix, the ability to drop entire sets of elements in this browser vs. that one. Yet we all implemented CSS3 Selectors over years. 

So until we have a reasonable use-case for this exact hack - i.e. why/when would you prefer using scientific notation to block older browsers - I am unable to measure this risk in any meaningful manner vs. any of the other possible switches we've already specified. It is an unusual switch in that it's not property-level but at the value syntax level, and it could apply to existing properties. But while that *appears* scarier, I don't yet understand how we establish it matters in practice. Especially given that selector-based switching has been possible for years, and with vastly more power. Were you concerned when Opera implemented CSS3 Selectors ?
 
> Regarding 3), it seems the use of scientific notation in SVG is
> limited to attributes and that we can harmonize without adding
> scientific notation to all properties.

We implementors may be smart enough to manage contextual, property-specific tokenizers. I'm not quite sure how it makes our lives easier - see Zack's post - but I hope our primary responsibility is to the authors who will have to remember when and where they can use which notation. It may be easy now with a handful of new bleeding-edge properties. It may not always stay that way.


[1] http://dev.w3.org/csswg/css3-gcpm/#the-border-clip-properties





> 
> So, I'd like to avoid using scientific notation in CSS.
> 
> There seems to be tree arguments for allowing scientific notation:
> 
>  1) transformations need it
> 
>  2) it can be used as a browser switch
> 
>  3) it helps CSS-SVG harmonization
> 
> Regarding 1), it seems that a string-less API will be even better than
> a scientific notation.
> 
> Regarding 2), the hacks we will see will look ugly. It will just add
> another layer of complexity to coding CSS.
> 
> Regarding 3), it seems the use of scientific notation in SVG is
> limited to attributes and that we can harmonize without adding
> scientific notation to all properties.
> 
>  > I don't buy the assertion that scientific notation will enable
>  > browser-sniffing.  NUMBERs can only appear in a property value
>  > (per the appendix G grammar) so the most aggressive differentiation
>  > between implementations that you can achieve with scientific
> notation
>  > is to wipe out one property declaration.  How's that different from
>  > feature-sniffing for novel property values, which we encourage?
> 
> Adding new property values opens up for browser sniffing, but it is
> rarely a goal in itself -- it's more of an unwanted side effect of
> adding useful functionality.
> 
> Cheers,
> 
> -h&kon
>               Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome

>

Received on Thursday, 11 February 2010 01:22:44 UTC