Revamp how fieldset and legend rendering is defined

[zcorpan]

Properly define the rendering of the fieldset and legend elements.

The layout model used is most similar to Gecko, which uses an anonymous box to hold the fieldset's contents.

Fixes #3955, fixes #3930, fixes #3929, fixes #3928, fixes #3927, fixes #3915, fixes #3913, fixes #3660, fixes #3331, fixes #2756, fixes #4013.

---

/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/references.html ( diff )
/rendering.html ( diff )

[zcorpan]

cc @whatwg/fieldset

[mstensho]

I don't understand the rationale behind letting the text-align property affect the LEGEND block itself.
In my book, that should be determined by inline margins, and possibly also the ALIGN attribute (but that one's deprecated, right?).
Text-align should only affect the position of text within lines. The position of the lines (or their container) should not be affected.

[zcorpan]

The rationale is just that WebKit and Chromium do this, but we can change it to be more like EdgeHTML (align attribute on ancestor div affects the legend, but text-align does not affect the position).

[mstensho]

Yeah, I think we should be more like Edge here.

[zcorpan]

Fixed in 6bdb923

[mstensho]

"then there border" -> "then the border"

[mstensho]

I'm not so sure about the anonymous box idea anymore. First of all, we'd then have to distribute the CSS properties on the FIELDSET node between the wrapper box and the contents container. Things like 'width', 'border', 'background' 'float', 'z-index', 'position' and 'transform' would intuitively belong in the wrapper, while 'display' and 'overflow' would have to be set on the contents container anonymous box. Do we want to go there?

WebKit creates just one box for a FIELDSET (box type determined by 'display'). The legend is simply encapsulated into the border block-start area. Any chance we could just spec it like that? Having the legend encapsulated into the border makes a lot of sense, e.g. when it comes to determining the containing block size for out-of-flow positioned descendants (in the cases where the FIELDSET isn't statically positioned). Scrolling would also work well then, since borders are outside the scrollport.

One thing that's still not obvious with this approach, though, is paint order. Should the legend be painted in the same phase as the borders (unless the legend establishes a stacking context entry (position:relative, etc.))?

Another thing would be that the used border-width may diverge from the computed border-width. Is that a problem?

[zcorpan]

If this approach works for implementation, it should work for the spec. 🙂

I think paint order should be such that the legend is painted after the fieldset's borders, but before other content of the fieldset. Does that match WebKit?

[mstensho]

Looks like it. Would be interesting to know what others think about this "legend is border" approach, though.

[zcorpan]

OK, please take a look at the latest commit.

[mstensho]

Promoting table-column / table-column-group (something essentially invisible and display:none-ish) to a block seems a bit weird.
Might also consider setting the used value to "flow-root" (rather than "block") for the other values in this list, and get a new formatting context for free. :)

[zcorpan]

I guess it's a bit weird but it's what browsers do, AFAICT.

[zcorpan]

Still need to say to establish the BFC for flex/grid, so it doesn't help much.

[mstensho]

The "used value" thing here bothers me a bit here - first and foremost as an implementor. :)
There are specs that do blockification, for instance, but that's about changing the computed value, not the used value. WebKit does actually change the used value for fieldsets, but is there any reason why we shouldn't change the computed value instead?

[annevk]

I suspect this was to match existing implementations. If we can clean this up that seems nice though.

[zcorpan]

I guess we can change this if it's easier to implement. @MatsPalmgren any opinion?

[tabatkins]

Setting used value of display does nothing; it's not a meaningful operation, since 'display' is only ever consulted during the computed->used transformation.

You can say that if [...] holds, then 'display' behaves as "inline-block", with a note that it doesn't change the computed value for backwards-compatibility reasons.

[MatsPalmgren]

I think we should try to avoid having the computed value of one property (-webkit-appearance) affect the computed value of another property (display) in general, because it makes style engines more complicated and might degrade performance. So Tab's "behaves as" suggestion sounds good to me.

[zcorpan]

OK, fixed in 256593b

[tabatkins]

Please use the phrasing "behaves as", it's becoming a term of art in CSS. (Not quite actually defined yet, but I've been thinking about how to formalize it lately.)

[annevk]

That's what Simon did, no?

[zcorpan]

@tabatkins fixed.

[mstensho]

I really think 'sticky' should also disqualify it from becoming a rendered legend. It's just gonna look silly anyway (right?), and probably not straight-forward to implement.

[zcorpan]

It is the rendered legend in WebKit/Chromium/Gecko/EdgeHTML. It is sticky in Chromium/Gecko/EdgeHTML but not in WebKit.

[mstensho]

Should legends be allowed to be multicol containers, BTW? Yes, because they are allowed to be blocks?

[zcorpan]

Yes. Test at web-platform-tests/wpt#12592

[mstensho]

Why allow only flex, grid and block?
I think we should either allow it to only be a block container, or allow practically any display-inside values.

[zcorpan]

Browsers today blockify legends, but @MatsPalmgren said they should support grid and flex. We could potentially support more if there are use cases and it doesn't break web compat.

https://gist.github.com/zcorpan/2f590536cf64c1aaabbc70f63dbfe2b5

[mstensho]

Yeah, I think we should be more like Edge here.

[mstensho]

Containing block size calculation (for e.g. percentage height resolution) for legends needs to be specced. I imagine it should contain the logical top border and padding areas (since legends are placed above the padding area, and are part of the border), although no browsers do that currently:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6133 (only testing borders, no padding)

[MatsPalmgren]

Edge/Firefox/Chrome renders the percentage height testcase the same though, so I think we should spec that rather than risk regressing existing web content. Also, I don't consider a rendered legend to be "part of the border" because then its extent should be part of the border-box area and thus the fieldset background should render behind it (fully), a box-shadow should wrap it etc, and that's not what any UAs do as far as I know.

Perhaps the spec would benefit from an example figure that visualizes the rendering? Something like this table figure. In Gecko we implement the <fieldset> using two boxes, an outer box that contains the rendered legend as the first child box and an inner anonymous box that contains the boxes of the other <fieldset> children. (Similar to how the table wrapper box wraps its caption and an inner table box.) Then it would be easier to discuss where and how the margin/padding/border of the various boxes should be applied and how a "reserved space" for the rendered legend should be calculated.

[mstensho]

Yes, all browsers render the same with my test, and I do agree that it's risky to spec it otherwise then. However, since legends are placed at the very top of the fieldset (and thus ignores top border and padding), it's kind of strange that top border and padding are included in the containing block size when resolving percentages.

Anyway, my post about containing block size calculation concerns was written under the assumption that we really let the legend be part of the border area (that's what the current spec changes in this pull request say), but I believe this is something we still need to discuss.

I was quite sold on the "two boxes" approach myself, but then I noticed that WebKit just puts it in the border area (and expands the border area if necessary), which seems simpler, and also easy to reason about. Blink doesn't use two boxes for tables, like the spec says (that implementation detail isn't leaked via any web-exposed API that I'm aware of, though), but what I find tricky with this approach is to determine which properties should be set on the outer box and which to set on the inner one. https://www.w3.org/TR/CSS22/tables.html#model mentions 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' as properties to set on the wrapper box. That list is far from complete, though. First of all, it only covers CSS 2 (and even then it seems to forget about things like z-index). How do you determine which property goes where?

EDIT: Looks like the answer to that lies in https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

[zcorpan]

Related bug re percentage height. https://bugs.chromium.org/p/chromium/issues/detail?id=178782

[zcorpan]

I find 20 pages in httparchive that style legend with a percentage height.

https://gist.github.com/zcorpan/186444076d75b735e99439bcddf92e40

[mstensho]

This is fine in the general case, but I'm realizing that it won't do if the legend establishes a stacking order entry (using relative position, opacity != 1.0, transform, etc.). Then we won't be able to paint it in the background phase. One special thing with the background phase is that it's not affected by scroll offset. But if we don't paint the legend in the background phase, it will be affected by the scroll offset if the fieldset has scrollable overflow.

This is something that won't be a problem if we wrap everything but the legend inside an anonymous fieldset child (like Firefox), so that e.g. overflow:scroll will be set on that anonymous child (which obviously won't affect the legend when it's on the outside).

[zcorpan]

What does WebKit do?

[mstensho]

Fails to paint the legend when it's relatively positioned and the fieldset is scrollable.
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6141

[zcorpan]

Here's a demo with percentage heights: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6143

A is 150px in Safari/Chrome/Firefox/Edge. B is 5px in Safari/Firefox, 150px in Chrome/Edge.

[MatsPalmgren]

The B result in Firefox seems like a bug to me. I think it should be 150px. I filed bug 1485646.

[zcorpan]

In that case, I think what https://drafts.csswg.org/css2/visudet.html#containing-block-details says should just apply to fieldset, without HTML having to say anything in particular. Right?

[mstensho]

I'd like us to settle on a FIELDSET/LEGEND layout model.

<!DOCTYPE html>
<div style="width:400px; height:400px;">
  <fieldset style="overflow:scroll; padding:10%; width:100px; height:100px;">
    <legend>legend</legend>
    <div style="height:500px;">contents</div>
  </fieldset>
</div>

In this example we have a scrollable fieldset. The legend is not expected to scroll along with the fieldset contents, according to Firefox, Safari, and common sense.

This does suggest that it makes sense to create an anonymous child for the actual contents of the fieldset. So I'd like to explore that approach a bit further (rather than my former favorite: slap the legend in the border area, expand the border as necessary, paint it as part of border painting - like WebKit).

The question then is, which properties should the anonymous child inherit, and which ones should the parent fieldset ignore (if any). And how much magic do we have to apply in addition to that?

Intuitively, 'overflow' should go on the anoymous child, so that the legend isn't scrolled along with the rest. Padding probably needs to be ignored on the parent FIELDSET and be applied on the anonymous child, though, so that the scrollport includes the padding. However, percentages need to be resolved on the FIELDSET and NOT on the anonymous child. @MatsPalmgren Does Firefox really get away with no special magic here?

Firefox has a nice selector for the anonymous child here: https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

[zcorpan]

Why doesn't the WebKit approach work when there is a scrollport? What does WebKit do in that case?