Re: [css3-values] About calc()

2009/2/10 L. David Baron <dbaron@dbaron.org>

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

What will you do? Will you change example or switch to used value instead of
computed value? I would prefer the latter, although it may not be possible
for example for width property (you need the width to compute the used value
of horizontal margins)

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

Actually, we only have lengths at the moment, so an implementation could
simply carry the grade (ie pixels vs square pixels vs cube pixels vs no
unit) and raise a math error (the same as division by zero): what this means
is currently undefined, maybe resorting to inherit if the property is
inherited, else initial could be the right way

>
>
> > 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.
>
I meant the opposite, ie setting background-color dependent on color. This
is the only thing you can do without property dependency, because
currentColor is the only variable keyword.


>  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.
>
The TV profile may ignore the calc() syntax for colours.


> (As a browser, we try to do this for selected text, and it doesn't
> always work.)
>
This was exactly the use case I had in mind.


> > 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.
>
It was a very abstract concept for avoiding adding a layout system, a set of
property, an algorithm and a specification every time author have new
incredible ideas on how to style their pages. But I agree with you,
complexity can be very high (or it is just impossible at all)

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