Re: Transitioning top and bottom properties.

On 01/06/2011 20:42, Alan Gresley wrote:
> On 1/06/2011 10:28 PM, Øyvind Stenhaug wrote:
>> On Tue, 31 May 2011 19:46:45 +0200, Alan Gresley <alan@css-class.com>
>> wrote:
>>> http://css-class.com/test/css/3/transitions/offset-auto-ltr.htm
>>> http://css-class.com/test/css/3/transitions/offset-auto-rtl.htm
>>>
>>> Note that Opera 11.11 does it all wrong since the absolutely
>>> positioned element (on the left with salmon background) stops the
>>> margin collapse of the first inflow element (div#move with "Hover
>>> Me"). To prove this, select margin-top: 200px.

>> The margins between body and #move seem to collapse fine here. The
>> salmon div gets positioned further up, though. I don't see why it should
>> be affected by the margin on #move.
>
> I agree.
>
>> I suppose the others (IE8, Fx
>> nightly, Chrome dev) are making an inaccurate "guess at its probable
>> position", which the spec allows...
>
> Øyvind, can you please define to me what an inaccurate guess is? I do
> think that using the words inaccurate and guess together in the same
> sentence is quite amusing.
>
> Yes, 10.6.4 of CSS2.1.
>
> http://www.w3.org/TR/2011/PR-CSS2-20110412/visudet.html#abs-non-replaced-height
>
> | But rather than actually calculating the dimensions
> | of that hypothetical box, user agents are free to
> | make a _guess at its probable position_.
>
> This all reminds me of another bug [1] in IE7 when browsers are allowed
> to guess the probable position of 'auto' since the specs allows it. The
> test case associated with this 'auto' offset was what I used in 2008 on
> this list [2] when this behavior became defined in the spec. Look at
> what Alex writes (see [2]) in the message I replied to:
>
> # This passage in the spec is actually one of my
> # favorites. "free to make a guess" is a great
> # way to define things!
>
>
> Also in 10.6.4.
>
> | For the purposes of this section and the next, the
> | term "static position" (of an element) refers,
> | _roughly_, to the position an element would have had
> | in the normal flow.
>
> The errata of CSS2.1 should remove the word roughly since guessing
> wasn't really the best idea. Cont. 10.6.4.
>
> | More precisely, the static position for 'top' is the
> | distance from the top edge of the containing block
> | to the top margin edge of a hypothetical box that
> | would have been the first box of the element if its
> | specified 'position' value had been 'static' and its
> | specified 'float' had been 'none' and its specified
> | 'clear' had been 'none'.
>
> Note the word _containing block_. Now take this markup and CSS.
>
> <div id="float" style="float: left">
> <div id="ap">Absolute</div>
> </div>
>
> Since the parent of the absolutely positioned element is a float (a
> property that establishes a BFC), then it's containing block is the
> float.

No the containing block is established by the nearest ancestor with a 
'position' of 'absolute', 'relative' or 'fixed' as described in CSS21 10.1.

> Opera ignores this completely since it will always absolutely
> positioned an element with respect to border-box of the <body> element
> regardless of if there is _margin collapse or not_

Opera would be correct if 'top' were non-auto, since 10.1 goes on to 
say, "If there is no such ancestor, the containing block is the initial 
containing block".  [However, it's not quite the border box of body 
that's being used.  Nor does it make sense to say:

> if the root element
> is the 'initial containing block'.

Rather, the relationship between the root element and the initial 
containing block is that the initial containing block is the "containing 
block in which the root element lives" ("lives" is another bit of CSS21 
goodness ;-).  This has the dimensions of the viewport for continuous 
media.]

When 'top' is auto, as in your example above, then the guess at the 
static position comes into play.  Obviously, the static position "ought" 
to relate to the parent float's location.

> Here is a test.
>
> http://css-class.com/test/bugs/opera/calculated-offset-bug.htm
>
> Note the position of the top edge of the absolutely positioned element
> when you hover (also think of transitions and animation) the box with
> the word "Hover Me". All other browser correctly places the AP element
> at the bottom the box with the green border and overlaps the
> border-bottom (beginning at the top edge if this border).
>
> Opera positions the top edge of the AP element by the height of the
> margin-top of the AP element which is margin-top: 3em.

Yes, Opera's guess is not ideal.  Looks like it's doing the calculations 
before taking margin collapsing of body into account.  Other browsers 
guess better in this situation.

> I have have said, there is nothing special with auto offsets and this
> itself need to be mentioned in the errata for CSS 2.1. Especially 9.3.1
> and 9.3.2.

What, specifically, do you want to put in the Errata?  I doubt it's 
practical to remove the "guess".

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 3 July 2011 10:42:56 UTC