Re: [css3-values] About calc()

On Sunday 01 February 2009, Giovanni Campagna wrote:
> I think that calc() is a very useful feature, but it has some
> problems and limitations:
>
> 1) current draft says that calc() value are resolved when em units
> are elaborated, that is, when computed values are applied (before
> flowing): this is in contrast with the example (the value of 100%
> width can only be got from the used value of parent width) and it is
> a huge limitation.

The way I imagine calc() to work is that the expression is reduced to a 
triple (a,b,c) at parse time, with the meaning

    a em  +  b %  +  c px

This is the expression's "specified value." The storage required is more 
than for current lengths (3 floats instead of one float and 2 bits), 
but still constant and limited.

Divisions by zero are caught at parse time and thus impossible 
declarations can be properly ignored. This requires that the syntax 
only allows numbers in the denominator of divisions, not lengths...

Example:

    calc((10em + 50% - 1in)/2)

can be represented as

    (5, 25, 48)

The "computed value" can be computed as soon as the value of 'em' is 
known. The "used value" can be computed when the referent of the 
percentage has been computed (which may fail, as described by each 
property where it occurs.)

>
> 2) what happens if there is a math error?
> Some are easy to find, eg. calc(1px / 0), some are not: calc(1px /
> (55 * (78 - (5 * 15 + 3)))). Are UAs required to normalize number
> values as soon as they're parsed?

As long as you can only divide by numbers, it is possible to find 
denominators that are 0.

Other errors can also occur, of course, such as overflow due to the 
limited number of bits per number. Maybe we should say something about 
the minimum number of bits UAs must store per number and that they 
don't have to rearrange expressions to avoid overflow. But in practice, 
I expect overflows to be the result of author error anyway. Whether you 
get a 10km high box or no box at all: you probably wanted neither.

>
> 3) why where not able to multiply or divide between lengths?
> Allowing multiplication between anything we could allow ratio-based
> rescalation, ie. a length multiplied by the ratio between two
> lengths.

Complicated...

>
> 4) the grammar is missing some spaces, that occur in the example
> (actually, what are missing are "S" tokens)

True, but they would also make the grammar less readable. Maybe a 
sentence in English that says that spaces may, and sometimes must, be 
added between tokens is enough?

A warning is probably needed anyway, because not everybody would 
notice immediately that calc(1px+5px) is OK, but calc(10px-5px) is 
invalid, because the unit 'px-5px' doesn't exist in current CSS.

... unless we want to define that UAs must re-parse calc() somewhat like 
they re-parse 'nth-child()': putting the tokens back into a string and 
then looking for certain known identifiers. That, of course, would mean 
we can never introduce units with a dash.

>
> Now the features I would like to see added:
>
> 1) calculations for other types:
> - for color, this is a simple way to have the text always visible
> regardless of the background color (or vice versa), without writing
> an appropriate color for each background-color
> we could use either vector mathematics (considering colours as 3D
> vectors) or red(), green(), blue() function to extract the
> corresponding component from the appropriate value (or hue(), sat(),
> lum() for the HSL model)
> - it may apply to any type that are not keywords, strings or urls,
> like times, angles, frequences or pure numbers.
>
> 2) dependencies on other properties of the same elements: I know,
> this is very likely to be buggy, especially with box model related
> properties, but it would mean a great advantage for authors and could
> make easier to write a liquid layout.
>
> 3) some base maths functions, like pow(<base>,<exp>), to allow a
> greater extensibility (trigonometry or logarithms may be useful, but
> I'm not sure they're required)

Stephen Hawking wrote in the preface to his book "A brief history of 
time" that he was warned that every equation in his book would reduce 
his audience by half. (He ended up with just one: E = mc^2, which, by 
that calculation meant he lost 9 million readers...) I think something 
similar holds for CSS: every pair of parentheses or nested braces we 
add, reduces the number of users by half.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Tuesday, 24 February 2009 20:57:04 UTC