W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: Transitioning top and bottom properties.

From: Alan Gresley <alan@css-class.com>
Date: Fri, 08 Jul 2011 19:40:16 +1000
Message-ID: <4E16D080.5040308@css-class.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: www-style list <www-style@w3.org>, Øyvind Stenhaug <oyvinds@opera.com>
On 3/07/2011 10:42 PM, Anton Prowse wrote:
> 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:

>>>> Also in 10.6.4.

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


The relevance is the hypothetical position of a static block. Opera uses 
the BFC of the float during the calculations of it's auto offset.


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


Please the below test in Opera and hover between the float and the 
second repeating image.

http://css-class.com/test/bugs/opera/calculated-offset-bug2.htm


Rarely have I created such test where I can make elements move. I should 
not be able to make Opera double guess since by doing so, I can 
continuously add to the AP element's calculated position.


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


Let me correct that. Calculations using the 'initial containing block' 
only arises if the positioned box has an offset value that in not auto.


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


My most recent test proves that Opera calculation (guess) is much later.

  1. Margin collapse happens.
  2. Float is positioned.
  3. AP is positioned in respect to a hypothetical static
     position.

(all other UAs stop here but Opera has one more step)


  4. Positions the AP in respect to the hypothetical
     un-collapsed border-box of the <body>.


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


Firefox, IE and WebKit are not guessing, they are calculating. What you 
are condoning is the use of the word guess in a W3C spec.


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


I don't see how. Does CSS have a testsuite for this very purpose?


> 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


Actually Opera is alone with this. I consider something taking four 
steps more expensive then something taking taking three steps.


-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/
Received on Friday, 8 July 2011 09:40:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT