Review HTML fieldset/legend spec

[zcorpan]

I would appreciate CSS WG review of whatwg/html#3934

Generated spec at https://whatpr.org/html/3934/rendering.html#the-fieldset-and-legend-elements

Tests at https://wpt.fyi/results/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements

Thank you

[fantasai]

First glance comments:

• -webkit-appearance shouldn't appear in an HTML spec as the definition of how something works. If we need a property for this (which I suspect we do), it should be appearance and -webkit-appearance should be a legacy alias to it. If 'fieldset' isn't dictated by Web-compat, then the only values that really need to work are none and unset, so let's make those work and note them in the spec. And fix [css-ui] Unprefix 'appearance' and/or make the spec web-compatible #3024.
• Using appearance: fieldset to create a new, general-purpose display type is awful. If the goal is to create a new general-purpose display type, add a new value to display.
• Also, definitions of new CSS properties and values don't really belong in the HTML spec? (Writing a layout model spec inside the HTML spec also seems ill-advised.)
• Creating a legend property just for this seems excessive. Why not re-use appearance if you want it magical (specific to LEGEND), or add a new outer display type to display if you want it more generally-applicable (e.g. to DIVs or whatever)?
• If the legend is overlaying the corner of the box, it should also obscure that part of the adjacent border. It seems perfectly reasonable for an author to want to position the legend over the corner: having only the block-start side of the border disappear in that case looks ugly. Mask the affected part of the border, nevermind which side it is.
• “The used value of the 'padding' property is expected to be zero.” I don't understand this requirement.
• “The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value?
• “In the absence of an explicit inline size, the box should shrink-wrap.” Can you set its inline-size to fit-content in the UA style sheet, or is this supposed to be part of the legend magic? If it's magic, we should tighten up the wording to match css-sizing.
• “In the absence of explicit margins in the inline direction, the element is expected to be positioned in the inline direction as follows” Use the justify-self property for this mapping. That's what it's for.
• “The used value of the element's margins in the block-flow direction are expected to be zero.” I don't know what “expected to” means here. If we're defining a new layout model corresponding to some CSS syntax, it should be clearly normative. Also, if it's possible to make the margins useful, that might be something to look into.
• “The following properties are expected to inherit from the 'fieldset'” ... we should try to find some better to make sure this list stays up-to-date. :/
• “The 'block-size' property is expected to be set to '100%'.” I'm pretty sure this is going to make me sad, I just haven't figured out how yet.

I appreciate your work on this, and also taking the initiative to ask the CSSWG for review. Cleaning up fieldset/legend to make sense would be lovely. I'd like us to work a little harder on reducing the weirdness, defining the layout model more rigorously, and making this feature pleasantly controllable for authors if at all possible.

p.s. Currently pondering the last two points, and wondering if it would work better to define this as the legend being taken out-of-flow from the fieldset's contents, laid out over the fieldset's border, and accounted for as an increase in the fieldset's border/padding area. That would probably address a lot of the sizing considerations better, and in a way that won't break as CSS evolves.

[MatsPalmgren]

Using appearance: fieldset to create a new, general-purpose display type is awful. If the goal is to create a new general-purpose display type, add a new value to display.

FYI, Gecko supports grid/flex/column layout of the <fieldset> contents by propagating those values to the inner anonymous box. I agree that display:fieldset + exposing the inner box with a pseudo for direct styling is probably cleaner but I wonder how web-compatible that would be at this point.

Creating a legend property just for this seems excessive. Why not re-use appearance if you want it magical (specific to LEGEND), or add a new outer display type to display if you want it more generally-applicable (e.g. to DIVs or whatever)?

Setting -webkit-appearance:legend on an element that already has a value in the UA sheet (e.g. form controls) destroys its visual appearance (see whatwg/html#3968). display:legend would have the same problem as for fieldset - how do you specify grid/flex layout of its contents?
(But yes, I agree this new legend property needs to be in a CSS spec somewhere).

“In the absence of explicit margins in the inline direction, the element is expected to be positioned in the inline direction as follows” Use the justify-self property for this mapping. That's what it's for.

Agreed, this is whatwg/html#4013. (Fwiw, I've already implement a prototype mapping <legend align> to justify-self and it seems to work well.)

“The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value?

Determining which box is the rendered legend happens during box construction, so it seemed "too late" to change the computed value at that point. (I could be wrong.)

“The used value of the element's margins in the block-flow direction are expected to be zero.” I don't know what “expected to” means here. If we're defining a new layout model corresponding to some CSS syntax, it should be clearly normative. Also, if it's possible to make the margins useful, that might be something to look into.

I agree that block-axis margins should not be ignored. Gecko currently support them, but WebKit/Blink doesn't, see whatwg/html#3929.

[zcorpan]

Thank you for the feedback @fantasai!

• -webkit-appearance shouldn't appear in an HTML spec as the definition of how something works. If we need a property for this (which I suspect we do), it should be appearance and -webkit-appearance should be a legacy alias to it. If 'fieldset' isn't dictated by Web-compat, then the only values that really need to work are none and unset, so let's make those work and note them in the spec. And fix [css-ui] Unprefix 'appearance' and/or make the spec web-compatible #3024.

I agree that it would be nice to unprefix (#3024), but since the current spec for appearance isn't web-compatible, Mozilla are reverse engineering Chrome and ignoring the spec (#1250). Also, web compat requires more values to be supported than that.

• Using appearance: fieldset to create a new, general-purpose display type is awful. If the goal is to create a new general-purpose display type, add a new value to display.

Unfortunately, that is not web compatible. Web pages set 'display' to something and expect the fieldset magic to still be there.

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

• Also, definitions of new CSS properties and values don't really belong in the HTML spec? (Writing a layout model spec inside the HTML spec also seems ill-advised.)

I'm happy to have it be moved elsewhere when it has stabilized.

• Creating a legend property just for this seems excessive. Why not re-use appearance if you want it magical (specific to LEGEND), or add a new outer display type to display if you want it more generally-applicable (e.g. to DIVs or whatever)?

As @MatsPalmgren said, we can't use appearance since it would not combine well with elements that have an appearance by default. We again can't use display for web compat.

• If the legend is overlaying the corner of the box, it should also obscure that part of the adjacent border. It seems perfectly reasonable for an author to want to position the legend over the corner: having only the block-start side of the border disappear in that case looks ugly. Mask the affected part of the border, nevermind which side it is.

I think this wouldn't match how it's implemented.

• “The used value of the 'padding' property is expected to be zero.” I don't understand this requirement.

The padding is used for the anonymous fieldset content box instead.

• “The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value?

What @MatsPalmgren said.

• “In the absence of an explicit inline size, the box should shrink-wrap.” Can you set its inline-size to fit-content in the UA style sheet, or is this supposed to be part of the legend magic? If it's magic, we should tighten up the wording to match css-sizing.

If an author sets inline-size to auto, it should still shrink-wrap. I can look at the wording, thanks.

• “In the absence of explicit margins in the inline direction, the element is expected to be positioned in the inline direction as follows” Use the justify-self property for this mapping. That's what it's for.

Yeah, we can do that. I haven't yet figured out how justify-self interacts with margins.

• “The used value of the element's margins in the block-flow direction are expected to be zero.” I don't know what “expected to” means here. If we're defining a new layout model corresponding to some CSS syntax, it should be clearly normative. Also, if it's possible to make the margins useful, that might be something to look into.

"Expected" is a normative keyword in the rendering section:

https://html.spec.whatwg.org/multipage/infrastructure.html#renderingUA

• “The following properties are expected to inherit from the 'fieldset'” ... we should try to find some better to make sure this list stays up-to-date. :/

Any suggestion? :)

• “The 'block-size' property is expected to be set to '100%'.” I'm pretty sure this is going to make me sad, I just haven't figured out how yet.

The intent here is to make percentage block sizes work.

I appreciate your work on this, and also taking the initiative to ask the CSSWG for review. Cleaning up fieldset/legend to make sense would be lovely. I'd like us to work a little harder on reducing the weirdness, defining the layout model more rigorously, and making this feature pleasantly controllable for authors if at all possible.

Thanks.

p.s. Currently pondering the last two points, and wondering if it would work better to define this as the legend being taken out-of-flow from the fieldset's contents, laid out over the fieldset's border, and accounted for as an increase in the fieldset's border/padding area. That would probably address a lot of the sizing considerations better, and in a way that won't break as CSS evolves.

Maybe. I'd like to spec it in a way that closely follows how it's implemented, though.

[frivoal]

+1 to everything fantasai said.

Additional points:

• I would be extremely careful about requiring particular values to be supported in the -webkit-appearance property (whether it is standalone, or an alias for appearance) as long as the way that property itself works is not properly defined, because it makes it very unclear what the overall effects of switching from another value are. And so far, I believe that it isn't properly. Or to be more specific, it is defined twice, differently:

  • Once, as appearance in CSS-UI-4, but there are complains that the current incarnation is not web compatible, and the debate as to whether it can be made web compatible is not closed. (see [css-ui] 'auto' as the initial value for the 'appearance' property isn't web-compatible #1250)
  • Once, as -webkit-appearance, in the compat spec, in a way that is hand-wavy and incomplete, and in importantly (as least by my reading) is self contradictory, which makes it impossible to implement as specified. (see [css-ui] Unprefix 'appearance' and/or make the spec web-compatible #3024 (comment))

• Whether or not an element is a replaced element depends (presumably, that's not fully determined yet, see previous point) on the value of the appearance property. (-webkit-)appearance:none turns form controls that would otherwise be replaced elements into non replaced. In a world view where (-webkit-)appearance:auto is a thing, it can be said that some elements are replaced by default, unless turned off by appearance:none. In a wold view where (-webkit-)appearance:auto is not a thing, then the replacedness of form elements is explained by the (-webkit-)appearance property's value. This makes the following statement in the proposed spec problematic: "Saying that The 'fieldset' value, when specified on a non-replaced element, is expected to act as follows: [...]". The property cannot both affect whether an element is replaced or not, and have different effects depending on whether the element is replaced or not.

• Revamp how fieldset and legend rendering is defined whatwg/html#3934 claims to (emphasis mine) ”Define fieldset's rendering in terms of a new 'webkit-appearance' value, so that web developers can turn off the magic”. A new value (regardless of the property) is only needed to let people turn on the magic. To turn off the magic using the appearance property, the none value is sufficient.

• The proposed spec has the following requirements:

  • The element is expected to establish a new block formatting context
  • The 'display' property is expected to act as follows:
    • If the computed value of 'display' is [...list that doesn't include grid...] then behave as 'inline-block'.
    • If the computed value of 'display' is [...list that doesn't include grid...] then behave as 'block'.
    • Otherwise , use the computed value.

  What does that mean? If the display property is grid, does the element establish a block formatting context, or a grid formatting context? Same problem with flex, or contents…

• I don't question the need to be able to turn this off, nor the need for interop when it is on. However that does not necessarily require the introduction of the ability to turn the magic on on arbitrary markup. It seems to me that the type of layout that it offers is very close to the sort of layout that can be achieved with grid. I think that with some minor tweaks / extensions to subgrid + exposing the inner box with a pseudo for direct styling (as suggested by @MatsPalmgren above or in [css-pseudo] Add a ::contents pseudo-element #2406), it should be possible to reproduce that sort of layout without any special purpose machinery. I'm not 100% positive, but I think this could be clarified in maybe 1 hour of whiteboarding with the editors of css-grid-2. Maybe I'm wrong, but I'm not sure we should rush to adding special purpose mechanisms, when generic purpose mechanisms can handle it or be made to handle it with some minor generally useful tweaks.

[zcorpan]

Thanks @frivoal

• I would be extremely careful about requiring particular values to be supported in the -webkit-appearance property (whether it is standalone, or an alias for appearance) as long as the way that property itself works is not properly defined, because it makes it very unclear what the overall effects of switching from another value are. And so far, I believe that it isn't properly. Or to be more specific, it is defined twice, differently:

  • Once, as appearance in CSS-UI-4, but there are complains that the current incarnation is not web compatible, and the debate as to whether it can be made web compatible is not closed. (see [css-ui] 'auto' as the initial value for the 'appearance' property isn't web-compatible #1250)
  • Once, as -webkit-appearance, in the compat spec, in a way that is hand-wavy and incomplete, and in importantly (as least by my reading) is self contradictory, which makes it impossible to implement as specified. (see #3024 (comment))

We should sort this out, I agree. I hope to be able to help work on this soon.

• Whether or not an element is a replaced element depends (presumably, that's not fully determined yet, see previous point) on the value of the appearance property.

No, it doesn't. Form controls are not defined to be replaced elements. See https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements

• whatwg/html#3934 claims to (emphasis mine) ”Define fieldset's rendering in terms of a new 'webkit-appearance' value, so that web developers can turn off the magic”. A new value (regardless of the property) is only needed to let people turn on the magic. To turn off the magic using the appearance property, the none value is sufficient.

Well, we also need a value that is not 'none' that fieldset has by default.

• The proposed spec has the following requirements:

  • The element is expected to establish a new block formatting context

  • The 'display' property is expected to act as follows:

    • If the computed value of 'display' is [...list that doesn't include grid...] then behave as 'inline-block'.
    • If the computed value of 'display' is [...list that doesn't include grid...] then behave as 'block'.
    • Otherwise , use the computed value.

  What does that mean? If the display property is grid, does the element establish a block formatting context, or a grid formatting context? Same problem with flex, or contents…

"Otherwise , use the computed value." -- what is unclear?

• I don't question the need to be able to turn this off, nor the need for interop when it is on. However that does not necessarily require the introduction of the ability to turn the magic on on arbitrary markup. It seems to me that the type of layout that it offers is very close to the sort of layout that can be achieved with grid. I think that with some minor tweaks / extensions to subgrid + exposing the inner box with a pseudo for direct styling (as suggested by @MatsPalmgren above or in [css-pseudo] Add a ::contents pseudo-element #2406), it should be possible to reproduce that sort of layout without any special purpose machinery. I'm not 100% positive, but I think this could be clarified in maybe 1 hour of whiteboarding with the editors of css-grid-2. Maybe I'm wrong, but I'm not sure we should rush to adding special purpose mechanisms, when generic purpose mechanisms can handle it or be made to handle it with some minor generally useful tweaks.

I dunno, fieldset is pretty funky. But if you figure something out that browsers are willing to implement, then sure.

[frivoal]

We should sort this out, I agree. I hope to be able to help work on this soon.

Let's talk. This is a thorny but important issue.

No, it doesn't. Form controls are not defined to be replaced elements. See https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements

They are not listed as replaced elements according to that spec, but the definition of replaced element it links to (in css2, also to be found in https://drafts.csswg.org/css-display-3/#replaced-element) to is not restrictive, so that list can easily be taken as "at least these things are", rather than "only these things can be". Throughout its usage in CSS specs, the term "replaced element" is often taken to mean "elements whose internal layout is not explained by css" in a broad sense, which would not work if it was restricted to the thigns that the html spec lists, and specs vaguely (yes, that vagueness is a problem) assume that some amount of form controls most certainly are replaced (and some partially replaced). I think this is a very messy territory.

I'll just take one example: whether listed or not, <input type=checkbox> effectively behaves like a replaced element, in the broad sense of the css definition: its content is outside the scope of the CSS formatting model, most properties have no effect on it, but if you apply appearance:none to it, then that stops being true, and it starts behaving like a regular element. So either the current definition of replaced element is not useful, or whether something is a replaced element does depend on the appearance property (in part. <img> elements are replaced elements regardless of appearance).

Related note, if we take that list of replaced elements to be exhaustive, then I suppose that an svg element isn't a replaced one, and that therefore, applying appearance: fieldtext to it will turn it into a Block Formatting Context. I don't know what that'd mean.

    To turn off the magic using the appearance property, the none value is sufficient.

Well, we also need a value that is not 'none' that fieldset has by default.

Maybe, but that value might be auto / normal, which just does the right thin on fieldsets, but doesn't let you opt into this model elsewhere. I know that whether auto should be a value of appearance is not uncontroversial, but the version without it has problems too.

"Otherwise , use the computed value." -- what is unclear?

I guess it depends on what "use" means. The only thing that makes sense to me is "honor the layout mode you get by obeying that computed value", but if that's true, then when display is grid, then your element must be a grid container, and must establish a grid formatting context. But the spec earlier says that it wants a block formatting context. So there's a contradiction.

Also, boxes, not elements, establish formatting contexts. In the case of display: contents, there's not principal box. Is appearance: fieldset supposed to be overriding this and make the element generate a box after all, so that it can establish a BFC? Probably not, but this is not clear.

I dunno, fieldset is pretty funky. But if you figure something out that browsers are willing to implement, then sure.

I don't expect that we'll be able to explain the behavior of fieldset+legend in a backward compatible way with generic mechanisms. I do suspect that we may be able to obtain through generic mechanisms a behavior that is similar enough to fieldset+legend that the legacy behavior might be able to be contained to actual fieldsets+legend elements under appearance: auto (if that ends up being a thing), and that authors wishing to do something similar elsewhere can use the generic mechanism, rather than use the legacy compat hack that doesn't play well with the rest of CSS.

[css-meeting-bot]

The CSS Working Group just discussed Review HTML fieldset/legend spec.

The full IRC log of that discussion

<dael> Topic: Review HTML fieldset/legend spec
<dael> github: https://github.com//issues/3094
<dael> astearns: Looks like fantasai mats and florian have commented in issue.
<dael> astearns: If you were not aware, please take a look at the issue
<dael> astearns: If you have anything to contibute please do.
<tantek> wow long comments are loooooooong
<dael> fremy: I didn't write anything on the issue and I haven't seen fantasai comments. It's an amazing document. One concern is in Edge webkit-appearance is cosmetic. We only support none. I'm concerned to see it overriding display and other essential properties to CSS.
<dael> fremy: If this is how it works in blink maybe, but I get this impression this is not a thing it does. If this is not how it works in blink I would not make it this way. I have not had a chance to verify
<tantek> q?
<dael> florian: You can I need to be involved in paralel conversaiton. There's a whatwg standardization of the webkit property where they're specing half of it. They're not super happy with out proposal so we should be involved
<dael> chrishtr: The blink engineers are opposed to adding more functionality to prefix properties.
<dael> florian: Good to know, I agree
<dael> tantek: I also agree
<Rossen_> +1
<fantasai> s/should be involved/should talk/
<dael> tantek: I don't think should be adding anything to appearance. Adding functionality feels like pointing someone to a giant mess.
<dael> florian: Total agreement, but there are 2 groups of people not talking. Our side saying this and another group saying we shoulds tandardize on webkit-appearance
<dael> Rossen_: Upcoming F2F event coming up...good thing to talk about there. I propose we keep looking and see if we can reach agreement at TPAC
<dael> tantek: sgtm
<dael> astearns: Add to wiki agenda?
<dael> Rossen_: Def. We'll see if we can pull people from whatwg
<dael> astearns: Other thing I noticed is there is a lot being discussed. Threading is hard to follow. If anything can split to its own issue please do
<dael> florian: It's tricky. It's a giant spec. Having 25 issues sep is different then one list where everything is bad and maybe we should reconsider.
<dael> astearns: Just pointing out as we find separate issues to solve we should split
<dael> dbaron: Another point here: interop is bad and this spec is doing a lot to improve it. SHouldn't ask for it to be thrown out. WE should question what is not needed for interop, but a bunch of this is needed given web compat
<dael> florian: Taking as dependencies as things not defined and assuming they work as they do in chrome. BUt they're not defined to work that way. Until solve dependencies not clear the spec works
<tantek> agreed with specing backcompat interop
<dael> fremy: Let's put this on TPAC agenda where we can work together and once everyone has read the spec.
<tantek> but disagreed with extending aappearance OR -webkit-appearance
<dael> fantasai: I think 2 things to add. This fieldset stuff but also appearance property.
<tantek> also disagreed with methodology of "just spec what Chrome does"
<dael> Rossen_: For appearance property good to summerize the principles as to what we'll take. Also making clear position on prefix properties. Then go from there
<tantek> can we counterpropose deprecating FIELDSET and LEGEND?
<fantasai> tantek, no
<dael> florian: And also people sync internally. Mozilla here and mozilla in compat spec seem to be different to take one example. Talking internally would be nice
<dael> florian: Maybe TPAC is the place for that
<tantek> they are too much trouble for authors to bother trying to use in any compat / interop way
<fantasai> tantek, they're perfectly fine HTML elements, we just need to be able to a) make them not magic b) ideally define the magic so it can be controlled and/or reused
<dael> astearns: Good for now? This will all go in the issue. Please continue there before TPAC.

[fantasai]

@MatsPalmgren

FYI, Gecko supports grid/flex/column layout of the

contents by propagating those values to the inner anonymous box. I agree that display:fieldset + exposing the inner box with a pseudo for direct styling is probably cleaner but I wonder how web-compatible that would be at this point.

I think we'd want fieldsetness (i.e. manipulating the first legend into the border area) to be something independent of the inner display type, so something like the 'list-item' keyword, which can be combined with various inner/outer display types. So you would say display: block grid fieldsetty.

The Web-compat issue is interesting. I definitely don't like using appearance as a general switch for this, to turn it on for arbitrary elements. It's got significant layout implications, no visual implications, and isn't really a good fit for appearance; also I do imagine that authors will want to use this ability on other elements, if it becomes accessible through a property, so we should design the trigger for it as if we were designing a new feature for general use.

If we need display: <inner-display> to work on <fieldset> without overwriting the fieldsetness, then we can run the following computation: if the element is <fieldset> and the appearance is not none (or is auto or is not none/button/whatever), then the computed value of display includes fieldsetty (or whatever we choose to call it). That should deal with the Web-compat issue, and also make appearance: none turn off FIELDSET's specialness, which is nice because appearance: none is supposed to take away the specialness of all other form controls.

display:legend would have the same problem as for fieldset - how do you specify grid/flex layout of its contents?

display: legend grid. I did say it should be an outer display type, that implies you can combine it with an inner one like grid or flex. :)

“The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value?

Determining which box is the rendered legend happens during box construction, so it seemed "too late" to change the computed value at that point. (I could be wrong.)

Is it a Web-compat requirement that legends which are not the “rendered legend” be inline-level? Because if not, then the legend property (or as I'm proposing it, display: legend) can just blockify unconditionally.

Agreed, this is whatwg/html#4013. … see whatwg/html#3929.

Thanks, I'll follow up there.

@zcorpan

I agree that it would be nice to unprefix (#3024), but since the current spec for appearance isn't web-compatible, Mozilla are reverse engineering Chrome and ignoring the spec (#1250). Also, web compat requires more values to be supported than that.

If the current spec isn't Web-compatible, then it needs to be fixed. It seems like there needs to be some discussion among interested properties in how exactly appearance should be specced (and the CSSWG is proposing we all do that during TPAC next month), but the HTML spec should not be relying on -webkit-appearance to define a new feature.

Unfortunately, that is not web compatible. Web pages set 'display' to something and expect the fieldset magic to still be there.

See response to Mats, above.

I'm happy to have it be moved elsewhere when it has stabilized.

Cool.

If the legend is overlaying the corner of the box, it should also obscure that part of the adjacent border. It seems perfectly reasonable for an author to want to position the legend over the corner: having only the block-start side of the border disappear in that case looks ugly. Mask the affected part of the border, nevermind which side it is.

I think this wouldn't match how it's implemented.

I think that's incorrect, since Firefox masks the inline-start/end edges just fine: testcase

"Expected" is a normative keyword in the rendering section:

OK, sure, but your spec is written such that this section is defining the behavior of certain CSS keywords and properties. That behavior should to be required, not optional, because we don't want to create new CSS keywords and properties whose behavior is “optional”. Use the “expected to” conditions on whether or not FIELDSET and LEGEND are mapped to these new display types you're creating, but don't use it when defining how the new display types are defined.

“The following properties are expected to inherit from the 'fieldset'” ... we should try to find some better to make sure this list stays up-to-date. :/

Any suggestion? :)

Yeah, I'm pretty convinced at this point that the postscript is a better way to go. :) A lot of the exceptional layout rules you're adding here would just go away.

p.s. Currently pondering the last two points, and wondering if it would work better to define this as the legend being taken out-of-flow from the fieldset's contents, laid out over the fieldset's border, and accounted for as an increase in the fieldset's border/padding area. That would probably address a lot of the sizing considerations better, and in a way that won't break as CSS evolves.

Maybe. I'd like to spec it in a way that closely follows how it's implemented, though.

Looking at all the exceptions you're creating, I think it's creating more of a mess to do it this way at the spec level, though. It's not just the exceptions you've listed, it's also that the model I'm proposing will behave as expected in cases we haven't thought of and in cases that don't exist yet, whereas the two-box model that you're proposing will keep needing explicit exceptions to divide one box’s behavior across two boxes. Its just not going to be as maintainable.

(There's a number of cases where the spec has one box whereas e.g. Gecko generates two nested boxes. E.g. scroll containers and table cells, IIRC. It doesn't mean those cases should use nested boxes in the spec.)

@frivoal

I don't question the need to be able to turn this off, nor the need for interop when it is on. However that does not necessarily require the introduction of the ability to turn the magic on on arbitrary markup. It seems to me that the type of layout that it offers is very close to the sort of layout that can be achieved with grid.

I don't think this is true. The way the legend takes up space outside the fieldset border, for example, can't be duplicated with grid afaict...

[fantasai]

If we don't want to make this a re-usable CSS feature, btw, the easiest way to control things would be with appearance: none | auto: if a FIELDSET is auto, then it is fieldsetty, and it takes the first LEGEND whose appearance is auto. Authors can turn off the special behavior appearance: none, and they can control which LEGEND to use likewise.

[fantasai]

Basically I'm saying we choose one of the following:

• We decide to make it specific to FIELDSET/LEGEND elements. In that case, use appearance: auto | none for control, as described above.
• We decide to make it a re-usable feature invoked by CSS declarations. In that case, clean it up and design it as if we were intending to create that feature independently, just make sure it also fits the Web-compat requirements of FIELDSET/LEGEND so it can be used to describe them.

I don't want us to:

• Decide we don't want it to be a reusable feature, but define it in a way that makes it so, but not in a way that'd be nice if we were intending it to be reusable.

[zcorpan]

I think that's incorrect, since Firefox masks the inline-start/end edges just fine: testcase

I stand corrected. I'll fix, thanks!

[zcorpan]

Use the “expected to” conditions on whether or not FIELDSET and LEGEND are mapped to these new display types you're creating, but don't use it when defining how the new display types are defined.

OK.

[zcorpan]

We decide to make it a re-usable feature invoked by CSS declarations. In that case, clean it up and design it as if we were intending to create that feature independently, just make sure it also fits the Web-compat requirements of FIELDSET/LEGEND so it can be used to describe them.

There is some tension between "clean it up" and "be web-compatible", I think, and I'm generally letting web compat requirements take precedence, since in my experience that is more likely to result in something that can be shipped.