1047590 - `display: flex;` doesn't work in <fieldset>

Status: RESOLVED DUPLICATE of bug 1230207

(Core :: Layout, defect)

Description

[Tae]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

<fieldset style="display: flex; flex-direction: row;">
    <input type="radio"/><!-- They can be other elements, like labels -->
    <input type="radio"/>
</fieldset>


Actual results:

Radio buttons appear one above the other.


Expected results:

Radio buttons should appear side by side.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is fundamentally the same issue as bug 984869.  And as there, there's no actual spec for how <fieldset> should work.  :(

Daniel, how insane would it be to set up the fieldset's anonymous block as a display:flex when the fieldset itself has that display type?  We could probably do the same for buttons too...

Comment 2

[Daniel Holbert [:dholbert]]

That could probably work.

The most straightforward thing to do would be to make the fieldset's anonymous block inherit its "display" property (and blockify it, perhaps via ApplyStyleFixups, if there's no better place to do it).

We'd just need to be sure to forcibly inherit the flex-container-specific properties (flex-wrap, align-content, etc) to the anonymous block inside the fieldset / button.  We'd need to do the same for the grid properties and table properties, and those of any other container-type that we want to work on a <fieldset>/<button> (targeting its content area), too...

Comment 3

[Ilya]

The linked bug 984869 is incorrectly marked as "Resolved: Invalid". The WHATWG HTML doesn't say that `button` element can't have `display` values other than `inline-block`, it just says that the default display of the button in CSS-supporting browsers must be `inline-block`. It would be nice to fix both these bugs with one patch, since they look similar.

Comment 4

[jondallas]

Blink bug:
https://code.google.com/p/chromium/issues/detail?id=375693

WebKit bug:
https://bugs.webkit.org/show_bug.cgi?id=148826

This is fixed in EdgeHTML.