Re: Transitioning top and bottom properties.

On 08/07/2011 11:40, Alan Gresley wrote:
> 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.

I'm afraid I still don't understand the relevance of these paragraphs! 
The fact that the float establishes a BFC appears to be neither here nor 
there.  And it's not clear to me that the abspos's parent (be it floated 
or otherwise) is relevant to Opera's bad guess at static position; 
rather, as I stated before, I think it might be due in some way to 
margin collapsing calculations.


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

Indeed, the repeated movement is unequivocally a bug.  But this list 
isn't the place to discuss such things.  Browser bugs, of curiosity 
though they are, should be filed with the browser manufacturer.


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

I'll have to take your word for it.  I haven't looked at the test case 
in any great detail.  You should file this bug with Opera.

(Note that it would be helpful if you would document (either in the test 
case rendering or preferably when you post them to the list) what your 
test cases actually do!  It took me a few moments to figure out that you 
had the rule
body:hover {margin-top:100px}
in your stylesheet.)


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

Yes, I am.  I would be more than happy to see that word removed but, as 
I said, you'll have to convince the browser manufacturers first.  I'd 
rather permit a guess than mandate a calculation that some manufacturers 
will refuse to perform.


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

Sorry, I didn't express myself very clearly, and you misunderstood me. I 
was actually asking you to provide a description of the behaviour that 
you observe, so that that behaviour could be verified by others and the 
description be considered as a replacement for the "free to make a 
guess" phrase.  (Personally I don't think it's worth your while, but if 
you wish the CSS21 Errata to remove the "guess" then you do need to 
explain what you want it replaced with.  Should you decide to provide a 
description, I suggest that it must "stand by itself" and not be of the 
form "look at such-and-such a test case.)


>> 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.
>
> Actually Opera is alone with this. I consider something taking four
> steps more expensive then something taking taking three steps.

I really cannot comment on the reasons behind Opera's behaviour.  (And 
in general, expense is not measured in terms of number of steps.)

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

Received on Monday, 11 July 2011 19:29:16 UTC