Absolutely positioned inline-block (or inline) element with floating nextSibling and auto "left" is positioned to the right of the float
Categories
(Core :: Layout: Floats, defect)
Tracking
()
Webcompat Priority | P2 |
People
(Reporter: hvtorsekar, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webcompat])
Attachments
(4 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 Steps to reproduce: Isolated the classes 'btn' 'btn-success' to have a margin-left that pushes the div too far to the right when using 'position: relative;' for the button inside a div. Actual results: Specific issue happens only in Firefox and not Chrome, Safari, or Opera. Expected results: Margin-left should be the same as other browsers for the button element inside the div.
I'm not sure how to run a test case. I attempted to change my CSS to position the button in a fixed position using position: absolute. It seems that it only has issue with Firefox. If this isn't helpful to you, would you be able to give me an example of a testcase that might be useful for me to give you better information. I'll write a testcase, just not sure how to go about doing it for the purpose of illustrating a CSS positioning component. Relevant CSS classes that are acting on the same button : availabilitybutton { margin-top:0px; margin-left: 150px; font-size: 1.2em; z-index: 1; } .showavailabilitybutton { margin-top: 20px; position: absolute; }
Comment 3•10 years ago
|
||
(In reply to HVT from comment #2) > I'm not sure how to run a test case. Basically, it would help if you could provide a link to a webpage or jsbin/jsfiddle that shows the issue. Ideally a page that shows only that particular issue, ie with the minimal HTML and CSS required to reproduce the issue. Thank you!
www.rentsixmile.com/login hvt@me.com test1234 Go to the edit button and then the page will be the edit page. Please note the Availability Button is not centered as it is in other browsers.
Comment 5•10 years ago
|
||
(In reply to HVT from comment #4) > www.rentsixmile.com/login > > hvt@me.com > test1234 > > Go to the edit button and then the page will be the edit page. > > Please note the Availability Button is not centered as it is in other > browsers. Thanks! I've distilled it down to a small HTML file that also shows problematic positioning.
Comment 6•10 years ago
|
||
So this is clearly a core bug, moving there in a second. I'm not sure what's causing the problem (or even really what's happening). Some notes: - div.wrongplace is mispositioned - removing its next sibling (div.inner-container) fixes things (!?) - removing the CSS rule for the width of the outer container makes the text disappear entirely (doesn't happen in Chrome) - removing *any* of the remaining properties for the div.inner-container (float, width, height) or div.wrongplace (position, display) fixes things, too. It seems to me like the abs-pos'd element is not positioned on top of the float (inner-container), even though it's position: absolute. Instead, its position is dictated by the float. I don't know why. (I included #reference to have an idea where the text should end up)
Updated•10 years ago
|
Updated•10 years ago
|
Updated•10 years ago
|
Comment 8•10 years ago
|
||
So looking at the testcase.... div.wrongplace is absolutely positioned and is inline-level, but does not have "left" specified. So its left position is supposed to based on the hypothetical box (see <http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width>). What we do there is to use the position of the placeholder, which comes to the right of the float, because the float is 100% width and the placeholder is 0 width. If the float were only 50% width, say, our behavior would clearly be "correct"; compare the horizontal position of div.wrongplace in that situation with and without the "position: absolute". But if the float is wide enough it would get cleared past the element if it were statically positioned, which is the situation in the attached testcase, then the behavior looks odd. Unfortunately, the spec doesn't actually define a specific rendering in this case, which is why you're seeing differences between UAs. I'm a bit hesitant to make changes here without a plan, since it's pretty easy to produce different testcases (see the 50% example above) where our rendering is closer to what I think is desired than the other browsers' are... David, is there a principled way to figure out whether floats would have gotten cleared past us when determining the hypothetical box?
What does IE do?
Comment 10•10 years ago
|
||
On attachment 8408177 [details] it matches WebKit and Blink. Same on http://jsfiddle.net/SVs7Z/
(In reply to Boris Zbarsky [:bz] from comment #8) > David, is there a principled way to figure out whether floats would have > gotten cleared past us when determining the hypothetical box? This question requires a good bit of analysis. I'm going to leave this in my needinfo? queue, but I'm unlikely to get to it before mid-June, and probably not for a bit after that.
Comment 12•9 years ago
|
||
I also stumbled up on this today with the following code: http://jsbin.com/wakuse/4/
Comment 13•5 years ago
|
||
This just bit another site on https://webcompat.com/issues/22867
I've attached a reduced test-case in the off chance that it helps. (The text overlaps in Chrome, but not in Firefox).
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 15•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 16•2 years ago
|
||
So the WebKit / Blink behavior would be sorta reasonable if they were consistent and placed the zero-sized inline somehow at the beginning of the line, or cleared the float, but that's not happening... So I think Gecko's behavior is more correct, or at least self-consistent.
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:TYLin, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 18•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 5 See Also bugs.
:TYLin, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•6 days ago
|
Description
•