Re: [css3-flexbox] min-width/height: auto, its Computed Value line, and "computes to" prose

On 21/05/2012 07:33, fantasai wrote:
> On 05/19/2012 03:44 PM, Tab Atkins Jr. wrote:
>> On Sat, May 19, 2012 at 11:45 AM, L. David Baron<dbaron@dbaron.org>
>> wrote:
>>> http://dev.w3.org/csswg/css3-flexbox/#min-size-auto says:
>>> # New Computed Value: the percentage as specified or the
>>> # absolute length or a keyword
>>> where the "or a keyword" is an addition relative to
>>> http://www.w3.org/TR/CSS21/visudet.html#min-max-widths .
>>>
>>> I think the "New Computed Value" line is correct, the 'auto' keyword
>>> should always be the computed value, and the second quoted piece of
>>> prose should be changed to avoid the term "computes".
>
> The concern here was backwards-compatibility, and there are two
> options for how this could behave:
> - auto always computes to auto
> - auto computes to 0 where needed for back-compat,
> currently blocks and tables
>
> There wasn't very much discussion on which option we should take,
> other than you suggesting to have it compute to 0 for now on
> tables and maybe decide later whether it could compute to ''auto'',
> or to ''min-content''. We took the option that was resolved in the
> minutes, which computes it to ''0''. But if it's not needed for
> back-compat, then it could certainly compute to ''auto''.
>
>>> This would avoid implementation complexity and the need to update
>>> http://wiki.csswg.org/spec/property-dependencies to reflect this
>>> additional dependency.
>
> I think we need to have a discussion on what the intention of
> computed values are, because originally they were the used
> value, and then, because that was hard to implement, they were
> degraded to "the value as far as you can compute without doing
> layout", and now you're arguing they should just be the specified
> value with variant syntaxes equated.
>
>> What effect would this have on Block Layout margin-collapsing, which
>> assigns special meaning to a min-height other than 0?
>
> If that's the concern, we can always clarify that ''auto'' is
> equivalent to ''0'' on blocks, even in the case of margin
> collapsing. It's not a blocker on what we decide to do here.

AFAICT the only normative part of CSS21 that would be affected by this 
new value 'auto' is the following line in 8.3.1:

   # Two margins are adjoining if and only if:
   # [omitted conditions]
   # * both belong to vertically-adjacent box edges, i.e. form one of
   #   the following pairs:
   #   [omitted pairs]
   #   * top and bottom margins of a box that does not establish a new
   #     block formatting context and that has zero computed
   #     'min-height', zero or 'auto' computed 'height', and no in-flow
   #     children

(although two items in the non-normative Note in the same section would 
also be affected).

Note, in particular, that nothing in 10.7 ('min-height' and 
'max-height') would be affected, thanks to the fortuitous wording of the 
algorithm which describes how the two properties influence the used 
value of 'height'.  (Non-integral values play no part.)

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 21 May 2012 09:08:27 UTC