Re: [csswg-drafts] Review HTML fieldset/legend spec

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](https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821) than that.

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

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

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

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

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

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

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

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

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

> - “The used value of the 'padding' property is expected to be zero.” [I don't understand this requirement.](http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cfieldset%20style%3D%22border%3A%20solid%3B%20background%3A%20aqua%20content-box%22%3Etest%3C%2Ffieldset%3E)

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](https://www.w3.org/TR/css-align-3/#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.

-- 
GitHub Notification of comment by zcorpan
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420537565 using your GitHub account

Received on Wednesday, 12 September 2018 07:11:03 UTC