W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: [css3-values] The 'calc' function

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 21 Apr 2010 10:16:06 -0700
Message-ID: <o2wdd0fbad1004211016k264ed76ezb574e9f96028fb96@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Rossen Atanassov <ratan@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Apr 7, 2010 at 5:53 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Wednesday 2010-04-07 17:35 -0700, L. David Baron wrote:
>> This is an interesting question.  I definitely don't want to make
>> inheritance depend on layout.  Given that, I think there are two
>> reasonable options:
>>
>>  (1) the computed value of a calc() expression is the expression
>>  transformed by computing the value for all its leaf nodes
>>
>>  (2) say that the computed value of a calc() expression is the
>>  expression itself
>>
>>  (3) say that the computed value of a calc() expression is the
>>  expression transformed by transforming all relative length units
>>  into absolute units.
>>
>> Initially, I would have thought that (1) was the logical choice.
>
> Actually, I think there's another option that might make the most
> sense:
>
>  (4) say that the computed value of a calc() expression is the
>  expression transformed by:
>    (a) transforming all relative length units into absolute units
>    (b) transforming all percentages just as they are transformed
>    when computing the value of the property.
>
> This has the significant advantage that for properties that don't
> accept percentages or where percentages are computed for the
> computed value, calc() does not add any complexity to the
> representation of the computed value (which means less complexity in
> the implementation).
>
> (I'd also note that, with any of the proposals, user agents should
> be free to perform any desired syntactic simplification they want
> based on mathematical equivalence.)

After reading through things and thinking a bit, I think this #4 works
the best.  It captures the ideal behavior for the two cases that were
brought up in Rossen's original email (matching the un-calc()ed
behavior) and similar non-trivial cases, while still allowing the
useful cases that Steve brought up (allowing units that are invalid
for the property, so long as they resolve themselves away and you're
left with a valid unit for the property at the end).

~TJ
Received on Wednesday, 21 April 2010 17:25:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT