Re: Transitioning top and bottom properties.

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.

Further investigation now indicates worst is happening.


> 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. 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_ if the root element 
is the 'initial containing block'.


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.

Since the border is 10px in height I have included an image of 10px in 
height that repeats along the x axis. Now select one of the margin-top 
options of the <body>. This repeating image move downwards since we have 
moved the background tiling downwards but it is always just above the 
top edge of the AP element in Opera with top: auto.

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.



[1] http://css-class.com/test/bugs/ie/calculated-offset-bug2.htm

[2] http://lists.w3.org/Archives/Public/www-style/2008Jun/0054.html



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Wednesday, 1 June 2011 18:43:01 UTC