search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 662 forks source link

Review HTML fieldset/legend spec #3094

Open zcorpan opened 6 years ago

zcorpan commented 6 years ago

I would appreciate CSS WG review of https://github.com/whatwg/html/pull/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 commented 6 years ago

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.

MatsPalmgren commented 6 years ago

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 https://github.com/whatwg/html/issues/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 https://github.com/whatwg/html/issues/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 https://github.com/whatwg/html/issues/3929.

zcorpan commented 6 years ago

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 #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 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 commented 6 years ago

+1 to everything fantasai said.

Additional points:

zcorpan commented 6 years ago

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 #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 #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 commented 6 years ago

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 commented 6 years ago

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/w3c/csswg-drafts/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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

I don't want us to:

zcorpan commented 6 years ago

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

I stand corrected. I'll fix, thanks!

zcorpan commented 6 years ago

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 commented 6 years ago

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.

zcorpan commented 6 years ago

@tantek also disagreed with methodology of "just spec what Chrome does"

I disagree with that methodology, too. I don't know what this is referring to, though?

MatsPalmgren commented 6 years ago

@fantasai

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. :)

display isn't a good fit for legends because it shouldn't actually change the box type. The only thing it should do is to position it in a special way. position:legend would be semantically more correct IMO. In both cases though, you'd need to compute it specially (as you suggested for fieldset), since we don't want <legend style="display:block"> (or <legend style="position:relative">) to reset its legendness.

In any case, your counter-proposal hinges on a non-existent appearance:none|auto property. We already tried to implement that in Gecko per CSS-UI only to have to backout the code after we found that it wasn't web-compatible. To be clear, I will object to implementing appearance:none|auto again in Gecko until WebKit/Blink has already shipped such a feature successfully to prove that it's web-compatible.

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 -webkit-appearance:fieldset and legend:auto affect the computed display value as you suggest. I just think that's unnecessarily complicated compared to letting those properties affect box construction directly with "behaves as" as currently drafted.

fantasai commented 6 years ago

@MatsPalmgren

display isn't a good fit for legends because it shouldn't actually change the box type. The only thing it should do is to position it in a special way. position:legend would be semantically more correct IMO.

position: legend makes sense, yeah. If position: relative is not a source of conflict, then that can be a good approach. I suspect it might be used to adjust the exact offset of the legend wrt the fieldset border, though... As for not changing the box type, inner and outer display types are two distinct concepts. It's clear that becoming a legend shouldn't change the inner type, but imho changing the outer type is a reasonable interpretation of what's happening--not unlike run-in (which is essentially a typical inline box with some special behavior).

In any case, your counter-proposal hinges on a non-existent appearance:none|auto property.

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 appearance is defined. Exactly how that happens is outside the scope of this particular issue: in any case, the property takes some as-yet-undetermined set of keywords, of which at least one of them is none and at least one of them is not.

That said, we could make -webkit-appearance:fieldset and legend:auto affect the computed display value as you suggest.

Why can't we use appearance:/-webkit-appearance: to replace legend:? Why does it need to be a new, separate property?

I just think that's unnecessarily complicated compared to letting those properties affect box construction directly with "behaves as" as currently drafted.

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. -webkit-appearance: fieldset is not a fitting way to introduce a new layout model: it's vendor-prefixed and its purpose is largely to control the visual appearance of a UI element, not to trigger a general-purpose layout feature.

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.

@zcorpan

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.

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 https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420743654 so I'm not sure what you're disagreeing with.

zcorpan commented 6 years ago

@frivoal

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.

Thanks, addressed in https://github.com/whatwg/html/pull/3934/commits/2eec031dbce5b9201cda0247507d823c5f120300

zcorpan commented 6 years ago

If position: relative is not a source of conflict, then that can be a good approach.

While 'position: absolute' and 'position: fixed' removes the legendness, 'position: relative' and 'position: sticky' do not, in browsers.

zcorpan commented 6 years ago

@fantasai

Why can't we use appearance:/-webkit-appearance: to replace legend:? Why does it need to be a new, separate property?

@MatsPalmgren wrote earlier:

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

fantasai commented 6 years ago

@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 -webkit-appearance property, in which case it is still irrelevant. The only case it's relevant is if you insist on defining fieldset-legend layout as a new CSS layout feature that can be independently invoked on any element using (specifically) the -webkit-appearance property, which I strongly disagree with as being a good approach.

MatsPalmgren commented 6 years ago

@fantasai

position: legend makes sense, yeah. If position: relative is not a source of conflict, then that can be a good approach.

It does conflict with relative, so you'd have to compute position: relative to position: relative legend, similar to your proposal for "fieldsetty". Anyway, I just wanted to point out that position is a better fit semantically. In practice, display:legend probably works and is simpler since display already has a two-value syntax, and UAs already have legend { display:block } in their UA sheets.

MatsPalmgren commented 6 years ago

I think the current fieldset/legend draft aims to:

  1. support fieldset/legend layout on all elements (with a few fieldset exceptions perhaps, e.g. <img>)
  2. make it possible to reset the fieldset/legend layout on fieldset/legend elements and display them according to display

(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.)

FremyCompany commented 6 years ago

FWIW I'm not in favor of the -webkit-appearance property affecting layout. This is not desirable.

zcorpan commented 6 years ago

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.

frivoal commented 6 years ago

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

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.

zcorpan commented 6 years ago

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.

Done: https://github.com/whatwg/html/pull/3934/commits/703ffff3f059b68ebdd82f7ad90d691db37f51fb https://github.com/whatwg/html/pull/4035

css-meeting-bot commented 6 years ago

The CSS Working Group just discussed fieldset.

The full IRC log of that discussion <fantasai> Topic: fieldset
<astearns> github: https://github.com/w3c/csswg-drafts/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
zcorpan commented 6 years ago

@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)?

patrickdark commented 6 years ago

Here's a proposal:

@namespace html url("http://www.w3.org/1999/xhtml");
html|fieldset { border-float-block-start: first-of-type("html|legend"); }
html|fieldset { border-float-block-start: none; }

It's generalizable. Get it working on fieldset and legend and treat its behavior on other elements like the appearance property: assumed to be supported generally at some indefinite point in the future.

tabatkins commented 6 years ago

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 r property only works on SVG circle elements, despite the fact that you can technically set it on any element.

SelenIT commented 6 years ago

turning it on can be restricted to solely the fieldset/legend elements

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 legend inside fieldset, and sometimes people suggest using fieldset just for this visual effect (example). Restricting the "magic" to these elements would encourage those people to keep (mis)using the fieldset element for this presentational purpose.

I'd prefer removing "the magical part" from this behavior, by defining it in more generic CSS terms (even mostly experimental by now, like backdrop-filter or mix-blend-mode). When those CSS features become more supported, browsers would be able to migrate from the current "magic" behavior to the visually equivalent non-magic one, and then drop the "magic" legacy altogether. I believe that explicit and reusable CSS features should eventually replace the historical "magic" artifacts, not the other way round. The history of display: flow-root, which also was previously a "magic" pecularity of the fieldset rendering, seems a good example of such process to me.

zcorpan commented 6 years ago

@patrickdark It would need to be first-of-type-that-is-not-floating-or-absolutely-positioned(html|legend)

https://html.spec.whatwg.org/multipage/rendering.html#rendered-legend

patrickdark commented 6 years ago

@zcorpan Ugh. A legend's default behavior is conditioned on unrelated CSS properties? What a mess.

There's always first-of-type-in-flow(html|legend), though I guess the whole proposal won't work either in light of @tabatkins comment.

@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 legend: none declaration would be more palatable if it were renamed to something like legacy-override: fieldset-legend. That's more generalizable while functionally still just a switch.

Another solution is to just fork the element and create something like fieldgroup. That'll be several years of polyfills to get behavior like <fieldset disabled=""/>, but there won't be any style baggage.

gibson042 commented 6 years ago

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 fieldset > legend:first-of-type (and therefore addressable by [author-overrideable] default styles).

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.

zcorpan commented 6 years ago

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.

SelenIT commented 6 years ago

Can't position: absolute/fixed and float be considered as "Author styles that disable special treatment" for the legend, similarly to the "Author styles that disable appearance" for the button from the form controls default rendering draft?

zcorpan commented 6 years ago

Oh I see. Yes, maybe.

zcorpan commented 6 years ago

Assigning this to @fantasai for now per https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-433912356

FYI, I will be on leave between 1 November and the end of the year.