-
Notifications
You must be signed in to change notification settings - Fork 689
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
Review HTML fieldset/legend spec #3094
Comments
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
Setting
Agreed, this is whatwg/html#4013. (Fwiw, I've already implement a prototype mapping
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. https://gist.github.com/zcorpan/711d7f7c199db74a0994f55da7935660
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: https://html.spec.whatwg.org/multipage/infrastructure.html#renderingUA
Any suggestion? :)
The intent here is to make percentage block sizes work.
Thanks.
Maybe. I'd like to spec it in a way that closely follows how it's implemented, though. |
+1 to everything fantasai said. Additional points:
|
Thanks @frivoal
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 <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. |
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.
Cool.
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:
|
I stand corrected. I'll fix, thanks! |
OK. |
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. |
I disagree with that methodology, too. I don't know what this is referring to, though? |
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. |
Thanks, addressed in whatwg/html@2eec031 |
While 'position: absolute' and 'position: fixed' removes the legendness, 'position: relative' and 'position: sticky' do not, in browsers. |
@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.) |
FWIW I'm not in favor of the |
Given the feedback so far, I plan to take out -webkit-appearance: fieldset and the 'legend' property from the Revamp PR, and put it in its own PR that is blocked from merging until we have figured out how we want it to work instead. |
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. |
|
The CSS Working Group just discussed The full IRC log of that discussion<fantasai> Topic: fieldset<astearns> github: https://github.com//issues/3094 <fantasai> zcorpan: A few weeks ago I did a project to specify rendering model of fieldset <fantasai> zcorpan: There's active implementaiton in gecko and chromium <fantasai> zcorpan: Remaining issue is finding a way for web developers to turn off the rendering model that fieldset employes <fantasai> zcorpan: There was a proposal to use -webkit-appearance for that, but would be open to other ideas <fantasai> florian: I remember fantasai filed a whole pile of issues against your spec <fantasai> florian: Have they all been resolved? <florian> fantasai: you got rid of the legend property? <florian> fantasai: I don't think there should be one <florian> zcorpan: we can look into that <fantasai> TabAtkins: We don't have opinions against or for 'appearance'. Do have an opinion on whether it should work on random other elements <fantasai> TabAtkins: If there's a case of "this is how it's turned on to fieldset/legend, and here's how to turn it off" that's fine <fantasai> zcorpan: Enabling on random elements was more of a side effect, not a goal <fantasai> zcorpan: I'm also working on appearance property, and don't think it's a perfect fit for fieldset <fantasai> zcorpan: It doesn't affect layout on other elements, just changes what's rendered, typically <fantasai> zcorpan: So would be open to probably adding new properties for opting out to the layout model for fieldset <florian> fantasai: I don't want to add to new properties that opt into a new useful layout model, but only work on one element <florian> fantasai: if the goal is to only have a switch that work on certain HTML element, appearance seems appropriate. <florian> fantasai: if we make a new property, it should be generally appicable <florian> florian: +1 <fantasai> zcorpan: So do we want it to be generally applicable, or do we want it to be limited? <fantasai> florian: The somewhat quirky version that's applicable to HTML is not nice to generalize as-is <fantasai> florian: IIRC it does strange things to broders <fantasai> fantasai: But isn't that what makes it special? Otherwise just use flexbox/gid <fantasai> zcorpan: There are various interesting layout effects, but main thing is placement over the border <fantasai> florian: clipping border is kinda weird <fantasai> fantasai: Seems reasonable to me <fantasai> fremy: Introducing a lot of stuff for this, and MS and Google agree that we don't want to add a generalizable thing. <fantasai> fremy: agree with fantasai, that if we're just trying to define for fieldset it's too much <florian> fremy: I'm not even sure we need a way to turn it off, because why would you use fieldset if not for that rendering <florian> fantasai: because fieldset has specific and useful semantics in form controls that you may very well want, but that doesn't mean you want that particular rendering model <fremy> minuting is great with zcorpan additions <fantasai> astearns: Sounds like y'all should have a hallway conversation or something, 'cuz we're done for today. <fantasai> Meeting closed. <pkra> Follow up to the meeting with the MathOnWeb CG. A simplified version of the document we presented is available on the GitHub wiki of the CG repository at https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations <pkra> Thanks again to the CSSWG for the kind invitation and good meeting! <astearns> Trackbot, end meeting |
@fantasai were you (or someone else) planning on making a proposal to replace "-webkit-appearance: fieldset and the 'legend' property" (that was taken out from the spec)? |
Here's a proposal:
It's generalizable. Get it working on |
We're not generally in favor of trying to extend the magic legend functionality to other elements. (I tried to do the same thing years ago, and ended up with basically the exact same solution as you.) All we really want is some switch to turn off the functionality; turning it on can be restricted to solely the fieldset/legend elements, like the |
For me, as an author, this sounds like a terrible mistake (with all due respect). Authors often ask for the visual effect similar to the default rendering of the I'd prefer removing "the magical part" from this behavior, by defining it in more generic CSS terms (even mostly experimental by now, like |
@patrickdark It would need to be https://html.spec.whatwg.org/multipage/rendering.html#rendered-legend |
@zcorpan Ugh. A There's always @tabatkins I got the impression from last week's minutes that some think the switch should be generalizable which is why this issue has gone back to the drawing board. Perhaps a Another solution is to just fork the element and create something like |
I bet the fraction of loaded pages that include a fieldset with a floating or absolute/fixed legend child before a legend child that is neither floating nor absolute/fixed is well below 0.001%, in which case it may be deemed web-compatible to simplify that aspect of the HTML Standard such that "rendered legend" becomes synonymous with matching Especially when one considers that the current definition and special treatment of "rendered legend" depends upon computed CSS styles, and therefore can change depending upon client treatment of and ability to access CSS. To see what I'm talking about, visit https://output.jsbin.com/bavowelixe in Firefox and use View > Page Style > No Style to disable the styles that exempt the fieldset's first legend. |
The point is that if the first legend is floated or abspos, it needs to not get the special treatment. Yes the web depends on this. Maybe less so about multiple legend children, that was just defined to match what browsers do. |
Can't |
Oh I see. Yes, maybe. |
Assigning this to @fantasai for now per #3094 (comment) FYI, I will be on leave between 1 November and the end of the year. |
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
The text was updated successfully, but these errors were encountered: