- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 27 Aug 2010 18:19:18 -0700
- To: Christoph Päper <christoph.paeper@crissov.de>
- Cc: "www-style@w3.org list" <www-style@w3.org>
On Fri, Aug 27, 2010 at 5:22 AM, Christoph Päper <christoph.paeper@crissov.de> wrote: > Håkon Wium Lie: >> >> I don't want to see this in style sheet: >> >> h1 { font-size: 2.6e-4em } > > Uch, it really looks like 2.6 e minus 4 em. And who says we wouldn’t want to introduce Euler’s constant as a pseudo-unit at some point in the future? Subtraction isn't valid outside of calc(). If we did introduce euler's constant, it would require spaces between it and the math operators just like numbers do. There's no ambiguity whatsoever. >> If we need very small numbers in some properties, I'm sure there are better solutions. > > There certainly are, appropriate units usually, and functions perhaps. > > h1 {font-size: calc(2.6em / 10000)} > h1 {font-size: frac(2.6em, 10000)} > h1 {font-size: sci(2.6em, -4)} /* scientific x*10^y */ > h1 {font-size: eng(260em, -2)} /* engineering x*10^3y */ > > If we were using percentages for values that can range from 0 to 1, we could do away with lots of decimal points, for instance. (But maybe I’m the only one who prefers integers.) > > A while back I proposed ‘um’ for micrometres since ‘µm’ could pose problems (encoding and U+00B5 vs. U+03BC). If that’s not small enough for absolute units, add nanometres ‘nm’ while at it (to specify colors by wavelength maybe). We also have plenty of prefixes for larger units, although mega ‘M’ and milli ‘m’ cannot be distinguished in a case-agnostic environment; kilo ‘k’ has already been introduced with hertz ‘Hz’, by the way. > > I also intended to suggest a baseline unit (‘u’ for now) which one pixel ‘px’, one point ‘pt’ and one millimetre ‘mm’ (or micrometre) are an integer multiple of. I intended it less as an actual unit authors would use rather than an internal rendering unit, which describes the highest precision authors may expect from user agents. (Ecma 376, OOXML has EMU, I hear, where 3600emu = 1mm, 1270emu = 1pt, 1emu = 0.2_7µm; Tex’s scaled point ‘sp’ is about 5.362851 nm, so roughly 1emu = 51.8sp.) > > So, anyhow, what are the real use cases for E notation? Which propreties need values so huge or so tiny? There are multiple ways to express very large or very small numbers. These types of numbers can be useful, for example, for serializing transformation matrices. If we were solving this problem for the first time, it would make sense to look at multiple solutions. We're not, though - SVG already has a notation for small/large numbers that would be nice to reuse if it isn't too horrible. Luckily, it's not - it's a common, well-known notation used fairly regularly in handwritten math and science (whether you used 2e5 or 2*10^5 seems to be an accident of what your teacher's preferred notation was) and is the way that javascript and many other languages natively serialize small/large floats. Authors are familiar with it, SVG is already using it, it's compact and easily understandable, and it's completely unambiguous. It's very difficult to argue against at a level beyond "I don't like it". ~TJ
Received on Saturday, 28 August 2010 01:20:13 UTC