1176786 - Flexbox on a <button> blockifies the contents but doesn't establish a flex formatting context

Status: RESOLVED DUPLICATE of bug 984869

(Core :: Layout, defect)

Description

[Oriol Brufau [:Oriol]]

Attachment: Demo

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150622052959

Steps to reproduce:

Add display:flex or display:inline-flex to a <button> element.


Actual results:

The children of the <button> are blockified, as dictates the flexbox spec.
However, the <button> seems to establish a block formatting context instead of a flex one.


Expected results:

The button should establish a flex formatting context.

Comment 1

[Daniel Holbert [:dholbert]]

This is a dupe of bug 1176786.

(In reply to Oriol from comment #0)
> The children of the <button> are blockified, as dictates the flexbox spec.

Right; this happens purely in the style system, due to the flexbox spec's requirements on how the CSS "display" property influences the "display" property on the child element.

> However, the <button> seems to establish a block formatting context instead
> of a flex one.

That is effectively what the HTML spec requires. See bug 984869 comment 3.

Several HTML container-elements are "special" and effectively ignore their CSS "display" value in Gecko [aside from whether it's inline-level vs. block-level].  <button> is one of these. <fieldset> & <legend> are as well. (Chrome has the same behavior as we do on those, I think -- they disregard the "display" property. They implement <button> differently, though, it seems; as bz notes on the other bug, these elements' behavior & interactions with CSS are largely undefined.)

See discussion on bug 984869 for more info.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)
> This is a dupe of bug 1176786.

Sorry, I meant "dupe of bug 984869" of course. :)

Comment 3

[Daniel Holbert [:dholbert]]

See also second half of bug 984869 comment 15.

In any case: if you want a button to behave as a flex container, your best bet is to wrap its children in a div, and make *that div* a flex container.

Comment 4

[Oriol Brufau [:Oriol]]

OK. I already knew flexbox doesn't work with some elements like <fieldset>, but didn't realize the contents are blockified. I think that is weird.

If the HTML spec says
> When the button binding applies to a button element,
> the element is expected to render as an 'inline-block'
> box rendered as a button whose contents are the contents
> of the element.

Then it makes sense that <button>s don't establish a flex formatting context.

But their children shouldn't be blockified, because contents inside an 'inline-block' box are not blockified.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase w/ <fieldset>

(In reply to Oriol from comment #4)
> But their children shouldn't be blockified, because contents inside an
> 'inline-block' box are not blockified.

This process ("is my parent display:flex? OK, blockify my display") happens inside of the style system, which is mostly separate from where we know what types of boxes we're actually generating.

Also FWIW, note that Chrome does the same thing (blockifying the children despite the parent box not being a flex container) in <fieldset style="display:flex">.  See attached testcase.