- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Sep 2018 07:13:13 +0000
- To: public-css-archive@w3.org
+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 https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-417552188)
* 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.
* 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.
* 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 https://github.com/w3c/csswg-drafts/issues/2406), it should be possible to reproduce that sort of layout with 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.
--
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420538145 using your GitHub account
Received on Wednesday, 12 September 2018 07:13:15 UTC