[CSS21] CR-CSS21-20070719, 8.3.1 Collapsing in presence of min/max-height, small correction suggested

[Bruno Fassino]

In 8.3.1:

"The bottom margin of an in-flow block-level element with a 'height' of
'auto' and 'min-height' less than the element's used height and 'max-height'
greater than the element's used height is adjoining to its last in-flow
block-level child's bottom margin..."

I suggest the following small corrections:
- "less than" should be "less than or equal" (or "not greater than")
- "greater than" should be "greater than or equal" (or "not less than")

This would be more consistent with the rules at 10.7 and more logical:
roughly speaking when min-height is exactly equal to the element's used
height, then min-height is not really in effect, and all should be as in the
case of min-height less than the element's used height.

Firefox is the only browser that I know that stops that margins collapsing
when min/max-height is in effect, and it behaves according to the suggested
change.


Best regards,

Bruno Fassino

--
http://www.brunildo.org/test

[fantasai]

Bruno Fassino wrote:

> In 8.3.1:
>
> "The bottom margin of an in-flow block-level element with a 'height' of
> 'auto' and 'min-height' less than the element's used height and 'max-height'
> greater than the element's used height is adjoining to its last in-flow
> block-level child's bottom margin..."
>
> I suggest the following small corrections:
> - "less than" should be "less than or equal" (or "not greater than")
> - "greater than" should be "greater than or equal" (or "not less than")
>
> This would be more consistent with the rules at 10.7 and more logical:
> roughly speaking when min-height is exactly equal to the element's used
> height, then min-height is not really in effect, and all should be as in the
> case of min-height less than the element's used height.
>
> Firefox is the only browser that I know that stops that margins collapsing
> when min/max-height is in effect, and it behaves according to the suggested
> change.

Thanks for the comment. Recorded as issue 14:
   http://csswg.inkedblade.net/spec/css2.1#issue-14

~fantasai

[L. David Baron]

On Sunday 2007-10-14 21:28 +0200, Bruno Fassino wrote:
> "The bottom margin of an in-flow block-level element with a 'height' of
> 'auto' and 'min-height' less than the element's used height and 'max-height'
> greater than the element's used height is adjoining to its last in-flow
> block-level child's bottom margin..."
>
> I suggest the following small corrections:
> - "less than" should be "less than or equal" (or "not greater than")
> - "greater than" should be "greater than or equal" (or "not less than")

This change looks wrong.

The intent was that the conditions exclude cases where min-height or
max-height affects the used height.  If you change them to "or
equal" then those cases are also included, and the only height:auto
case that is excluded is the case where min-height > max-height.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Bruno Fassino]

L. David Baron wrote:

> On Sunday 2007-10-14 21:28 +0200, Bruno Fassino wrote:
> > "The bottom margin of an in-flow block-level element with a
> > 'height' of 'auto' and 'min-height' less than the element's
> > used height and 'max-height' greater than the element's used
> > height is adjoining to its last in-flow
> > block-level child's bottom margin..."
> >
> > I suggest the following small corrections:
> > - "less than" should be "less than or equal" (or "not
> > greater than")
> > - "greater than" should be "greater than or equal" (or "not
> > less than")
>
> This change looks wrong.
>
> The intent was that the conditions exclude cases where min-height or
> max-height affects the used height.

Yes, I agree on this. And I believe that cases when the min-height is
"equal" to the used height are cases when min-height is not affecting the
used height. So I believe that this case ("equal") should be added to the
mentioned case, which means:
 "min-height less than the element's used height"
becomes:
 "min-height less than or equal the element's used height"

In other words, the only cases to leave out are those when min-height is
strictly greater than the used height, because only in those cases
min-height is affecting the height, and collapsing is not wanted. Similarly
for max-height.


> If you change them to "or equal" then those cases are also included,
> and the only height:auto case that is excluded is the case where
> min-height > max-height.

I don't think so, all cases with:
 min-height > used_height  OR  max_height < used_height
will still be excluded (no collapsing).
The reverse of the above:
 min-height <= used_height  AND  max_height >= used_height
will be included (collapsing allowed).

The suggested change is really a small thing, maybe I wasn't clear in my
previous message.


Best regards,
Bruno

--
Bruno Fassino http://www.brunildo.org/test

[Bruno Fassino]

Bruno Fassino wrote:

> L. David Baron wrote:
>
> > The intent was that the conditions exclude cases where min-height or
> > max-height affects the used height.
>
>
> Yes, I agree on this. And I believe that cases when the
> min-height is "equal" to the used height are cases when
> min-height is not affecting the used height. So I believe
> that this case ("equal") should be added to the mentioned
> case, which means:
>  "min-height less than the element's used height"
> becomes:
>  "min-height less than or equal the element's used height"

I see now that the issue is caused by my incorrect reading of "used height",
since this is the height "after" min-height is applied, and so my suggested
change is indeed wrong.

But the current phrasing of the condition doesn't allow to distinguish the
case when the height "before" min-height is applied (the computed height?)
is equal to min-height. Is this the case that I wanted to add, since in this
case the min-height is not in effect, and it is currently excluded.


Best regards,
Bruno

--
Bruno Fassino http://www.brunildo.org/test

[L. David Baron]

On Monday 2007-10-15 08:03 +0200, Bruno Fassino wrote:
> In other words, the only cases to leave out are those when min-height is
> strictly greater than the used height, because only in those cases

min-height is never greater than the used height.  It's either less
than or equal.  (If it were greater, than we'd be violating the rule
that the used height is at least as large as the min-height.)

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Bruno Fassino]

David Baron wrote:

> min-height is never greater than the used height.  It's either less
> than or equal.  (If it were greater, than we'd be violating the rule
> that the used height is at least as large as the min-height.)

Yes, my formulation was wrong.
Still, an element may have 'used height' equal to 'min-height' not because
min-height is in effect, but because this is the height of its content (a
sort of borderline case, but well possible.) I would like to see this case
listed among the ones with collapsing allowed (Firefox behaves in this way.)

Ideally one should say "used height before min-height is applied" and
include the equality case.

Bruno

--
Bruno Fassino http://www.brunildo.org/test

[Bruno Fassino]

As David pointed out, my initial proposal was wrong. What about simply change:

"min-height less than the element's used height"

with:

"min-height not affecting the element's used height"  ?

This will allow margins collapsing in cases when the used height,
_before_ taking min-height into account, is exactly equal to
min-height.
Such cases are probably not much relevant. Apparently a trivial
example is a height:auto box containing an empty (or height:0) box.
The first box has used height 0, equal to its min-width=0. I think we
want to allow (bottom) margins collapsing here.

Bruno

--
Bruno Fassino http://www.brunildo.org/test

[L. David Baron]

On Friday 2007-10-19 22:22 +0200, Bruno Fassino wrote:

>
> As David pointed out, my initial proposal was wrong. What about simply change:
>
> "min-height less than the element's used height"
>
> with:
>
> "min-height not affecting the element's used height"  ?
>
> This will allow margins collapsing in cases when the used height,
> _before_ taking min-height into account, is exactly equal to
> min-height.
> Such cases are probably not much relevant. Apparently a trivial
> example is a height:auto box containing an empty (or height:0) box.
> The first box has used height 0, equal to its min-width=0. I think we
> want to allow (bottom) margins collapsing here.

I think what we want to do is replace:
  # The bottom margin of an in-flow block-level element with a
  # 'height' of 'auto' and 'min-height' less than the element's used
  # height and 'max-height' greater than the element's used height
  # is adjoining to its last in-flow block-level child's bottom
  # margin if the element has no bottom padding or border.

with:
  # The bottom margin of an in-flow block-level element is adjoining
  # to its last in-flow block-level child's bottom margin when:
  #   * the element's specified 'height' is 'auto',
  #   * the element's computed height is the same as it would have
  #     been if the specified value of 'min-height' were '0' and the
  #     specified value of 'max-height' were 'none', and
  #   * the element has no bottom padding or border.

This fixes the issue in this thread using the hypothetical, and also
fixes the issue (pointed out recently, I think) that the text should
say something about blocks where the height conditions do not match.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Bruno Fassino]

On Wed, Aug 20, 2008 at 12:36 PM, L. David Baron wrote:

>
> I think what we want to do is replace:
>  # The bottom margin of an in-flow block-level element with a
>  # 'height' of 'auto' and 'min-height' less than the element's used
>  # height and 'max-height' greater than the element's used height
>  # is adjoining to its last in-flow block-level child's bottom
>  # margin if the element has no bottom padding or border.
>
> with:
>  # The bottom margin of an in-flow block-level element is adjoining
>  # to its last in-flow block-level child's bottom margin when:
>  #   * the element's specified 'height' is 'auto',
>  #   * the element's computed height is the same as it would have
>  #     been if the specified value of 'min-height' were '0' and the
>  #     specified value of 'max-height' were 'none', and
>  #   * the element has no bottom padding or border.

In the second bullet did you mean:
  "the element's _used_ height is the same as..."  (_used_ in place of
_computed_)  ?

I'm always rather confused by these terms "computed", "used", but the
description at 7.3.1 states that
  "These steps do not affect the real computed values of the above properties"
which I assume to mean that min-/max-height never affects the
'computed' height, but may affect the used height.


Bruno

--
Bruno Fassino http://www.brunildo.org/test

[L. David Baron]

On Wednesday 2008-08-20 16:28 +0200, Bruno Fassino wrote:

>
> On Wed, Aug 20, 2008 at 12:36 PM, L. David Baron wrote:
> >
> > I think what we want to do is replace:
> >  # The bottom margin of an in-flow block-level element with a
> >  # 'height' of 'auto' and 'min-height' less than the element's used
> >  # height and 'max-height' greater than the element's used height
> >  # is adjoining to its last in-flow block-level child's bottom
> >  # margin if the element has no bottom padding or border.
> >
> > with:
> >  # The bottom margin of an in-flow block-level element is adjoining
> >  # to its last in-flow block-level child's bottom margin when:
> >  #   * the element's specified 'height' is 'auto',
> >  #   * the element's computed height is the same as it would have
> >  #     been if the specified value of 'min-height' were '0' and the
> >  #     specified value of 'max-height' were 'none', and
> >  #   * the element has no bottom padding or border.
>
>
> In the second bullet did you mean:
>   "the element's _used_ height is the same as..."  (_used_ in place of
> _computed_)  ?

Yes.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[fantasai]

L. David Baron wrote:

>
> I think what we want to do is replace:
>   # The bottom margin of an in-flow block-level element with a
>   # 'height' of 'auto' and 'min-height' less than the element's used
>   # height and 'max-height' greater than the element's used height
>   # is adjoining to its last in-flow block-level child's bottom
>   # margin if the element has no bottom padding or border.
>
> with:
>   # The bottom margin of an in-flow block-level element is adjoining
>   # to its last in-flow block-level child's bottom margin when:
>   #   * the element's specified 'height' is 'auto',
>   #   * the element's computed height is the same as it would have
>   #     been if the specified value of 'min-height' were '0' and the
>   #     specified value of 'max-height' were 'none', and
>   #   * the element has no bottom padding or border.
>
> This fixes the issue in this thread using the hypothetical, and also
> fixes the issue (pointed out recently, I think) that the text should
> say something about blocks where the height conditions do not match.

Couldn't that second bullet just say

    * the element's used height is the same as it would have been if
      'min-height' and 'max-height' had their initial values

?

~fantasai