Closed Bug 437722 Opened 13 years ago Closed 10 years ago
Relatively positioned buttons should be abs pos containing block
Component: Build Config → Layout: Form Controls
Product: Firefox → Core
By the way, I forgot to comment that you must set the "padding" of the button to "0px" in order to make that algorithm work. If not, you must change some of its values.
Yep. The issue is that we end up using the anonymous block inside the button as a containing block (because of the wacky reparenting into the insertion frame buttons do), and then centering it inside the button. Since it has no in-flow kids, its height is 0, and you get the resulting rendering. Really, we should be using the button itself as the containing block, but right now only inlines and blocks can be abs pos containing blocks...
Status: UNCONFIRMED → NEW
Depends on: 63895
Ever confirmed: true
Summary: Absolute CSS coordinates inside of BUTTON which has a relative position fail → Relatively positioned buttons should be abs pos containing block
I wouldn't wager on a timeframe here. This is a very longstanding problem that not all frames can be absolute containing blocks, and roc has been thinking about fixing it for a while. But I don't know when he or someone else will get to it. And yeah, you can't get at the anonymous block. It's actually just a CSS box; it doesn't even have an associated DOM element, really.
Ok, then I'll have to continue using to my "home-made" JS solution. As long as it works, I don't mind to use these tricks. Anyway I'll keep an eye on this thread to track any news. I also wanted to thank you all, the people who make the Mozilla products possible, for all the good job. All the things which you're making are astonishing.
I found a related issue. Absolute positioning inside a (relative positioned)<BUTTON> starts after the padding. Please see this URI for a demo: http://www.maisqi.com/abs-pos-with-padding. Seen from the outside it seems <BUTTON> is broken in Firefox. Hope you can fix it soon. Thanks.
(In reply to comment #5) > Ok, then I'll have to continue using to my "home-made" JS solution. As long as > it works, I don't mind to use these tricks. Anyway I'll keep an eye on this > thread to track any news. At least for me a usable workaround is to wrap a <button> in a 'position:relative;display:inline-block'-ed span and position the needed elements (they can be in the button) using the span boundaries. Beware that inline-blocks are not recognized in Fx before, I think, v3. An additional workaround for this is to use 'display:-moz-inline-block;display:inline-block' on the span as advised in various blog posts out there. Additional minor fixes must be applied to IE8. No JS, but conditional comments and you, probably, already use them anyway.
testcase from comment 0
testcase with text inside the button
(In reply to comment #10) > At least for me a usable workaround is to wrap a <button> in a > 'position:relative;display:inline-block'-ed span and position the needed > elements (they can be in the button) using the span boundaries. I also do this. I find that setting display:block; position:static; width:100%; height:100%; on the button element means that the button listens to the wrapping span/div box. With these additions to the button element you may find it easier to position the wrapping element as you wish. I found this neccessary in order to also position internal elements absolutely to the button (divs with image sprites etc). In effect it makes the button element invisible for positioning purposes - as it is just listening to the wrapping element.
This is still a problem in Firefox 5, see example http://jsfiddle.net/j6q2e/3/ Why is this taking so long to fix? All the other browsers figured this out ages ago.
The infrastructure for this has landed in bug 10209.
Both attached Testcases + the JSFiddle Example of Comment 16 render the same as WebKit 535.5 for me with Bug 10209 fixed. Sufficient to resolve?
(In reply to XtC4UaLL [:xtc4uall] from comment #18) > Both attached Testcases + the JSFiddle Example of Comment 16 render the same > as WebKit 535.5 for me with Bug 10209 fixed. Sufficient to resolve? It seems fixed indeed. Please reopen if I missed something.
Status: NEW → RESOLVED
Closed: 10 years ago
Depends on: 10209
Resolution: --- → FIXED
Whiteboard: [fixed by bug 10209]
Even though that this fixed, I really want to get some tests for this in the tree. Maybe tomorrow though...
Assignee: nobody → ehsan
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Ehsan Akhgari [:ehsan] from comment #20) > Even though that this fixed, I really want to get some tests for this in the > tree. Maybe tomorrow though... I might be pedantic, that is why 'in-testsuite: ?' was set. Technically, the bug is fixed. Though, I'm not going to complain if you want the bug to be open to write some tests :)
Attachment #565367 - Flags: review?(roc) → review+
Status: REOPENED → ASSIGNED
Flags: in-testsuite? → in-testsuite+
Target Milestone: --- → mozilla10
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.