W3C home > Mailing lists > Public > www-style@w3.org > February 2009

[css3-values] About calc()

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sun, 1 Feb 2009 13:43:43 +0100
Message-ID: <65307430902010443ke210d3ah11ad37b74c921959@mail.gmail.com>
To: www-style@w3.org

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.

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?

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.

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

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)

Received on Sunday, 1 February 2009 12:44:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC