- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Sep 2018 22:27:10 +0000
- To: public-css-archive@w3.org
@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, the 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 special case of `inline`). > In any case, your counter-proposal hinges on a non-existent appearance:none|auto property. Call it -webkit-appearance, then, for the purpose of this discussion. As far as I'm concerned, they are both the same property unless for some very dramatic reason we can't alias them no matter how `appearance` is defined. Exactly how that happens is outside the scope of this particular issue: in any case, the property takes some as-yet-undetermined set of keywords, of which at least one of them is `none` and at least one of them is not. > That said, we could make -webkit-appearance:fieldset and legend:auto affect the computed display value as you suggest. Why can't we use `appearance:`/`-webkit-appearance:` to replace `legend:`? Why does it need to be a new, separate property? > I just think that's unnecessarily complicated compared to letting those properties affect box construction directly with "behaves as" as currently drafted. My concern is that we're using the situation of FIELDSET/LEGEND to create a new CSS layout tool, but choosing to do it poorly. IMO, if we're giving authors a tool to enable a new generally-useful layout feature via CSS syntax, we should do that in an intentional way—that fits into the design of CSS as a whole, as if the feature was _intended to be there_. `-webkit-appearance: fieldset` is not a fitting way to introduce a new layout model: it's vendor-prefixed and its purpose is largely to control the visual appearance of a UI element, not to trigger a general-purpose layout feature. Fieldset/legend layout, if it's reasonably controllable, is useful. I imagine authors are going to re-use it elsewhere if they're able to; and the current spec does enable them to. I'd rather have some magic involved with invoking the feature on FIELDSET/LEGEND than to turn the entire feature into an annoyingly awkward historical artifact. @zcorpan > There is some tension between "clean it up" and "be web-compatible", I think, and I'm generally letting web compat requirements take precedence, since in my experience that is more likely to result in something that can be shipped. Letting web-compat requirements take precedence is different from glossing over other design considerations where web-compat is not affected. I thought I was very clear about this point in https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420743654 so I'm not sure what you're disagreeing with. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420818680 using your GitHub account
Received on Wednesday, 12 September 2018 22:27:11 UTC