Re: Transitioning top and bottom properties.

On 3/07/2011 8:41 PM, Anton Prowse wrote:
> 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.


So what becomes of 9.4.1 [1]? I only went to 10.6.4 since 9.4.1 does 
mention the static position.

   | Floats, absolutely positioned elements, block containers
   | (such as inline-blocks, table-cells, and table-captions)
   | that are not block boxes, and block boxes with 'overflow'
   | other than 'visible' (except when that value has been
   | propagated to the viewport) establish new block formatting
   | contexts for their contents.

   | In a block formatting context, boxes are laid out one
   | after the other, vertically, beginning at the top of a
   | containing block.


Remember that no offset value has be declared so the position should be 
calculated from the hypothetical position of a static block.


>> 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:


This 'initial containing block' only arises if the positioned box has an 
offset value that in not auto.


>> 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.]


The root element does not live in an 'initial containing block' since 
the root element can overflow the viewport. For continuous media, the 
'initial containing block' is formed by the border-box of the viewport 
in respect to positioned elements who offset values are not auto.


> 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.


Agree.


>> 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.


Guessing is no way for anything to be defined. Guessing is why we are 
here today and guessing will make defining CSS behavior harder in the 
future.


>> 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


I want the errata to define the behavior that is already happening in 
three implementations.

I do have a follow up for Øyvind but I have been pulled in many 
directions (no pun intended).


[1] 
http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#block-formatting



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

Received on Sunday, 3 July 2011 12:18:21 UTC