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

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
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height
and
§10.3.7 Absolutely positioned, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

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:

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/margin-collapse-012.htm

Email discussion:
http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0012.html

Shepherd file:
http://test.csswg.org/shepherd/testcase/margin-collapse-012/


------------

{
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
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height

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

"
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"
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

Gérard

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