Last Comment Bug 471763 - Abs pos buttons with top/bottom set and auto height don't use intrinsic height
: Abs pos buttons with top/bottom set and auto height don't use intrinsic height
Status: NEW
: css2
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
data:text/html;charset=utf-8,<!DOCTYP...
Depends on:
Blocks: reflow-refactor
  Show dependency treegraph
 
Reported: 2009-01-01 04:07 PST by Adam_5Wu
Modified: 2011-03-28 05:08 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase from url (796 bytes, text/html)
2009-04-20 22:37 PDT, Kevin Brosnan
no flags Details

Description Adam_5Wu 2009-01-01 04:07:34 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.5) 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.

Reproducible: Always

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>
Actual Results:  
The width of the button does not extend to the page's width.

Expected Results:  
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.
Comment 1 Mardeg 2009-01-01 04:28:12 PST
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
Comment 2 Ria Klaassen (not reading all bugmail) 2009-01-01 05:08:38 PST
This is something from Bug 300030.
Comment 3 philippe (part-time) 2009-01-01 06:05:31 PST
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.
http://www.w3.org/TR/CSS21/visudet.html#abs-replaced-width

Vertically, see CSS2.1:10.6.5
http://www.w3.org/TR/CSS21/visudet.html#abs-replaced-height

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.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-01 11:34:40 PST
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.
Comment 5 Adam_5Wu 2009-01-01 11:57:21 PST
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">.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-01 12:11:21 PST
> 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.
Comment 7 Adam_5Wu 2009-01-01 13:08:35 PST
> I doubt you really want that, since in that case the CSS spec would require
> them to be 300px wide and 150px tall.

Hmm, it seems to be a dead corner for the CSS specs then. If we stick to CSS, is there anyway to get the window control like bahavior of "anchoring" both the left and right (other than playing javascript voodoo magic :D)?
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-01 16:09:52 PST
> 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...
Comment 9 Adam_5Wu 2009-01-01 16:30:24 PST
> 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...
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-01 19:38:58 PST
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).
Comment 11 Adam_5Wu 2009-01-02 11:25:42 PST
>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...
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-02 12:15:37 PST
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).
Comment 13 Adam_5Wu 2009-01-03 06:44:36 PST
> 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.

Haha, it is exactly the same thing I heard five years ago, I swear! :D

And yes, by the ideal of "standard", I totally agree with you (and I don't mean to change the standard for the need here). But the problem is that CSS aside, there is practically nothing else (I know of) to use. Even JavaScript is a long shot (capturing document viewport resize and recalculate? Sounds really flaky...). Any suggestions how to get the job done elegantly?
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-04 08:33:36 PST
In this case?  Use a positioned div with left/right and a button with width:100% inside it.
Comment 15 Adam_5Wu 2009-01-04 12:34:49 PST
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?
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-04 15:07:46 PST
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.
Comment 17 Mardeg 2009-01-08 15:07:33 PST
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.
Comment 18 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-01-08 15:10:13 PST
Er... except the bug about height (the only reason I left this open; see summary) is still there.
Comment 19 Kevin Brosnan 2009-04-20 22:37:57 PDT
Created attachment 373794 [details]
testcase from url

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