1186177 - height:100% on element inside a table-cell ends up behaving like "auto", if the table-cell has height:auto

Status: UNCONFIRMED

(Core :: Layout: Tables, defect)

Description

[František Nesveda]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36

Steps to reproduce:

I created a HTML page containing elements and styles as described in http://jsfiddle.net/fnesveda/rxsLvxpa/.


Actual results:

The height of the element with the ID "content" is not derived from the height of the containing table cell, but rather the height is just the height of the contents of the element.


Expected results:

The element with the ID "content" should have filled the whole height of the containing table cell, as specified in the CSS style.

Comment 1

[William Lachance (:wlach)]

I can verify that on Chrome works how the reporter expects it to, whereas on Firefox I reproduce the same behavior on Nightly. I'm not sure if this is expected, a duplicate of another bug or a new issue: suspect :dholbert would though.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Per spec, the height of that element is 100% of auto, so auto.  So the Firefox behavior is correct as far as the CSS specification is concerned, as far as I can tell.  We have had occasional bug reports about this in the past...

Comment 3

[Daniel Holbert [:dholbert]]

Yeah, the problem here is that the containing block of .content -- its <td> -- has "height: auto". So .content's 100% height ends up resolving against that, which produces auto.

If you give that .td "height:100%" as well, then things work as the author expected:
  https://jsfiddle.net/rxsLvxpa/6/

CSS 2.1 says that sizing is undefined when a percent value is resolved against a length that depends on that percent-value (as is the case here), so technically any behavior is allowed by the spec.

For comparison, Edge and IE11 both match Chrome here, while Opera 12.16 (Presto) matches Firefox. So we're not quite the odd one out in our interpretation, though we basically are given that Opera has switched to Blink nowadays. So, might be worth changing our behavior here.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> CSS 2.1 says that sizing is undefined when a percent value is resolved against a length
> that depends on that percent-value 

That's not relevant here.  The relevant part is http://www.w3.org/TR/CSS21/visudet.html#the-height-property which says:

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

So the spec pretty clearly says the computed height of the kid is "auto" in this case...

Comment 5

[Daniel Holbert [:dholbert]]

Ah, sorry -- you're right. (I was remembering some different spec-text that's actually about % values in vertical margin/padding, which says "If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1." http://www.w3.org/TR/CSS21/box.html#propdef-padding-top . I'd thought there was similar text for CSS 'height', but nope.)

So, based on the comment 4 spec-quote, it sounds like we're matching the spec here & Chrome/IE/Edge are not - yup.

Comment 6

[Gérard Talbot]

Daniel, Boris,

Can we resolve this bug report as INVALID please? 

Then I will resolve bug 1417495 as a DUPLICATE of this bug report. And I will file a bug report at chromium project. Okay?

Comment 7

[Boris Zbarsky [:bzbarsky]]

You should file a bug on Chromium not following the CSS spec no matter what we do here.

The question is whether we might need to match their behavior...

Comment 8

[Gérard Talbot]

I intend to file a bug on Chromium.



Issue 603507: Display:table height issue
https://bugs.chromium.org/p/chromium/issues/detail?id=603507
https://bugs.chromium.org/p/chromium/issues/detail?id=603507#c37
states:

"Treat percent-height div inside auto-height cells as auto"

They mention this test

http://jsfiddle.net/pCx89/4/

which Chromium 62 fails and Firefox 52.5 passes.

Also:

https://jsfiddle.net/zc21pg9q/1/

coming from their issue 603835; Chromium 62 and Firefox 52.5 differ in their rendering.

Comment 9

[Gérard Talbot]

"
Anonymous block boxes are ignored when resolving percentage values that would refer to it: the closest non-anonymous ancestor box is used instead.
"
9.2.1.1 Anonymous block boxes
https://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level
https://www.w3.org/TR/CSS22/visuren.html#anonymous-block-level

Anonymous block box is not the same as anonymous table object in the text of the spec. 

This is probably what Chrome developers initially did (Chrome 49 and below). Then, in Chrome 50, they corrected the bug, but then people started complaining that such fix was breaking a popular CSS technique (aka the "holy grail" layout) for rendering a fixed growable header above a scrollable area and so they reverted back.

Comment 10

[Gérard Talbot]

> You should file a bug on Chromium 

Done:

Issue 786309: Height of block with percentage unit inside an auto-height cell box
https://bugs.chromium.org/p/chromium/issues/detail?id=786309

Comment 11

[Ksenia Berezina [:ksenia]]

https://webcompat.com/issues/32605 is still reproducible, moved it to bug 1891612