1060131 - Buttons with width: 100% have an intrinsic min-width of 0 (end up too narrow or cut off in table cells, inline blocks)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Mark Otto]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2

Steps to reproduce:

A `button` with `width: 100%` within a table cell will not render correctly when available space is less than the space required to render the entire table's contents. Instead of maintaining the width of the button, it's contents are cropped and the width of the button knocked down to the sum of the horizontal padding.

See http://jsfiddle.net/qq465644390/73HeE/4/embedded/result/.

FWIW, https://bugzilla.mozilla.org/show_bug.cgi?id=332171 sounds super similar, but is 8 years old.


Actual results:

Button text is cropped.


Expected results:

Button text and horizontal padding should be preserved when horizontal space is limited.

Comment 1

[Chris Rebert]

(Original Bootstrap bug report: https://github.com/twbs/bootstrap/issues/14320 )

Comment 2

[Boris Zbarsky [:bzbarsky]]

Mark, is the behavior different than for a <div style="display: inline-block; width: 100%">?  If not, why were you expecting a different behavior for those two cases?

Comment 3

[Mark Otto]

Boris:

divs apparently don't behave the same with as a block level button. I expect the block level, 100% wide button to behave as a div, as it does in every other browser (in that the button's minimum required width is maintained).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Simpler testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

So I guess the issue here is that buttons are being treated as replaced elements, for which percentage sizing means an intrinsic width of 0 (try it with an <img> for an equivalent comparison).

We could try changing that, but I worry about web compat issues if we do...

Comment 6

[Chris Rebert]

I have filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28904 in the hopes of having the spec clarify whether or not <button> is/can-be/may-be a replaced element.

Comment 7

[Chris Rebert]

(In reply to Boris Zbarsky [:bz] from comment #5)
> So I guess the issue here is that buttons are being treated as replaced
> elements,

Hixie said in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23893#c0 that they are NOT replaced elements.

See also https://github.com/whatwg/html/issues/45

Comment 8

[Chris Rebert]

(In reply to Boris Zbarsky [:bz] from comment #4)
> Created attachment 8481618 [details]
> Simpler testcase

I checked this in Chrome, Safari, Edge, IE11, and Opera 12, and none of them make the button too narrow like Firefox does.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yes, I know all that.  The point is, some parts of button rendering _do_ act as if they were replaced elements in all browsers.  That's why hixie isn't sure how to spec it.  :(

Comment 10

[Patrick Westerhoff]

I was caught by this problem as well, see my question on Stack Overflow here: http://stackoverflow.com/q/34948628/216074. In my case I was able to fix this by using `min-width: 100%` instead of `width: 100%`.

This also seems to be related to bug 332171.

Comment 11

[Patrick Westerhoff]

A fix landed yesterday that fixed bug 332171, and from what I see in today’s Nightly build, this issue is now also resolved. So someone close this please :)