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

RE: [CSS2.1] Interop Issue in regards to fixed/absolute positioned children inside of inline-relative containers

From: Gérard Talbot <www-style@gtalbot.org>
Date: Mon, 28 Jul 2014 12:32:16 -0400
To: Greg Whitworth <gwhit@microsoft.com>
Cc: Alan Gresley <alan@css-class.com>, Pavel Curtis <pavelc@microsoft.com>, W3C www-style mailing list <www-style@w3.org>
Message-ID: <a1494b890c4b04920a4b76725e7fb031@gtalbot.org>
Le 2014-07-27 21:34, Greg Whitworth a écrit :
> Sorry for the delayed response.
> 


http://fiddle.jshell.net/eUV76/1/show/light/


> Starting off, let's focus on the blue square, we can then discuss the
> green square once we reach agreement on the blue. Gerard had a great
> question in regards to my confusion of Chrome moving the blue square:
> 
>> The containing block of an element is defined as follows:
> # (...)
> #     If the element has 'position: absolute', the containing block is
> #established by the nearest ancestor with a 'position' of 'absolute',
> #'relative' or 'fixed', in the following way:
> #         In the case that the ancestor is an inline element, the
> #containing block is *_the bounding box around the padding boxes of the
> #first and the last inline boxes_* generated for that element.
> #"
> #§10.1 10.1 Definition of "containing block"
> #http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
> #
> #The "that element" means, is, refers to the (nearest positioned) 
> inline
> #ancestor.
>> 
>> What am I missing? Where am I wrong? ... just asking..
> 
> I agree that it is the containing block, but 10.3.7 in the process for
> determining the position of the absolutely placed box states the
> following:
> 
>     # 2.'left' and 'right' are 'auto' and 'width' is not 'auto',
>     # then if the 'direction' property of the element establishing
>     # the static-position containing block is 'ltr' set 'left'
>     # to the static position, otherwise set 'right' to the static 
> position.
>     # Then solve for 'left' (if 'direction is 'rtl') or 'right' (if
> 'direction' is 'ltr').
> 
> Since the box has a width and the left/right are auto the position of
> the blue box should be in the same position as when they are static
> boxes.
> 
> Please let me know if you have any thoughts on the above, thank you.

Okay. Things are clear in my mind now.

So, in

http://fiddle.jshell.net/eUV76/1/show/light/

the middle gray rectangle (auto offsets and relative) should display 
identically to the topmost gray rectangle (static). Chrome 36 appears to 
have a bug here.

And in Boris' example

http://fiddle.jshell.net/eUV76/4/show/light/

the top gray rectangle (abs. pos. children with auto offsets inside rel. 
pos. inline with non-auto offsets) should be displayed identically to 
the bottom gray rectangle (static pos. children inside rel. pos. inline 
with non-auto offsets). Firefox 31 appears to have a bug here.

> 
> Greg

Those are rather complex tests, complex code situations, scenarios. For 
several reasons, these tests would need to be broken into smaller tests 
before submitting them to CSS2.1 test suite.

Then, static cases could and should be used as reference file.

Since the expected results are known (static cases), then I believe we 
do not absolutely need to resort to Ahem font... but it would not be a 
mistake to resort to Ahem font.

Gérard

> 
> P.S.I have not filed any bugs against any UA as I felt it best to come
> to an agreement before proceeding
Received on Monday, 28 July 2014 16:32:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC