Closed Bug 799699 Opened 12 years ago Closed 10 years ago

Percent-height elements *inside* an auto-height stretched flex item should be treated as auto-height

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: dholbert, Unassigned)

References

Details

Attachments

(1 file)

Attached file testcase 1
STR: Load testcase, in a profile with layout.css.flexbox.enabled = true

EXPECTED RESULTS: The region directly below the text "height: 100%" should be lime (like it is below "height:auto")

ACTUAL RESULTS: That region is yellow instead.

Chrome dev channel (Version 24.0.1284.2 dev) and opera-next (12.10 beta RC) both give EXPECTED RESULTS.

Note: The attachment is basically a simplified/clarified version of the testcase that Rudolph brought up in this www-style thread:
 http://lists.w3.org/Archives/Public/www-style/2012Oct/0204.html

(Incidentally, our rendering matches what he expects, but it's not correct.)
Morten basically outlines why our behavior is wrong here:
 http://lists.w3.org/Archives/Public/www-style/2012Oct/0205.html

> The height of the "item" elements are "indefinite" (a term used in the
> flexbox) spec, so the percentage height on the ["inner"] elements should
> compute to 'auto'.
>
> http://www.w3.org/TR/CSS2/visudet.html#the-height-property
>
>   "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'."


(NOTE: his post actually said <<the percentage height on the "item" elements>>, but he meant "inner" -- I corrected it above (and put my correction in square-braces) for clarity)
OS: Linux → All
Hardware: x86_64 → All
The spec has now changed, and I believe our behavior [which this bug originally considered "buggy"] matches what the spec now requires.

In particular, quoting this www-style post from fantasai...
 http://lists.w3.org/Archives/Public/www-style/2014Mar/0464.html
...:
>   - if the flex container is auto height, a stretched item is
>     considered definite after we have measured the contents of
>     the flex items treating any percentage-height children as
>     auto-height. This requires a relayout step, but it makes
>     height: 100% work as expected on auto-height flex containers.

In other words, the flex item with the "height: 100%" child is considered to have a definite height (which the 100% can resolve against) in its final reflow. So it's now correct that the "height: 100%" actually does resolve to 100%.

The actual spec change appears to have happened here:
> 11. Determine the used cross size of each flex item.
> [...]
> If the flex item has align-self: stretch, redo layout for its
> contents, treating this used size as its definite cross size
> so that percentage-sized children can be resolved.
http://dev.w3.org/csswg/css-flexbox/#algo-stretch

Hence, resolving as INVALID, since our behavior matches the [updated] spec.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: