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

Le 2014-07-16 20:56, Alan Gresley a écrit :
> 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

Indeed. An inline box with a 'display' value of 'inline-block' should 
*not* influence the baseline of text outside of it.

> but the above test case shows that this is what
> happening

Huh... I do not understand what you are saying. All I see is those tan 
"X" sitting on the baseline. The larger X does make the line box 
taller... which is okay.

And you probably meant "aligned" when you wrote "alighted" in that test.

Maybe this excerpt could be useful ...

"
The baseline of an 'inline-block' is the baseline of its *_last line 
box_* in the normal flow, unless it has either no in-flow line boxes or 
if its 'overflow' property has a computed value other than 'visible', in 
which case the baseline is the bottom margin edge.
"
http://www.w3.org/TR/CSS21/visudet.html#leading


> and it is interoperable across all browsers. It's happening
> because the box itself does not have a 'height' that is 'auto'.
> 

In your
http://css-class.com/test/temp/containing-block-inline4b.htm
the inline-block's height (painted tan) is set to 100px but the X glyph 
of the last line box should be sitting on the baseline. Alan, I'm 
sorry... I could be wrong... but I do not see the baseline influence 
problem you report...

I spent a lot of time carefully examining all the tests (Greg's, yours, 
Boris') provided so far.

Gérard

> 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 Saturday, 19 July 2014 19:03:00 UTC