Re: [css3-values] About calc()

L. David Baron wrote

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

The draft says: "The expression within the parethesis is computed at
the same time as 'em' lengths are computed". It seems more reasonable
that units inside calc() are evaluated at the same time as outside
calc(). 

I suggest we remove that statement.

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

I don't think we need to specify when errors should be found, but the
specification should probably say something along the lines of:

 "The value is ignored if a division by zero or other mathemathical
 errors occur in the calculation."

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

I'm hesitant to require this until we have implementation experience.
For now, I suggest adding a note

  "Issue: Division by length units will allow ratio-based measurements."

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

I'm trying to think of cases where a space is required. I hope there
are none. Consider these examples:

  width: calc(3px3em)
  width: calc(3px-3em)

The first example consists of two length values without a space
between them. So does the second. We want to first to be illegal, but
the second to be legal. The trick is to ensure that the '-' sign is
interpreted as an operator and not part of the value. 

Hmm.

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

Agreed. 

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

Agreed.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Sunday, 15 February 2009 21:38:13 UTC