Re: Transitioning top and bottom properties.

On 03/07/2011 14:17, Alan Gresley wrote:
> 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.

I don't understand the relevance of these paragraphs to this discussion.

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

Yes.  (A position which is free to be guessed at.)

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

?
The initial containing block always exists.  Various things in CSS21 are 
measured or positioned with respect to it.

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

Yes.  Hence my comment about the undesirability of the word "lives".  We 
all know what it's trying to say though.

> For continuous media, the
> 'initial containing block' is formed by the border-box of the viewport

There's no such thing as the "border box" of the viewport.  The spec 
expresses the relationship as "has the dimensions of the viewport", 
which seems reasonable.

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

Guessing is what we've got though, because it's expensive to calculate 
static position precisely.  I'm not condoning it; I'm merely explaining it.

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

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

A concise and specific description of that behaviour (without reference 
to any particular test case) would be useful.  If the behaviour is "many 
UAs calculate static position precisely instead of guessing" then, as 
I've said, this would be great but it's expensive and you'd have to get 
implementers on board.

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

Received on Sunday, 3 July 2011 12:43:52 UTC