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: Alan Gresley <alan@css-class.com>
Date: Thu, 17 Jul 2014 10:56:04 +1000
Message-ID: <53C71F24.5070003@css-class.com>
To: Greg Whitworth <gwhit@microsoft.com>, Pavel Curtis <pavelc@microsoft.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Gérard Talbot <www-style@gtalbot.org>
CC: "www-style@w3.org" <www-style@w3.org>
On 17/07/2014 6:15 AM, Greg Whitworth wrote:
> Sorry that should read "and" (see inline)

Greg and Pavel. The spec does not define what should happen with an 
empty inline box but the test case is showing some usual behaviour 
because such a empty inline box has been set to display-inline-box.

>>>> On 7/15/14, 6:25 PM, Pavel Curtis wrote:
>>>>> Note the tall orange inline block later on the line, which raises
>>>>> the height of the line box.  I think everybody uses the top of the
>>>>> line box as the vertical coordinate of the static position.

This orange box is showing the same as if it's a non-replaced element 
(an image) with a 'display' value of 'inline' [1] and it's bottom is 
aligned with the baseline of the line box [2]. Here is a test case.

http://css-class.com/test/temp/containing-block-inline4b.htm

There is nothing in the spec that says that an inline box with a 
'display' value of 'inline-block' should influence the baseline of text 
outside of it but the above test case shows that this is what happening 
and it is interoperable across all browsers. It's happening because the 
box itself does not have a 'height' that is 'auto'.

Before we work out where the "static position" of the green box is (see 
below), the above has to be resolved and spec'd.

>>>> Right; that seems obviously wrong per the current spec.  On the
>>>> other hand, given that there is interop on it, we should change the
>>>> spec
>>> accordingly.
>>> 	Pavel
>>
>> Same thing I was going to suggest  that the spec should read:
>>
>> 	# That when an element is set to absolute it should be placed at the
>> top/0 of the line box if top or bottom is set to auto. It should be placed in the
>> same place it would have been in the flow if left or right is set to auto.

This is not precisely correct. We are dealing with a containing block 
and not a line box. If an element is set to absolute, it should be 
positioned as though the box is static. This is what Boris meant by the 
following:

   > Yes, but its "same position" should be between
   > the "inside1" and "inside2" text (and in
   > particular vertically aligned with them).
   > I assume all implementations are taking some
   > sort of shortcut here that ends up with them
   > mispositioning it....

Please see section 10.4.7 [4] which has as follows:

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

As is seen in the test case 'containing-block-inline4.htm' [5] all 
browsers are mispositioning the green box. The top edge of the 
containing block is what is indicated by the inline that has a 
top-border coloured salmon. This is why I did another test case 
'containing-block-inline3.htm' [6] that is positioning the green box 
correctly but we running into another issue.

This is all happening because there is an *empty* inline box with a 
'display' value of 'inline-block' that has a height that is *not* 'auto' 
and which is not spec'd.

> 	# That when an element is set to absolute it should be placed at the top/0 of the line box if top _and_ bottom is set to auto. It should be placed in the same place it would have been in the flow if left _and_ right is set to auto.
>
>> On the other two issues I will open bugs against Blink and Mozilla accordingly.
>>
>> Thanks,
>> Greg

Greg. Can you provide the link to the bugs against Blink and Mozilla.


1. http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#inline-boxes
2. 
http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#inline-formatting
3. 
http://www.w3.org/TR/2011/REC-CSS2-20110607/visudet.html#abs-non-replaced-width
4. 
http://www.w3.org/TR/2011/REC-CSS2-20110607/visudet.html#abs-non-replaced-height
5. http://css-class.com/test/temp/containing-block-inline4.htm
6. http://css-class.com/test/temp/containing-block-inline4.htm


Alan
Received on Thursday, 17 July 2014 00:56:38 UTC

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