- From: L. David Baron <dbaron@dbaron.org>
- Date: Sun, 22 Nov 2009 14:11:51 -0800
- To: www-style@w3.org
After seeing another set of complaints about how percentage heights don't do what authors want in CSS, I had an idea about how they could have worked better. Right now, the problem is that if the container has 'height:auto', percentage heights act just like 'height:auto'. A simple alternative that some browsers have done at various times (and sometimes only in quirks mode) is finding the closest ancestor that doesn't have 'height:auto', but that also has problems if anything in between has padding, border, or margin. Here's an alternative that I think would work significantly better in that case (and would also define concepts that would be useful for a whole bunch of other things, as Alex Mogilevsky and I were discussing in a side discussion at the last face-to-face meeting and perhaps others earlier). Define the <dfn>input (width/height)</dfn> of an element as the larger of: + the element's containing block's min-(width/height), or '0' if it is 'fit-content', 'min-content', or 'max-content' + the smaller of: + the element's containing block's max-(width/height), or infinity if it is 'none', 'fit-content', 'min-content', or 'max-content' + either: + if the element's containing block has a (width/height) that is not 'auto', 'fit-content', 'min-content', or 'max-content' the used value of the containing block's (width/height) + otherwise, the element's containing block's input (width/height) minus the containing block's (horizontal/vertical) padding, border, and (accounting for collapsing margins) margin plus, if the element is absolutely positioned, its containing block's (horizontal/vertical) padding. (I'm not sure that's the best handling of 'fit-content', 'min-content', and 'max-content'; it might be better not to have exceptions for them. The 'fill' value is fine, though.) Then, define percentage widths and heights as relative to the input width/height. These definitions of input width and input height are intended to have two interesting properties: (1) they're symmetric and don't depend on the block progression direction (i.e., whether we're doing block layout for vertical text) at all (except for whether margins collapse, though perhaps they shouldn't depend on that either) (2) the input width is the same as the containing block width in CSS 2.1 (i.e., without vertical text, 'fit-content', 'min-content', or 'max-content'), although I probably made some mistakes in the definition However, I think these definitions would also be useful for providing reasonable defaults when switching block progression direction (i.e., switching into or out of vertical text layout), and likewise for column layouts that are intended to fit in a fixed or maximum height and scroll horizontally, and likewise for providing useful size defaults at some other boundaries of new layout systems being introduced into CSS (e.g., flexible box layout, template layout). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Sunday, 22 November 2009 22:12:29 UTC