Closed Bug 949476 Opened 11 years ago Closed 11 years ago

CSS display property flex does not work on fieldset element

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1230207

People

(Reporter: simon, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">
.flexbox {
	display: flex;
	flex-direction: row;
}
</style>
</head>

<body>
<form>

<fieldset class="flexbox">
<div>no flex :-(</div>
<div>no flex :-(</div>
</fieldset>

<div class="flexbox">
<div>yay flex :-)</div>
<div>yay flex :-)</div>
</div>
</form>
</body>
</html>


Actual results:

Using the CSS display property on the fieldset element does not layout the children as flex-items.


Expected results:

Children of both elements with class flexible should align next to each other. There should be no difference between div.flexbox and fieldset.flexbox.
Works in IE11, but not in Chrome 31
Summary: CSS display property flex does work on fieldset element → CSS display property flex does not work on fieldset element
Quoting bz's response to the same question but for <fieldset> failing to honor "display:table-cell" (the same basic issue):
> Basically, the default rendering of fieldset can't actually be expressed in CSS.
> As a result, browsers have to implement it in non-CSS terms, and that interferes
> with application of CSS to the element.
>
> Pretty much any element that can't be recreated using pure CSS will have issues of that sort.
Source: http://stackoverflow.com/questions/9203561/fieldset-does-not-support-display-table-table-cell

You'll notice that e.g. <iframe style="display:flex"> and <img src="foo.png" style="display:flex"> will similarly refuse to render as a flex container (at least in Firefox, and probably in other browsers too).
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Component: Untriaged → Layout
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 25 Branch → Trunk
If this is not a bug, then you should update the documentation on MDN. According to the specs https://developer.mozilla.org/en-US/docs/Web/CSS/display it should work an all elements.

- and it does work in IE11.
(In reply to Simon Speich from comment #2)
> If this is not a bug, then you should update the documentation on MDN.
> According to the specs
> https://developer.mozilla.org/en-US/docs/Web/CSS/display it should work an
> all elements.

That "Applies to: all elements" is just copypasted directly from the CSS21 spec:
 http://www.w3.org/TR/CSS21/visuren.html#display-prop

Moreover, per the definitions at the beginning of the CSS21 spec, "not applying" means "have no rendering effect on some types of elements" (e.g. like "flex-grow" on non-flex-items).

That's not the case for "display" on a fieldset -- <fieldset style="display: inline"> definitely renders differently from <fieldset style="display:block">.   That's not because we actually render it *as* a block; rather, it's because it affects whether it's treated as block-level or inline-level.  So there is *some* rendering effect.

So it wouldn't quite be correct to say that display doesn't apply to <fieldset>.

> - and it does work in IE11.

That's interesting. Does it still honor <legend> etc?  And does IE11 honor display:flex on e.g. <textarea>?
I decided to answer my own question and reboot in windows to try IE11.

It looks like treats <fieldset style="display:flex"> the same as <div style="display:flex"> -- i.e. it drops all of the fieldsettiness. (aside from the border, which presumably just comes from a rule in the UA stylesheet)

That's just an implementation detail from the way they implement <fieldset>. "display:flex" does *not* work for other special elements like <textarea> and <iframe>, as shown lower down in this testcase.
Thanks for the clarification.

> That's interesting. Does it still honor <legend> etc?  And does IE11 honor
> display:flex on e.g. <textarea>?

How would I test that? Isn't textarea supposed not to have any child elements?

But having textarea as flex-items works even in FF
<style type="text/css">
.flexbox {
	display: flex;
	flex-direction: column; /* and for row */
}
</style>
<div class="flexbox">
<textarea></textarea>
<textarea></textarea>
</div>
(In reply to Simon Speich from comment #5)
> How would I test that?

I did already; see attachment.

> Isn't textarea supposed not to have any child
> elements?

I don't know offhand, but that makes sense, and is special <textarea>-specific behavior.

Similarly, <fieldset> has its own specific behavior, which includes rendering like a fieldset. :)

> But having textarea as flex-items works even in FF

Yes, but that's unrelated. We're talking about what happens when you style a special element like <fieldset> or <textarea> *as* a flex container.
The following might explain the fundamental problem a bit better.

So let's lay out some intuitive strawman expectations (which I imagine might match your expectations when you filed this bug):
 <fieldset> renders like a fieldset
 <fieldset style="display: block"> renders like a block
 <fieldset style="display: table"> renders like a flex container
 <fieldset style="display: flex"> renders like a flex container

i.e. let's say the last 3 all should render like the equivalent <div style="...">

BUT, it can't work that way, because even in the case with no explicit style, <fieldset> *does* have a computed value for "display" (since every element has a computed value for every property).  The computed value happens to be "block", in Firefox at least, since <fieldset> traditionally renders as a block-level element.  In order for it to still render like a fieldset when it's unstyled, we can't let that default computed value change its rendering away from being a fieldset. (though we do let it determine whether it's block-level vs. inline-level)

Looking at it from a different angle: supposing you had a rule that assigned "display:flex" to a fieldset, and you wanted to override that with a more specific rule; what "display" value would you use to do that?  There is no "display:fieldset", so it's unclear what display value would be correct, in a theoretical browser that honored the strawman assumptions laid out above.

Anyway -- with regards to IE -- I don't know what they do or why, since I can't inspect their source code.  From some brief testing, it looks like they preserve fieldset rendering behavior (offsetting the <legend> into the border, at least) *specifically* when a fieldset has display:block, inline, and inline-block (so they fail the <fieldset style="display: block">-renders-like-a-block strawman expectation that I laid out at the beginning of this comment).  They abandon the fieldset rendering behavior for other display values like "table" and "flex". And then they do something different for other elements like e.g. <textarea>, as shown by my attached testcase.  So, I don't think they're particularly consistent or worth mimicking here.
>  <fieldset style="display: table"> renders like a flex container

Sorry, of course I meant "renders like a table" there :) copypaste failure.
Chrome seems to consider the similar issue a bug/regression: https://code.google.com/p/chromium/issues/detail?id=375693#c6

Shouldn't this bug be reviewed and probably reopened with the modern approach to 'display' definition (with separate values for display-inside and display-outside, special value for just creating BFC, as <fieldset> does by default, etc.)? I believe that the possibility to make the <fieldset> the flex container is very useful, and if both Chrome and IE/Edge will have it, it wouldn't be good for Firefox to be the only browser that doesn't allow it.
<fieldset> not being flexible poses another problem. If you want to make your form flexible (which is very helpful) then you're kind of forced to use <section> instead of <fieldset>, which is semantically wrong, or replace it with a <div>.
We ended up implementing this after all, over on bug 1230207 (and the attached testcase passes in current Nightly).

Duping forward to that bug.
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: