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

Open
zcorpan opened this Issue Sep 10, 2018 · 26 comments

Comments

Projects
None yet
7 participants
@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

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

Contributor

fantasai commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 12, 2018

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.

MatsPalmgren commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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.

Member

zcorpan commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Sep 12, 2018

Contributor

+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 #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))
  • 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.

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

Contributor

frivoal commented Sep 12, 2018

+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 #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))
  • 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.

  • 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 #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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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.

Member

zcorpan commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Sep 12, 2018

Contributor

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.

Contributor

frivoal commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Sep 12, 2018

Member

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

css-meeting-bot commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

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

Contributor

fantasai commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

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.

Contributor

fantasai commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

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

fantasai commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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

I stand corrected. I'll fix, thanks!

Member

zcorpan commented Sep 12, 2018

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

I stand corrected. I'll fix, thanks!

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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.

Member

zcorpan commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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.

Member

zcorpan commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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

Member

zcorpan commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 12, 2018

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

MatsPalmgren commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

@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 #3094 (comment) so I'm not sure what you're disagreeing with.

Contributor

fantasai commented Sep 12, 2018

@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 #3094 (comment) so I'm not sure what you're disagreeing with.

zcorpan added a commit to whatwg/html that referenced this issue Sep 12, 2018

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

@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 whatwg/html@2eec031

Member

zcorpan commented Sep 12, 2018

@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 whatwg/html@2eec031

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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.

Member

zcorpan commented Sep 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

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

Member

zcorpan commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 12, 2018

Contributor

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

Contributor

fantasai commented Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 12, 2018

@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 Sep 12, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 13, 2018

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

MatsPalmgren commented Sep 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 13, 2018

Contributor

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

Contributor

FremyCompany commented Sep 13, 2018

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

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 13, 2018

Member

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.

Member

zcorpan commented Sep 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Sep 13, 2018

Contributor

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.

Contributor

frivoal commented Sep 13, 2018

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 added a commit to whatwg/html that referenced this issue Sep 14, 2018

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 14, 2018

Member

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:
whatwg/html@703ffff
whatwg/html#4035

Member

zcorpan commented Sep 14, 2018

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:
whatwg/html@703ffff
whatwg/html#4035

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment