14

So, I'm using display: table-cell to put two buttons next to each other so that if text from one overflows to the next line, both buttons are the same height. I have border-collapse: separate and am using border-spacing to put space between them. It works just fine if I'm using something like <div class="button">, but as soon as I use the <button> element, the middle space disappears.
JSFiddle: http://jsfiddle.net/uASbb/

Now, using the <div> is fine for now (if not semantically as accurate), so I'm mostly just curious if anyone knows what exactly is going on here.
Note: I've also noticed some (different) weird behavior with using <input> elements in this same situation: http://jsfiddle.net/G5SFX/1/

Is display: table-cell just not supported in these instances? Is this a bug?

Thanks!

EDIT: It seems like you just can't apply a display: table-cell to a button; it just defaults back to inline-block. See this screenshot from Chrome WebInspector:
table-cell -> inline-block

Now the questions remain: Is this intentional? Is it the specification or is it just the browser? Can we get it changed?

gsroth
  • 151
  • 1
  • 6
  • 1
    Interesting... And it wouldn't be necessary to have `width:50%`, but with the buttons it doesn't work either. Comparison: http://jsfiddle.net/uASbb/1/ – Oriol Sep 13 '12 at 21:18
  • i dont know its is bug or not for tag "button", but if see in firebug`s "DOM" we gets next : for tag "button" offsetLeft = 0 , for tag "div" offsetLeft = 15... – voodoo417 Sep 13 '12 at 22:02
  • Not quite a solution, but something to consider is nesting a div or span inside the button. – Taylor D. Edmiston Sep 15 '12 at 17:17
  • Yeah, what I ended up doing was having an outer `
    ` to take care of the spacing and an inner `
     – gsroth Sep 17 '12 at 16:25
  • It works well when using Opera 12 (but not in Chromium of Firefox), so I guess this is some kind of browser bug. But on the other hand – do you really need to format the buttons as table-cells? What about floats or `display: inline-block;`? – feeela Sep 26 '12 at 10:26
  • The idea behind formatting them as table-cells was that they would all auto-expand together if the text in one became too long to be on one line. That way you avoid having an awkward button that's larger than the others. – gsroth Oct 22 '12 at 07:52
  • I consider it a bug, but probably in the spec more now than browser implementations (which kind-of previously defined the spec anyway). `button` is a 'replaced element' which means normal rules don't apply - see https://stackoverflow.com/a/38779191/2511031 and that thread. – Jake Nov 26 '21 at 00:53

1 Answers1

2

Inserting the button element into a div is a good solution (in your place I would have choose it, too), but if you want to display both button elements side by side with space in between without the help from a div you can try this for your .item class:

.item {
    display: table-cell;
    width: 46%;
    background: aliceBlue;
    border: 1px solid black;
    margin: 1%;
}

Width is reduced to 46% to allow a margin of 1% around every button element. You have a space between them now, and also if you resize the window the second button element won't fall under the first one.

Example: http://jsfiddle.net/codenighter/H7TZU/

Hope it helps.

EDIT: It seems that border-spacing (in fact none of block styling is working) doesn't work with button or input. But it does working with other inline elements like span, h1 or b. So, for input and button the display: table-cell property can't be properly applied (I've changed the width value for button and input and it showed, while for span and b the width remained actually at 50%).

Examples: http://jsfiddle.net/codenighter/HrTZS/

codenighter
  • 348
  • 1
  • 4
  • 11
  • The first example leaves me at least with a much larger space on the right-hand side. – gsroth Oct 22 '12 at 07:55
  • Adding extra layers of elements with well-defined classes to allow better styling is good practice in IMO, though it was a bit frowned upon back in 2012 (when the situation was much worse). Nowadays with so much usage of 3rd-party libraries it is essential for such to be flexible. Nothing worse than dealing with markup you can't modify (except for death and taxes). – Jake Nov 26 '21 at 00:59