Open Bug 471763 Opened 16 years ago Updated 2 years ago

Abs pos buttons with top/bottom set and auto height don't use intrinsic height

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

People

(Reporter: Adam_5Wu, Unassigned)

References

(
URL
)

Details

(Keywords: css2)

Attachments

(1 obsolete file) 

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.
Keywords: css2
Version: unspecified → 3.0 Branch
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.
Blocks: reflow-refactor
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 3.0 Branch → 1.9.0 Branch
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.
Component: Layout → Layout: Form Controls
QA Contact: layout → layout.form-controls
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.
OS: Windows XP → All
Hardware: x86 → All
Summary: html buttons incorrect css sizing (button, input buttons) → Abs pos buttons with top/bottom set and auto height don't use intrinsic height
Version: 1.9.0 Branch → Trunk
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.

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)?
> 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
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?
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.
URL: <!DOCTYPE HTML><html lang%3D"en"><hea... → <!DOCTYPE HTML><html lang%3D"en"><hea...
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Er... except the bug about height (the only reason I left this open; see summary) is still there.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 489284
Attached file testcase from url (obsolete) — 

    
  

        Attachment #373794 -
        Attachment is obsolete: true

    
  
No longer blocks: 489284

    
  
Severity: normal → S3

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: