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

(12/07/05 15:34), Tab Atkins Jr. wrote:
> 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).

No, the resolved type of <percentage> is <length> and you can't resolve
to it at computation time (unless the property is 'font-size',
'line-height' or 'vertical-align').

> This means that it'll be representable as a length/percentage tuple,
> and receive normal handling for that case.

Let me restate my main issue again:

Issue:

  There's is no normative stating when and what 'calc()' is treated as
'auto' when used in 'height'. Either this spec or css3-box should
specify this. Is your intention to defer this to css3-box? css3-values has

  # Given the complexities of width and height calculations on table
  # cells and table elements, math expressions involving percentages
  # for widths and heights on table columns, table column groups, table
  # rows, table row groups, and table cells in both auto and fixed
  # layout tables MAY be treated as if ‘auto’ had been specified.

too so it seems the right fit here.



Cheers,
Kenny

Received on Thursday, 5 July 2012 08:07:22 UTC