Re: [css3-values] About calc()

On Sunday 2009-02-01 13:43 +0100, Giovanni Campagna wrote:
> 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.

If the draft implies that width:calc(100%-5px) doesn't work, then
that's a bug in the draft that we need to fix.

> 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.

Hmm.  It seems reasonable, although we'd have to require that the
implementations carry around units and check that:
 * both sides of a + or - have the same units
 * the final result has either length, angle, time, or unitless
   units, as appropriate for the property

> 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

This is far from trivial, for a number of reasons:

 a. the background that text is on is often hard to figure out, and
    it need not be a solid color.  It could be an image, or a
    partially-opaque color on top of an image, etc. etc.

 b. What combinations are visible relative to each other are also
    complicated, especially in the presence of:
    i. color-blindness
    ii. NTSC television displays, in which some horizontal color
        transitions require multiple pixels.

(As a browser, we try to do this for selected text, and it doesn't
always work.)

> 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.

This doesn't seem implementable to me.  There are already enough
(undocumented) dependencies on computation between properties, and
introducing this into the already-very-complicated CSS layout
algorithms would be a nightmare.

I think we instead need layout systems that do what authors want.

> 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)

Do you have actual use cases for them?

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 10 February 2009 02:10:16 UTC