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>

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). ~TJReceived on Wednesday, 21 April 2010 17:25:03 UTC

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