- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 05 Jun 2009 18:00:41 -0500
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Anton Prowse <prowse@moonhenge.net>, "www-style@w3.org" <www-style@w3.org>
Oh, auto height. Yeah, we don't support that on purpose right now. Relative positioned objects can still affect layout in the case where overflow is auto, since scrollbars must appear to encompass that relative positioned content. The act of showing the scrollbars could end up affecting the position again such that you don't need scrollbars, etc. In general we try to avoid cyclic layout situations (which I thought was the point of typically having percentage values ignored when inside auto height containing blocks). Maybe people amended the spec with the belief that such a cyclic layout situation could not occur, but it most definitely can. dave (hyatt@apple.com) On Jun 5, 2009, at 5:36 PM, Brad Kemper wrote: > Was that recently, like within the last week? Because when I checked > with a recent Nightly, I could not get anything out of percentage > values on 'top', unless the parent had a set height. > > Sent from my iPhone > > On Jun 5, 2009, at 11:48 AM, David Hyatt <hyatt@apple.com> wrote: > >> This issue has already been fixed in WebKit. >> >> dave >> (hyatt@apple.com) >> >> On Jun 5, 2009, at 1:36 PM, Anton Prowse wrote: >> >>> Jorrit Vermeiren wrote: >>>> It looks like this behaviour is "just" a vestige of CSS2. That says >>>> the following about percentage values: "For 'top' and 'bottom', >>>> if the >>>> height of the containing block is not specified explicitly (i.e., >>>> it >>>> depends on content height), the percentage value is interpreted >>>> like >>>> 'auto'." [1] >>> >>> Indeed. >>> >>> My apologies to the list for not doing my research before posting; >>> this issue has already been raised before[1], and fantasai >>> responded saying,[2] >>> >>> > The spec was actually changed so that percentages for top/bottom >>> *do* >>> > work. Behavior in this case was previously explicitly undefined: >>> > http://www.w3.org/TR/CSS21/changes.html#q53 >>> > So that means at some point the browser implementors discussed >>> it and >>> > decided it should be possible. I guess it just hasn't been done >>> yet :) >>> >>> The corresponding bug in Gecko is [3], in which Boris Zbarsky does >>> indeed state[4] that the behaviour currently implemented in Gecko >>> is that specified in CSS2. >>> >>> [1] http://lists.w3.org/Archives/Public/www-style/2007Aug/0139.html >>> [2] http://lists.w3.org/Archives/Public/www-style/2007Aug/0152.html >>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=260348 >>> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=260348#c14 >>> >>> >>> Thanks, >>> Anton Prowse >>> http://dev.moonhenge.net >>> >> >> >
Received on Friday, 5 June 2009 23:01:21 UTC