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

(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'.

It's fine to postponed this to css3-box. It's just not necessary. It
doesn't require more investigation.

(Who knows when we will advance css3-box again...)

>> 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.
> 
> That paragraph is different - it's allowing table layout to
> *completely* ignore calc() with percentages, even in situations where
> plain percentages would be allowed and reasonable, because of the
> weird way that table layout propagates some child constraints back
> upwards (such as "width:25%" td forcing the table to be at least 4x
> the cell's min-width).
> 
> It's unrelated to the general behavior surrounding percentages and
> indefinite lengths that you're referring to.

It's fair say to this paragraph belongs to css3-box too, but I am not
suggesting punting this paragraph out of css3-values, I am on the
contrary asking the spec to add more normative sentences to specs that
are being maintained.


Cheers,
Kenny

Received on Tuesday, 10 July 2012 00:38:19 UTC