Proposal: allow display: contents to do away with legacy fieldset/legend rendering

[emilbjorklund]

If a style declaration of display: contents is applied to a fieldset element, it should ditch all the legacy behavior in terms of rendering, and (I'm assuming) just show the legend as an inline element per default, allowing authors to control the layout and rendering fully by using CSS (by using another wrapper, rather than styling the fieldset element directly).

The old/odd behavior of fieldset and legend has, in my experience, prevented loads of people from using them over the years, potentially making the web less accessible in the process. I think the addition of display: contents in CSS is an excellent opportunity to ditch the old behavior for newer sites, without breaking backwards compatibility.

I've opened the same issue against the WHATWG spec here: whatwg/html#2805

Blog post here: https://thatemil.com/blog/2017/07/01/fixing-fieldsets/

[LJWatson]

Thanks for this proposal @emilbjorklund.

The guidance in the Rendering section of the spec is informative (meaning it just provides guidance for browsers on how to render different elements). It would be possible to update the rendering guidance for <fieldset> and/or <legend>, should it be a good idea.

One thing to note is that AFAIK, display:contents; is only supported in Firefox at present, so it doesn't have good interop.

[hanshillen]

Sounds like a good idea to me.

[emilbjorklund]

Thanks for the feedback, @LJWatson! FWIW, display: contents seems to have been in development in Blink for a while, so there seems to be some movement, at least.

The important bit is getting some sort of ”Doctype switch” for fieldset/legend combos (to shrug off the old ”unstyleability”). If some other property (that doesn't remove the rendered box) can play that part without breaking compatibility, even better. 😊

[aardrian]

I have not had the experience where developers avoid fieldset/legend simply because of styling issues, and I have been working with web teams since before those elements existed. I would love to see something to back up your assertion.

Do you anticipate display: contents having any effect on the fields and labels that live within the fieldset? Or is this primarily just targeted at indenting and addressing how legend renders (an issue you cite in a blog post linked off the blog post above)? As in, is there any default styling on common (or uncommon) nested elements that developers might lose and, as a result, be hesitant to use display: contents?

All that being said, I don't think this is a bad idea, though display: contents seems a bit of stretch just to remove default indenting.

Given the low existing support for display: contents, lack of browser movement, and probably a need to file new bugs so the browsers redefine how display: contents treats fieldset/legend, I suspect this will take some pushing.

[emilbjorklund]

@aardrian I've come across many people (over the last 10 years or so) who either know about it but are reluctant to use it for styling reasons, or tried using it at some point but then got frustrated over styling and then pretty much forgot that these elements exist at all. It's not like I've kept a journal of those instances, though. Going on feedback I got from writing the blog post (along the lines of ”OMG YES”), I'd say that I'm at least not alone. 😊

That said, when people do use fieldsets, they tend to jump through lots of hoops to ”fix” the rendering (which goes beyond paddings etc), or run into other issues because of the old code paths that fieldset rendering seems to run through:

• My own article of CSS hacks required to at least ”reset” the fieldset styling (and encouraging authors to style a div wrapper rather than the fieldset element itself.
• Roger Johansson's older article covering some fieldset rendering bugs
• Another article from Roger about legend rendering issues
• Chrome bug on fieldsets not being able to be flex items
• CSSWG discussion on the above flavor of bugs

Interesting quote from Tab in that last one:

There's nothing magical about fieldset per spec - it should just be a block normally, and accept other display values like everything else does.
In practice, it's magic in ways that are completely unexplained in CSS, and we haven't wanted to generalize that magic so we've never really tried to explain it.

If browser makers are reluctant to fix the ”completely unexplained magic” for backwards compat reasons, I figured display: contents could at least be a bazooka-level way to say "please stop, I'll fix the rendering myself". It would then be up to them to adjust any margin/padding issues etc - but at least it would be possible.

If we can do that any other way (like, hypothetically, appearance: none), even better. Low browser support for any such solution is to be expected initially, I guess, but that's fine – I'm thinking more of how we can get rid of hacky solutions long-term, and with a CSS-based solution that is fairly self-explanatory. Author interest in display: contents seems to be on the rise, at least, as a way to acheive more advanced subgrid-like layouts in Grid (and flexbox).

[patrickhlauke]

Possibly the more sustainable solution would be to get browsers to fix their sometimes quirky special-casing of fieldset/legend. I admit that I have vague memories of having fought around with styling these and having to do lots of extra work (possibly to get it to work in Firefox) back in the early 2000s. But I thought that most kinks had been ironed out (similarly to the old old issues of not being able to style certain aspects of <button> elements, again from that era, which seem to have mostly been addressed in browsers since).

[emilbjorklund]

@patrickhlauke That would be ideal – my fear is that browser makers won't do that, as it breaks existing sites (the Blink bug I linked to above was one such case - they shipped a fix for fieldset not being able to be a flex container, then had to revert it because of site breakage, if I understand correctly.)

The kinks are still very much there, sadly, and the weirdness of rendering the legend on top of the fieldset border (causing all kinds of strange collisions in terms of borders, backgrounds, shadows etc) is in the rendering documentation in the HTML spec. That's what I want a ”doctype switch” for, so to speak.

[fvsch]

I have not had the experience where developers avoid fieldset/legend simply because of styling issues

I’ve had that experience on 100% projects where we follow a pre-existing visual design (in 12 years in web agencies). Fieldset/legend is just impossible to use if you’re targetting a custom design. If you want to keep the default design that looks like something out of Windows 95, then it’s okay, but I’ve never worked on a commercial project that wanted that.

But I thought that most kinks had been ironed out

I don’t think there’s been significant work on better form styling (which would require a spec to iron out differences and unlock a few oft-requested styling abilities). A few bugs here and there, e.g. in Gecko there’s been appearance:none to remove the <select> arrow, fixes to allow or disallow line-height on text inputs (not sure which direction that was, but it was a compatibility thing), and a bug to allow display:flex on <button>, things like that. Nothing groundbreaking.

[jpdevries]

I have not had the experience where developers avoid fieldset/legend simply because of styling issues, and I have been working with web teams since before those elements existed. I would love to see something to back up your assertion.

I don't avoid it, I just visually hide the <legend> and then style a custom "label" that is aria-hidden="true". Personally I would find being able to style <legend> useful.

[Dan503]

Not being able to easily style a fieldset/legend is a massive pain in the ass. It's a requirement for good accessibility to use fieldset/legend but browsers make the combo almost impossible to style.

I would prefer appearance: none to cancel out the restrictions around styling fieldset/legend over display: contents since display: contents requires a rapper element. display: contents should do it as well though.

[siusin]

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.