Join GitHub today
Review HTML fieldset/legend spec #3094
I would appreciate CSS WG review of whatwg/html#3934
First glance comments:
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.
FYI, Gecko supports grid/flex/column layout of the
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.)
I agree that block-axis margins should not be ignored. Gecko currently support them, but WebKit/Blink doesn't, see whatwg/html#3929.
Thank you for the feedback @fantasai!
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.
Unfortunately, that is not web compatible. Web pages set 'display' to something and expect the fieldset magic to still be there.
I'm happy to have it be moved elsewhere when it has stabilized.
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.
I think this wouldn't match how it's implemented.
The padding is used for the anonymous fieldset content box instead.
What @MatsPalmgren said.
If an author sets inline-size to auto, it should still shrink-wrap. I can look at the wording, thanks.
Yeah, we can do that. I haven't yet figured out how justify-self interacts with margins.
"Expected" is a normative keyword in the rendering section:
Any suggestion? :)
The intent here is to make percentage block sizes work.
Maybe. I'd like to spec it in a way that closely follows how it's implemented, though.
+1 to everything fantasai said.
We should sort this out, I agree. I hope to be able to help work on this soon.
No, it doesn't. Form controls are not defined to be replaced elements. See https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements
Well, we also need a value that is not 'none' that fieldset has by default.
"Otherwise , use the computed value." -- what is unclear?
I dunno, fieldset is pretty funky. But if you figure something out that browsers are willing to implement, then sure.
Let's talk. This is a thorny but important issue.
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,
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
Maybe, but that value might be
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
Also, boxes, not elements, establish formatting contexts. In the case of
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
The CSS Working Group just discussed
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
<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
<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.
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
The Web-compat issue is interesting. I definitely don't like using
If we need
Is it a Web-compat requirement that legends which are not the “rendered legend” be inline-level? Because if not, then the
Thanks, I'll follow up there.
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
See response to Mats, above.
I think that's incorrect, since Firefox masks the inline-start/end edges just fine: testcase
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.
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.
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.)
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...
If we don't want to make this a re-usable CSS feature, btw, the easiest way to control things would be with
Basically I'm saying we choose one of the following:
I don't want us to:
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.
In any case, your counter-proposal hinges on a non-existent
I think it's rather pointless to discuss a fieldset/legend proposal that builds on a feature that (so far) isn't web-compatible.
That said, we could make
Call it -webkit-appearance, then, for the purpose of this discussion. As far as I'm concerned, they are both the same property unless for some very dramatic reason we can't alias them no matter how
Why can't we use
My concern is that we're using the situation of FIELDSET/LEGEND to create a new CSS layout tool, but choosing to do it poorly. IMO, if we're giving authors a tool to enable a new generally-useful layout feature via CSS syntax, we should do that in an intentional way—that fits into the design of CSS as a whole, as if the feature was intended to be there.
Fieldset/legend layout, if it's reasonably controllable, is useful. I imagine authors are going to re-use it elsewhere if they're able to; and the current spec does enable them to. I'd rather have some magic involved with invoking the feature on FIELDSET/LEGEND than to turn the entire feature into an annoyingly awkward historical artifact.
Letting web-compat requirements take precedence is different from glossing over other design considerations where web-compat is not affected. I thought I was very clear about this point in #3094 (comment) so I'm not sure what you're disagreeing with.
added a commit
Sep 12, 2018
Thanks, addressed in whatwg/html@2eec031
@MatsPalmgren wrote earlier:
@zcorpan That looks like a feature request, not a Web-compat issue nor a requirement in handling FIELDSET/LEGEND. If we go down the path of supporting FIELDSET/LEGEND rendering only for FIELDSET/LEGEND elements, then it's irrelevant. If we go down the path of introducing a new, re-usable CSS layout feature for fieldset-legend layout, then (as I said multiple times) such a layout feature should be introduced through a property that's intended for controlling layout models, not through the
It does conflict with
I think the current fieldset/legend draft aims to:
(My prototype implemented both and shows that it's easy to implement, fwiw.)
Perhaps we should decide that first, to ensure that we're talking about the same thing. :-)
(I'm in favor of supporting both.)
referenced this issue
Sep 13, 2018
I agree it is not true with grid as it is today, but I think it could be made true with subgrid, with some minor (and generally useful) tweaks compared how the spec is now. But mostly, I agree with your overall point: if this is not restricted to back compat for FIELDSET/LEGEND elements and is meant as a generic layout mechanism, that mechanism should be something that fits well with CSS. The general approach you've been proposing in earlier comments makes sense to me, and this thread is already long, so I'll try to convince you offline it could also be done with tweaks to subgrid; I'll drop this point if you prove me wrong; and raise it on grid if it turns out I'm onto something.