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

On 07/09/2012 05:37 PM, Kang-Hao (Kenny) Lu wrote:
> (12/07/10 4:59), Tab Atkins Jr. wrote:
>> On Thu, Jul 5, 2012 at 1:06 AM, Kang-Hao (Kenny) Lu
>> <kennyluck@csail.mit.edu>  wrote:
>>>    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?
>>
>> Yes, another spec (likely Box) will define the currently-undefined
>> behavior of percentages in certain properties.  This includes when
>> they appear in calc().
>
> For what's worth, percentage in 'height' is relatively well-defined:
>
>    #<percentage>
>    #
>    # Specifies a percentage height. The percentage is calculated with
>    # respect to the height of the generated box's containing block. If
>    # the height of the containing block is not specified explicitly
>    # (i.e., it depends on content height), and this element is not
>    # absolutely positioned, the value computes to 'auto'.
>
> An undefined corner case for which I am asking the spec to define is
> whether calc(0*100% + 1em) is the same as calc(1em), and I already did
> the testing for browsers supporting calc(): No, calc(0*100% + 1em) is
> treated as 'auto'.

Hi Kenny,
I think it's a fair point that css3-values clarify say whether percentages
can be simplified away. We've added

   # Where percentages are not resolved at computed value, they are not
   # resolved in ‘calc()’ expressions, e.g. ‘height: calc(100% - 100% + 1em)’
   # computes to ‘height: calc(0% + 1em)’, not to ‘height: calc(1em)’, and,
   # due to containing a percentage relative to the height of a containing
   # block that depends on this element's height, is treated as ‘auto’. [CSS21]

Let us know if this addresses your comment.

~fantasai

Received on Wednesday, 11 July 2012 20:45:51 UTC