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: Sat, 19 Jul 2014 13:41:17 -0400
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Alan Gresley <alan@css-class.com>, Pavel Curtis <pavelc@microsoft.com>, Greg Whitworth <gwhit@microsoft.com>, W3C www-style mailing list <www-style@w3.org>
Message-ID: <ad9271c19bbdc1e41c7c7b44dba02b6f@gtalbot.org>
Le 2014-07-15 15:12, Boris Zbarsky a écrit :
> On 7/14/14, 7:18 PM, Greg Whitworth wrote:
>> We have found an interop issue on how an inline-relative’s offset 
>> should
>> affect a fixed/absolute element.
> To be clear, this is about the case when the absolute/fixed element
> has auto offsets so what matter is the "static position" of CSS 2.1
> section 10.3.7, right?
>> Absolute Example: http://jsfiddle.net/eUV76/1/embedded/result/
> Let's focus on this one, since I agree that absolute and fixed
> position should be treated identically here.
> In particular, let's focus on the "relative with offset:" case.
> For the case it's interesting to look at what actually happens if the
> positions are set to static: http://fiddle.jshell.net/eUV76/4/show/
> I agree that it looks odd that Firefox is not vertically moving the
> green bit and not moving the blue bit at all.  That said, the vertical
> position of the green bit looks odd to me in IE as well, given where
> the static position is.
> The spec, of course says:
>   But rather than actually calculating the dimensions of that
>   hypothetical box, user agents are free to make a guess at its
>   probable position.
> -Boris

But rather than actually calculating the dimensions of that hypothetical 
box, user agents are free to make a guess at its probable position.
stated in both
§10.6.4 Absolutely positioned, non-replaced elements
§10.3.7 Absolutely positioned, non-replaced elements

There were reasons why the CSS2.1 spec was originally written with such 
latitude, leniency; if you change the spec now, then you have to 
consider those reasons (assuming they are still valid). One reason I see 
is margin collapsing: it is active when blocks are statically 
positioned, it is not active when blocks are positioned. I remember at 
least 1 test which was labelled as incorrect because of this:


Email discussion:

Shepherd file:


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. 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'.
§10.6.4 Absolutely positioned, non-replaced elements

The term "top edge of the containing block" is different (meaning that 
"top edge of containing block" refers to something different) if the 
parent is an inline instead of a block. (Am I wrong here with such 

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. In CSS 2.1, 
if the inline element is split across multiple lines, the containing 
block is undefined.
§10.1 Definition of "containing block"

Received on Saturday, 19 July 2014 17:41:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:42 UTC