How percentage heights could have worked (and maybe still could)

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