From: Tab Atkins Jr. <jackalmage@gmail.com>

Date: Thu, 5 Jul 2012 00:34:37 -0700

Message-ID: <CAAWBYDD8hHfRaj_zv3UFpPMHvr0U8ni=B9whyLK0aaAGp=HieA@mail.gmail.com>

To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>

Cc: WWW Style <www-style@w3.org>

Date: Thu, 5 Jul 2012 00:34:37 -0700

Message-ID: <CAAWBYDD8hHfRaj_zv3UFpPMHvr0U8ni=B9whyLK0aaAGp=HieA@mail.gmail.com>

To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>

Cc: WWW Style <www-style@w3.org>

On Wed, Jul 4, 2012 at 12:09 AM, Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> wrote: > (12/04/24 3:55), Tab Atkins Jr. wrote: >> Issue 2: calc() and attr() need to resolve values that are normally >> changed at computed-value time >> Closed as Accepted - the spec now says "The computed value of a calc() >> expression is the expression with all components computed, with all >> multiplication/division subexpressions resolved, and with all >> addition/subtraction subexpressions resolved where both sides are the >> same type." >> >> Let us know if this is acceptable! > > Sorry but I just realized the current wording is sort of vague when > talking about a corner case: 'height: calc(0*0%)'. It is treated as > 'height: auto' in IE9, Firefox13 and a Chrome version with > '-webkit-calc', similar to 'height: 0%', not 'height: 0'. > > Therefore, the note > > # Thus, the computed value of a ‘calc()’ expression can be > # represented as either a number or a tuple of a dimension and a > # percentage. > > is sort of inexact in that it doesn't say '0' and 'undefined' are different. > > > The spec should provide a hint to css3-flexbox too. calc(0*0%) should > probably be treated as indefinite if resolved against an indefinite length. > > > Also, I think "same type" in the quoted prose here should be elaborated > a little bit. The rest of the description of 'calc()' talks about > "resolved type", but both <percentage> and <length> have the same > "resolved type" for the cases we care. > > Proposed wording (just a try): > > | The computed value of a calc() expression is the expression with > | all components computed with all multiplication/division > | subexpressions resolved, and with all addition/subtraction > | subexpressions resolved where both sides are the the same type, > | unless one of which is <percentage> (which doesn't compute to an > | absolute unit) and the other isn't. User agents must track whether > | a <percentage> is contained a calc() with a flag. > | > | If 'height' is specified with calc() containing a <percentage> > | , the value must be treated as 'auto'. A length specified with > | calc() containing a <percentage> when the <percentage> is resolved > | against an indefinite length is an indefinite length. Otherwise, > | it's definite. I don't think we need to make this change. The type resolution rules definitely state that if you multiply a number with something else, the type is the "something else". So, "0 * 0%" will resolve to a percentage (or rather, the resolved type of the percentage). This means that it'll be representable as a length/percentage tuple, and receive normal handling for that case. > A somewhat irrelevant nit picking: > > # At ‘,’, ‘+’, or ‘-’, check that both sides have the same > # type, or that one side is a <number> and the other is an <integer>. > > ',' is no longer relevant since we dropped max() and min(). Good catch. ~TJReceived on Thursday, 5 July 2012 07:35:29 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 11 February 2015 12:35:12 UTC
*