Re: [CSS21] rule on % height in auto-height container should apply to used value, not computed value

On Monday 2011-10-24 23:39 -0700, Tab Atkins Jr. wrote:
> On Mon, Oct 24, 2011 at 9:21 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > http://www.w3.org/TR/CSS21/visudet.html#propdef-height says, in the
> > definition of <percentage>:
> >  # 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'.
> >
> > I believe this statement (and the corresponding bit of the "Computed
> > value" line) should be updated to reflect that this change happens
> > at the *used value* level but not at the *computed value* level.  I
> > think it is part of the principle of the computed vs. used value
> > distinction that computed values of properties should not depend on
> > the identity of or properties of the element's containing block,
> > though I don't know if this principle was previously stated.  Thus,
> > I think it should have been changed when we introduced the concept
> > of used value.
> >
> > (I'd note that the prose for max-height and min-height is different,
> > but should probably be the same, once this is corrected.)
> >
> > A testcase is attached.  Gecko and WebKit agree with my
> > interpretation; Opera does not.
> 
> I thought the only principle separating computed from used was that
> computed values were what you get when you resolve it as far as
> possible without actually doing layout; used values require layout
> data to resolve.

They don't require actually doing layout, but it does impose
significant constraints on implementation modularity.  I think this
is the only thing in the entire specification that requires a
computed value to depend on containing block rules.  It thus
constrains implementations to implement the concept of containing
block in terms of style data rather than in terms of the rendering
tree, which is a significant constraint on implementation modularity
(and doesn't happen to be how it's implemented in Gecko).

If there were a good reason for authors to want this behavior, I'd
be willing to do that, but as far as I can tell things are likely to
make more sense to authors if the computed value isn't changed by
the containing block structure.  (Frankly, though, I've never seen
authors care either way, which suggests that we ought to do
whatever's easier to implement.)

> Is the containing block of an element something that requires layout
> to resolve?  I don't *think* it is.  Thus, it should be okay to have a
> computed value depend on it.

I don't think "should be okay" is sufficient to significantly
constrain implementation modularity and require significant
rewriting in existing implementations.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Tuesday, 25 October 2011 16:00:30 UTC