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

RESOLVED DUPLICATE of bug 984869

Status

()

Core
Layout
RESOLVED DUPLICATE of bug 984869
3 years ago
2 years ago

People

(Reporter: Oriol, Unassigned)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8625387 [details]
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.

Updated

3 years ago
Component: General → Layout
Keywords: testcase
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 984869
(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. :)
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.
(Reporter)

Comment 4

2 years ago
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.
Created attachment 8625750 [details]
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.
You need to log in before you can comment on or make changes to this bug.