Last Comment Bug 489100 - absolutely positioned child of relative inline positioned relative to only first line of inline
: absolutely positioned child of relative inline positioned relative to only fi...
Status: NEW
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 543383 1133525 (view as bug list)
Depends on:
Blocks: css2.1-tests 743599 766530
  Show dependency treegraph
 
Reported: 2009-04-19 15:57 PDT by Richard Neill
Modified: 2015-12-06 07:50 PST (History)
13 users (show)
roc: blocking1.9.2-
roc: wanted1.9.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshots in Firefox/Konqui/Opera (5.43 KB, application/octet-stream)
2009-04-19 16:00 PDT, Richard Neill
no flags Details
testcase (378 bytes, text/html)
2009-04-20 10:58 PDT, Nochum Sossonko [:Natch]
no flags Details

Description Richard Neill 2009-04-19 15:57:08 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8) Gecko/2009033117 Mandriva/1.9.0.8-0.1mdv2009.0 (2009.0) Firefox/3.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8) Gecko/2009033117 Mandriva/1.9.0.8-0.1mdv2009.0 (2009.0) Firefox/3.0.8

The child element of an inline div is misplaced. It is actually positioned with respect to the top line of that div, rather than the bottom. Both Opera and Konqueror behave differently, so this is probably a genuine bug.

Reproducible: Always

Steps to Reproduce:
Look at the following HTML. (I'll attach screenshots shortly)


<h2>Firefox</h2>
BEFORE
	<div style="position:relative; display:inline; background-color:#0F0">
    		This is an inline div.<br>Here is the second line<br>And a third line<br>And now a fourth and final line
    		<div style="position:absolute; left: 0; bottom: 0; display:inline; background-color:#F00">
    			x
  		</div>
  	</div>
AFTER
Actual Results:  
The red 'x' is positioned at the TOP of the parent div. It should be placed at the bottom.

Both Firefox 3.5 and Firefox 3.6a1 (today's nightly) show the same behaviour. But Opera and Konqueror show different behaviour.

Expected Results:  
The inner div has "bottom: 0", therefore the bottom of the 'x' should be aligned with the bottom of the parent div.
Comment 1 Richard Neill 2009-04-19 16:00:26 PDT
Created attachment 373589 [details]
Screenshots in Firefox/Konqui/Opera

Here is a tarball of 3 png files, showing the rendering in Firefox, Konqueror (3.5) and Opera (9.64) respectively.

The HTML source of all of them is exactly the same (excepting that I changed the <h2> to show the correct name)
Comment 2 philippe (part-time) 2009-04-20 07:08:47 PDT
dupe of bug 5016, I think
Comment 3 Richard Neill 2009-04-20 09:46:09 PDT
I think you're probably right. 10 years, and half-a-million bugs later ;-)

Any chance of a fix? Web designers now tend to regard Firefox as the de-facto implementation of the standards, and test here first.

*** This bug has been marked as a duplicate of bug 5016 ***
Comment 4 Nochum Sossonko [:Natch] 2009-04-20 10:54:38 PDT
Reopening per bug 5016 comment 32.
Comment 5 Nochum Sossonko [:Natch] 2009-04-20 10:58:38 PDT
Created attachment 373682 [details]
testcase
Comment 6 Nochum Sossonko [:Natch] 2009-04-20 11:02:34 PDT
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090202 Minefield/3.2a1pre

Confirmed.
Comment 7 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2009-04-20 12:01:42 PDT
There is an explanation of what needs to be done to fix this starting from bug 5016 comment 17.
Comment 8 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-02-01 14:05:27 PST
*** Bug 543383 has been marked as a duplicate of this bug. ***
Comment 9 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2011-01-25 12:26:27 PST
We should also figure out what the spec says about bidi issues:  see http://lists.w3.org/Archives/Public/www-style/2011Jan/0538.html
Comment 10 Gérard Talbot 2013-10-06 13:02:45 PDT
Issue 215
Summary
    Make it undefined what containing block is formed by a relpos inline that splits across multiple lines
 URI
    http://test.csswg.org/suites/css2.1/20110111/html4/containing-block-032.htm
(which was removed from /latest/ and /nightly/ :
http://test.csswg.org/suites/css2.1/latest/html4/containing-block-032.htm
http://test.csswg.org/suites/css2.1/nightly/html4/containing-block-032.htm
)
Resolution
    Make undefined.
Status
    Closed.
http://wiki.csswg.org/spec/css2.1#issue-215

"
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_**. 
"
CSS2.1, §10.1 Definition of "containing block"
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

So, I'd say this bug is not valid for CSS 2.1.


CSS3 is a bit different:

"
If the element has ‘position: absolute’, the containing block is established by the nearest ancestor with a ‘position’ other than ‘static’, in the following way:

    In the case that the ancestor is inline-level, the containing block depends on the ‘direction’ property of the ancestor:
        If the ‘direction’ is ‘ltr’, the top and left of the containing block are the top and left content edges of the first box generated by the ancestor, and the bottom and right are the bottom and right content edges of the last box of the ancestor. 
"
CSS Positioned Layout Module Level 3, Working Draft 7 February 2012
§3.1. Definition of containing block
http://www.w3.org/TR/css3-positioning/#def-containing-blocks

as it now refers to content edges (and not padding edges) and it does not specify what happens if the positioned ancestor inline box is split in multiple line boxes.
Comment 11 matt 2014-10-14 09:45:51 PDT
Is there any push at all to implement this? It's inconsistent with all major browsers causing me quite a few headaches. It's been half a year since this was last discussed which is quite alarming.
Comment 12 tdmalone 2015-08-11 21:39:58 PDT
Still experiencing this bug, and can confirm it is still inconsistent with Chrome and IE implementation.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2015-12-06 07:50:57 PST
*** Bug 1133525 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.