New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
emilbjorklund opened this Issue Jul 1, 2017 · 10 comments

Comments

Projects
None yet
9 participants
@emilbjorklund
Copy link

emilbjorklund commented Jul 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

LJWatson commented Jul 3, 2017

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

This comment has been minimized.

Copy link

hanshillen commented Jul 3, 2017

Sounds like a good idea to me.

@emilbjorklund

This comment has been minimized.

Copy link

emilbjorklund commented Jul 3, 2017

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

This comment has been minimized.

Copy link

aardrian commented Jul 3, 2017

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

This comment has been minimized.

Copy link

emilbjorklund commented Jul 3, 2017

@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:

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

This comment has been minimized.

Copy link
Member

patrickhlauke commented Jul 3, 2017

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

This comment has been minimized.

Copy link

emilbjorklund commented Jul 3, 2017

@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

This comment has been minimized.

Copy link

fvsch commented Jul 4, 2017

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

This comment has been minimized.

Copy link

jpdevries commented Jul 4, 2017

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

This comment has been minimized.

Copy link

Dan503 commented Nov 24, 2017

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.

@chaals chaals added this to the When it's ready milestone Jun 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment