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 #2805

Closed
emilbjorklund opened this Issue Jul 1, 2017 · 14 comments

Comments

8 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.

@emilbjorklund

This comment has been minimized.

Copy link

emilbjorklund commented Jul 1, 2017

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

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Jul 1, 2017

This seems like mostly a proposal for the CSS working group, although it certainly has some overlap with HTML. @tabatkins, could you help route this?

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Jul 1, 2017

/cc @mstensho and @bzbarsky as I see you were involved in #2756.

My guess is that display: contents is not the right CSS property to trigger this; instead position: relative or appearance: none or reset: all or something. (Also, please don't call it legacy: it's very much purposeful behavior.) Curious to hear what CSS spec and implementer folks think though.

@emilbjorklund

This comment has been minimized.

Copy link

emilbjorklund commented Jul 3, 2017

As the rendering of fieldset/legend combos (which is the thing causing the most weirdness) is defined in the HTML spec rather than in a CSS spec, I think it makes more sense to open the bug here, no?

Regarding which CSS property would remove the current behavior: sure, I'm open to it being another property – my thinking was that position: relative would cause backwards compatibility issues. But in essence, any property that doesn't cause compat issues could be used as the equivalent of a ”doctype switch" for fieldsets would work. Even better if it's one that doesn't remove the rendered box.

(As to not calling it ”legacy”: sure, let's call it "the spec-prescribed rendering of fieldset + legend combos that is pretty much impossible to recreate in user agent CSS, and therefore has weird quirks in various browsers that authors cannot predict, and if it would have been designed today the chances are slim-to-none that it would have been described that way, but we're stuck with it now, so there you go.") :-)

@SelenIT

This comment has been minimized.

Copy link
Contributor

SelenIT commented Jul 4, 2017

It seems that the CSS Display level 3 spec already has it. The "Appendix B: Effects of display: contents on Unusual Elements" currently states:

button
details
fieldset
These elements don’t have any special behavior; display: contents simply removes their principal box, and their contents render as normal.

And it even seems to work in the latest Chrome behind the "Experimental Web Platform features" flag (see jsfiddle).

@emilbjorklund

This comment has been minimized.

Copy link

emilbjorklund commented Jul 4, 2017

@SelenIT That's excellent! I must admit I had missed that (I might have been looking at an earlier version – that appendix was added in March).

Although: while the effects on fieldset are there, the behavior as described for legend doesn't work in latest Chrome/Canary (with experimental flag on):

Per HTML, a legend with display: contents is not a rendered legend, so it does not have magical display behavior. (Thus, it reacts to display: contents normally.)

...which is a bit of a shame, as the weirness mostly relates to legend positioning.

In any case, sounds like it's time to file some browser bugs. 😊

I do think that @domenic is onto something when looking for another property to act as "doctype switch" for the behavior as whole, without removing the rendered box for either fieldset or legend, thus not requiring extra markup to style either.

@fvsch

This comment has been minimized.

Copy link

fvsch commented Jul 4, 2017

Beyond display:contents, appearance: none comes to mind. There’s precedent for other form elements (at least select, maybe button or some input types too?).

@SelenIT

This comment has been minimized.

Copy link
Contributor

SelenIT commented Jul 4, 2017

I agree that, ideally, appearance: none would be the best way to "switch off" all the built-in browser rendering "magic" for these "special" elements. But wouldn't changing its behavior it break existing pages that already rely on appearance: none to remove only limites set of default properties of these elements (as the shipped browsers currently do)? Maybe it would make sense to introduce a new appearance value, like normal or default, for this?

But anyway, until this new switch gets implemented and becomes standard, display:contents can be an acceptable workaround. I believe that browsers should support it, too. Moreover, if this is implemented, wouldn't it be easier to implement the standard switch technically as creating the ordinary wrapper box around the result of display:contents?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

bzbarsky commented Jul 15, 2017

So just to be clear, what people are really looking for here is to make a <legend> inside a fieldset not have the "rendered legend" behavior, right?

If we were green-field designing this, presumably this would be some property we set on the legend itself. As things stand, it's not clear to me whether it's best to do this via a property on the legend or the fieldset, and which property...

I do agree that the interaction between CSS and HTML for display:contents on fieldset, and in particular the definition of rendered legend needs to be more clearly defined.

@SelenIT

This comment has been minimized.

Copy link
Contributor

SelenIT commented Jul 15, 2017

what people are really looking for here is to make a inside a fieldset not have the "rendered legend" behavior, right?

@bzbarsky, IMO, not only that. There are other peculiarities in the fieldset behavior that are not always wanted (e.g. content-depending minimum width or new block formatting context regardless the styling). So I suppose that making fieldset behave like a usual element would have its use cases by itself. Making legend not have the "rendered legend" behavior without changing the behavior of fieldset would also have its use cases, so probably there should exist an independent solution for this. And what are the problems of the current definition of the rendered legend in HTML?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

bzbarsky commented Jul 15, 2017

e.g. content-depending minimum width or new block formatting context regardless the styling

Ah, true.

And what are the problems of the current definition of the rendered legend in HTML?

See discussion in #2756

@patrickdark

This comment has been minimized.

Copy link

patrickdark commented Aug 15, 2017

display: contents doesn't solve the problem with these elements. All it does is ignore them; one still has to have additional elements that serve as styling hooks.

@bzbarsky I typically want something like:

form { display: table; }
fieldset { display: table-row; }
legend, legend + * { display: table-cell; }

The problem would seem to be with the fieldset element—not the legend element. If I replace fieldset elements with p elements, the styles work. If I replace legend elements with label elements (and leave fieldset elements as they are) the styles don't work.

In fact, I asked for a solution to this styling problem just ten days ago: https://stackoverflow.com/questions/45517590/how-do-i-style-an-html-legend-element-as-a-table-cell-in-mozilla-firefox. There aren't any answers, presumably because there is no solution without a browser fix. (I privately opted to solve the problem by using an HTML table, thereby sacrificing functionality like HTMLFieldSetElement.disabled)

The optimal solution would be for this CSS to just work.

The next best solution is to use appearance: none as a switch, which inexplicably doesn't work in this case.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

bzbarsky commented Aug 29, 2017

Right, the problem is that HTML requires "fieldset" to have special rendering behavior and this is done by giving it a particular box type and that precludes it having a table-row box...

Worse, just switching to not doing the special box type if the display is changed is not backwards-compatible and may break pages. :(

Having "appearance: none" disable the special box type business might be doable, again modulo it being non-backwards-compatible...

@zcorpan

This comment has been minimized.

Copy link
Member

zcorpan commented Aug 15, 2018

Tests for display: contents on fieldset and legend landed in web-platform-tests/wpt#8699

Per spec display: contents should work on fieldset and legend already, so I'll close this issue.

Using appearance: none to turn off magic is #3912.

@zcorpan zcorpan closed this Aug 15, 2018

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