User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:126.96.36.199) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:188.8.131.52) Gecko/2008120122 Firefox/3.0.5
The absolute positioned html button element (<button>, <input type="button">, etc.) does not adjustand its width when its css style specified both left and right.
Steps to Reproduce:
<html><body><button type="button" style="display: block; position: absolute; left: 0; right: 0; top: 0; bottom: 0">Click Me!</button></body></html>
The width of the button does not extend to the page's width.
The button should fills the entire client area of the page;
Firefox 3.0.5 on Windows (XP SP2) have this bug; but Firefox 2.x on Linux (SUSE 10.x) does not.
I'm getting conflicting results in other browsers on this one. Chromium 0.5.x has the button covering the entire content, while Opera 10a1 has the same width as Firefox 3.x
This is something from Bug 300030.
input[type="button"] is a replaced element. It has an intrinsic width/height.
The same problem happens with input[type="submit"].
For both, Opera10a differs from Gecko as it does NOT stretch the button, not horizontally, not vertically.
WebKit is partly wrong, as it stretches those 2 horizontally, but not vertically.
See CSS 2.1:10.3.8 ('right' should be ignored if the document is LTR), Opera and Gecko are correct.
Vertically, see CSS2.1:10.6.5
Gecko is wrong for input[type="button"] and input[type="submit"]. 'bottom' should be ignored (as happens for textarea or input[type="text"], see e.g bug 385870). (WebKit and Opera are correct)
For <button> I'm not sure. I think it should have the same behaviour as the other buttons.
I was sure we had a bug for buttons along the lines of what I fixed in bug 385870. In any case, resummarizing for the real issue here, so that dupe-finding can happen better.
I think we should consider buttons as having no intrinsic width/height, otherwise there is no way to make it adaptively size according to its parent (ie. behave like in a real window).
As to textarea, it has intrinsic width/height if its "cols"/"rows" are specified, otherwise not; same for <input type="text">.
> I think we should consider buttons as having no intrinsic width/height,
I doubt you really want that, since in that case the CSS spec would require them to be 300px wide and 150px tall. Assuming they're replaced elements, of course. There's a case to be made for buttons not being replaced elements, but that affects their interaction with a whole bunch of things (including floats, text-decoration, etc), not just the sizing. We have bugs with discussion on that too, as I recall.
> I doubt you really want that, since in that case the CSS spec would require
> them to be 300px wide and 150px tall.
> If we stick to CSS, is there anyway to get the window control like bahavior of
> "anchoring" both the left and right
Yes, for non-replaced elements...
> Yes, for non-replaced elements...
But the problem is that I think it is reasonable to consider button / text input / textarea as replaced elements, since they are OS GUI controls, not something the browser generates internally.
Here comes the problem: now we have these elements that appear like (and in essence, are) standard window controls, but they can't be anchored like standard window controls. In fact, part of their layout feature is totally gone, due to the CSS specs.
It is very counterintuitive, at least from a native application programmer's point of view...
Oh, if you're talking UI implementation, CSS is just a poor fit at the moment. What you really want is the flexbox model (similar to what XUL uses).
>CSS is just a poor fit at the moment.
No offense, but I'm pretty certain I have heard the same thing five years ago while trying to do something else... how many years will there be before the new CSS standard become widely implemented (and all browsers agree with the presentation)?
Meanwhile, how about provide some kind of override mechanism to get back the button/textarea/textinput anchoring, so to make basic UI implementations a lot easier?
I mean, the big brilliant point of *cascading* is that "things should behave as they were until said otherwise". Brushing useful features like these right out of the picture just doesn't make sense...
It's not a matter of implementation. The standard is designed for document layout. You're using it for user interface layout. It's the wrong tool for the job.
If that's an issue, please bring that up with the CSS working group (though note that they've been trying to work on the flexbox model for years now and are blocked on lack of someone competent to design it who has time to do so).
> It's not a matter of implementation. The standard is designed for document
layout. You're using it for user interface layout. It's the wrong tool for
Haha, it is exactly the same thing I heard five years ago, I swear! :D
In this case? Use a positioned div with left/right and a button with width:100% inside it.
Hmm, it worked. :D
I am pretty certain that in the past, using the width: 100% and/or height: 100% will defnitely push the border outside of the container. Maybe it is because now button is correctly rendered as replaced element, and its css width and height includes its entire content including borders?
That behavior would depend on the box model being used. For Gecko, you can use "-moz-box-sizing: border-box" (which is the default for buttons) to make sure to get that behavior.
Marking WORKSFORME based on comments 13 - 15 having both a way to do this (now in the URL) and no desire to change the standard for the need.
Er... except the bug about height (the only reason I left this open; see summary) is still there.
Created attachment 373794 [details]
testcase from url