- From: Simon Pieters via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Sep 2018 08:25:59 +0000
- To: public-css-archive@w3.org
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)](https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-417552188)) 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](https://github.com/whatwg/html/pull/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. -- GitHub Notification of comment by zcorpan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420558607 using your GitHub account
Received on Wednesday, 12 September 2018 08:26:05 UTC