- From: Alex Danilo <alex@pagefire.com>
- Date: Sun, 29 Aug 2010 14:18:14 +0000
- 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 Wednesday, 1 September 2010 07:52:04 UTC