128670 - If a container block's height is set through min-height its rendered height is not recognized by its decendents (treating their percentage (%) height as auto)

Status: RESOLVED INVALID

(Core :: Layout: Block and Inline, defect)

Description

[Jonathan Watt [:jwatt]]

When a containing block is set with a CSS property value pair of |height: 100%|,
then child elements with a height property assigned a percentage value use the
rendered height of the containing element as the reference for _their_ rendered
height. However, if the contianing block's height property is replaced with the
min-height property, then the child element acts as if it can't find a reference
height from the containing block even though the containing block's rendered
height remains the same as it was when the height property was used. 

I am attaching two testcases. These are exactly the same except that one
specifies a min-height property for the body element and the other specifies a
height property. 

The rendered height of a container element should be recognized when it is the
result of setting a value for min-height just as it is when set through a value
for height. 

I would guess the same problem exists for min-width too although I haven't
tested it.

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: testcase with body assigned height: 100%

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: testcase with body assigned min-height: 100%

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->Layout

Comment 4

[Christine Hoffman]

Changing QA contact

Comment 5

[Mikko Rantalainen]

Even though I hate the way Mozilla currently works, it seems to comply with the
spec: http://www.w3.org/TR/REC-CSS2/visudet.html#x14 says

<percentage>
Specifies a percentage for determining the computed value. 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), the percentage value is interpreted like 'auto'.**
(emphasis mine).

Height of an element without height (min-height isn't enough, height depends on
content height) property isn't explicitly defined and therefore its childs
should indeed treat min/max-height as auto. Spec also says min/max-height
doesn't apply to table elements - I hate that too.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, this is a bug, since the specified min-height influences the computed height.

Comment 7

[Boris Zbarsky [:bzbarsky]]

.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The problem is that min-height and max-height for blocks simply adjust the block
height (see nsBlockFrame::ComputeFinalSize) instead of changing its
mComputedHeight and reflowing....

Comment 9

[perlmonkee+moz-bugzilla]

Simply adding my vote to this, making things like "real" footers would suddenly
be a *lot* easier of this bug didn't exist.

Comment 10

[Gérard Talbot]

Hello,

I wish someone in this bugfile would confirm my hunch, my impression that bug 354504 is actually a duplicate of this bug 128670 here. Otherwise a consequence of bug 128670? Without a min-height set on containing block, testcase (attachment 240322 [details]) succeeds (get expected results). 

Thank you for your time.

Comment 11

[Gérard Talbot]

*** Bug 354504 has been marked as a duplicate of this bug. ***

Comment 12

[Raul Dias]

Just found this bug.
So, as this was already opened here are another test case:

http://www.dias.com.br/css/css_minheight_test.html

Interesting is that KHTML on Konqueror 3.4.2 and Opera 9.01 on Linux have the same bug.

Comment 13

[perlmonkee+moz-bugzilla]

I'm not sure the latest modification to the summary was strictly necessary, as this bug does not only pertain to PARENT elements who's min-height has been specified in terms of percentages, but any unit of measurement.  CHILD elements that are being assigned a height of x% (or their own min-height) are simply unaware of their parents actual computed height, and as such have their heights computed relative to the lowest level parent with a fixed height (or the view port, whichever comes first).  ...so I'm not really sure what you're talking about "auto" for.  ...but hey, I could be misunderstanding something.

Comment 14

[Boris Zbarsky [:bzbarsky]]

For what it's worth, looks like our current behavior is what the CSS spec calls for (which is why Opera and Konqueror have it too).  See thread at <http://lists.w3.org/Archives/Public/www-style/2006Oct/0046.html>.

So this should probably be resolved as invalid, if David agrees.

Comment 15

[Hixie (not reading bugmail)]

Yeah this is invalid now. Computed values aren't ever affected by layout, and min-height doesn't count as specifying the height (it's just a constraint on the final rendering).

Comment 16

[Raul Dias]

So, what is the point in having a min/max-height (or width)?

Comment 17

[Boris Zbarsky [:bzbarsky]]

To change the height.  But it doesn't affect heights of children with percentage heights.

Note that for width the situation is different, as usual, unless you're doing shrink-wrapping.

Comment 18

[Jonathan Watt [:jwatt]]

I think this is a poor resolution. I think this is a case where the letter of the spec is coming before common sense and what's useful for users.

Comment 19

[Raul Dias]

2 points to consider:

1 - What is the usefullness of having min/max-height without passing it to
    the children?  Can someone show a situation where this is usefull 
    (forgetting about what the spec says)

2 - Not forgeting what the spec says.  It can have different interpretations 
    about this issue:

      **If the height of the containing block is not specified explicitly 
        (i.e., it depends on content height), the percentage value is
        interpreted like 'auto'.**

2A - when specifing min/max-height the height is being explicit specified to 
     be inside the give range.  With this interpretation, the children height
     would not fallback to 'auto'.

2B - in the spec -> not specified explicitly == depends on content height.
     So in this case:
     <div style="height:1000px;">
        <div style="min-height: 80%">
          <div style="min-height: 50%>
             bla bla
          </div>
        </div>
      </div>

      In this case, the first div have 1000px, the second one 800px and the 
      third one right now would have 'auto', but should have 400px as the 800px
      from the second div did not depended on its CONTENT HEIGHT.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #18)
> I think this is a poor resolution. I think this is a case where the letter of
> the spec is coming before common sense and what's useful for users.

I disagree.

We don't want to make it easy for authors to create a situation where a percentage height works if the font is small but then breaks if the font is slightly bigger because the text became large enough to fill past the min-height.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Never mind that we can't even distinguish those two situations until after we're done laying out the element.)

Comment 22

[Boris Zbarsky [:bzbarsky]]

> It can have different interpretations about this issue

Did you even read comment 14 and 15?  The CSS working group has unambiguosly stated what the spec means in this case.  Read the email thread.

> but should have 400px as the 800px
> from the second div did not depended on its CONTENT HEIGHT.

It did, actually.  The 800px only happens if the content height is less than 800px.  So it very much depends on the content height.

> What is the usefullness of having min/max-height without passing it to
> the children? 

1) Being able to do something like this with an image:

  img { width: 100px; max-height: 200px }

to handle cases when you want images to be a certain width and scale the height with the width unless the height gets too big.

2)  Having a div take up some sort of minimal space no matter what its children are (this is pretty commonly used).

That's off the top of my head in 30 seconds.

Comment 23

[perlmonkee+moz-bugzilla]

(In reply to comment #20)
> (In reply to comment #18)
> > I think this is a poor resolution. I think this is a case where the letter of
> > the spec is coming before common sense and what's useful for users.
> 
> I disagree.
> 
> We don't want to make it easy for authors to create a situation where a
> percentage height works if the font is small but then breaks if the font is
> slightly bigger because the text became large enough to fill past the
> min-height.
> 

I believe what you are saying is only relevant to max-height, correct? (Just want to be clear)  If thats correct, then the same is true of simply specifying "height", and I don't understand what point you're trying to make.   If you're somehow trying to apply what you're saying to "min-height" - then I can't see how your statement is correct... we're specifying a MINIMUM height, if it's not enough, we re-flow with "auto" - how is this "breaking"? How is this not logically what it seems "min-height" should mean?

Don't get me wrong, I have yet to read the spec for myself, if the current behavior is to the letter of the spec, then this debate is better suited to a w3c discussion group.

Comment 24

[Boris Zbarsky [:bzbarsky]]

> I believe what you are saying is only relevant to max-height, correct?

No, it's relevant to min-height.

> Don't get me wrong, I have yet to read the spec for myself

Yeah.  Most of comment 23 shows that you don't understand the problem dbaron is talking about.

> this debate is better suited to a w3c discussion group.

That's already happened.  See comment 14.

One more note: the publicly available spec version is not as clear on this as the current CSS WG internal draft.  People should really look at that once it's published.