Re: [css3-values][css3-transforms] relative length in functional notation

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.

~TJ

Received on Thursday, 5 July 2012 07:35:29 UTC