Margin collapsing and auto 'top' for abs pos (was Re: Transitioning top and bottom properties.)

On 12/07/2011 5:28 AM, Anton Prowse wrote:
> 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:

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


It is relevant since Opera is using the border of the BFC parent in it's 
calculations. This why is the abspos box is sitting at 85px from the top 
edge of the viewport instead of 75px. The 75px is the margin of the 
<body> before margin collapse and the 10px is from the width of the 
border of the float. If the float also has padding, then this is also 
used by Opera in calculating the abspos box' auto offset. So the reason 
I look at 9.4.1 is that a BFC has something called a content box.


   | Float, ..... establish new block formatting contexts
   | for their _contents_.


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


I have been planning to send Øyvind a _email offlist_, with some 
testcases in reply to this message.

http://lists.w3.org/Archives/Public/www-style/2011Jun/0088.html

It was your questioning that put it back onlist with the incorrect 
subject title that has nothing to do with transitioning from values of 
pixel, percentage, etc. to auto.


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


And this is what I plan to do.


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


The test case with the bug has nothing to do if an effect that happens 
after you hover something. The test case clearly shows that the abspos 
box is not positioned as one (an author) would expect.


>> 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 don't have to convince the browser manufacturers of anything. Please 
stop mandating that I do anything. What you think manufacturers will do 
is your assumption only.


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


This follow up was going to be offlist.


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


To right. I though you were saying that I can not bring a test case to 
this list.


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


What is this?

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


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


And that is what I'm was planning to do. END OF THREAD.


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

Received on Wednesday, 13 July 2011 07:52:32 UTC