According to Bug 984869 – display: flex
doesn’t work for button elements,
<button>
is not implementable (by browsers) in pure CSS, so they are a
bit of a black box, from the perspective of CSS. This means that they
don’t necessarily react in the same way that e.g. a<div>
would.This isn’t specific to flexbox — e.g. we don’t render scrollbars if
you putoverflow:scroll
on a button, and we don’t render it as a
table if you putdisplay:table
on it.Stepping back even further, this isn’t specific to
<button>
. Consider
<fieldset>
andwhich also have special rendering behavior:<table>
data:text/html,<fieldset style="display:flex"><div>abc</div><div>def</div>
In these cases, Chrome agrees with us and disregards the
flex
display mode. (as revealed by the fact that “abc” and “def” end up
being stacked vertically). The fact that they happen to do what you’re
expecting on<button style="display:flex">
is likely just due to an
implementation detail.In Gecko’s button implementation, we hardcode
<button>
(and
<fieldset>
,and) as having a specific frame class (and hence,<table>
a specific way of laying out the child elements), regardless of the
display
property.If you want to reliably have the children reliably arranged in a
particular layout mode in a cross-browser fashion, your best bet is to
use a wrapper-div inside the button, just as you would need to inside
ofaa<table>
or<fieldset>
.
Therefore, that bug was marked as “resolved invalid”.
There is also Bug 1047590 – display: flex;
doesn’t work in <fieldset>
, currently “unconfirmed”.
Good news: Firefox 46+ implements Flexbox for <fieldset>
. See bug 1230207.