Closed
Bug 799699
Opened 11 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)
Core
Layout
Tracking
()
RESOLVED
INVALID
People
(Reporter: dholbert, Unassigned)
References
Details
Attachments
(1 file)
635 bytes,
text/html
|
Details |
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.)
Reporter | ||
Comment 1•11 years ago
|
||
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)
Reporter | ||
Comment 2•10 years ago
|
||
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.
Description
•