- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Sep 2018 03:06:23 +0000
- To: public-css-archive@w3.org
> Using appearance: fieldset to create a new, general-purpose display type is awful. If the goal is to create a new general-purpose display type, add a new value to display. FYI, Gecko supports grid/flex/column layout of the `<fieldset>` contents by propagating those values to the inner anonymous box. I agree that `display:fieldset` + exposing the inner box with a pseudo for direct styling is probably cleaner but I wonder how web-compatible that would be at this point. > Creating a legend property just for this seems excessive. Why not re-use appearance if you want it magical (specific to LEGEND), or add a new outer display type to display if you want it more generally-applicable (e.g. to DIVs or whatever)? Setting `-webkit-appearance:legend` on an element that already has a value in the UA sheet (e.g. form controls) destroys its visual appearance (see https://github.com/whatwg/html/issues/3968). `display:legend` would have the same problem as for fieldset - how do you specify grid/flex layout of its contents? (But yes, I agree this new `legend` property needs to be in a CSS spec somewhere). > “In the absence of explicit margins in the inline direction, the element is expected to be positioned in the inline direction as follows” Use the justify-self property for this mapping. That's what it's for. Agreed, this is https://github.com/whatwg/html/issues/4013. (Fwiw, I've already implement a [prototype](https://bugzilla.mozilla.org/show_bug.cgi?id=1488228) mapping `<legend align>` to `justify-self` and it seems to work well.) > “The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value? Determining which box is the _rendered legend_ happens during box construction, so it seemed "too late" to change the computed value at that point. (I could be wrong.) > “The used value of the element's margins in the block-flow direction are expected to be zero.” I don't know what “expected to” means here. If we're defining a new layout model corresponding to some CSS syntax, it should be clearly normative. Also, if it's possible to make the margins useful, that might be something to look into. I agree that block-axis margins should not be ignored. Gecko currently support them, but WebKit/Blink doesn't, see https://github.com/whatwg/html/issues/3929. -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420496835 using your GitHub account
Received on Wednesday, 12 September 2018 03:06:25 UTC