- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Aug 2018 09:09:38 +0000
- To: public-css-archive@w3.org
Starndardizing -webkit-appearance means explaining form controls with it in the UA stylesheet, and having the full list of values and pseudo elements to go along, since that's how it works in Blink/Webkit. The feedback I've heard in the csswg from all browsers so far was that people were not willing to do that, because it is a very leaky abstraction: the list was gigantic (and includes pseudos elements) to cover every imaginable form control and sub-component of form control, but also it needs to evolve each time we come up with a new form control, and isn't even necessarily the same on different platforms. Maybe that has changed, but then we need to realize that this cannot be limited to just specifying and/or unprefix webkit-appearance with the `none` value and a handful of other values. If we actually want to do the same thing, we'll need to go through a giant list of things that include stuff like `searchfield-cancel-button` or `sliderthumb-horizontal`, and also implement all the pseudo elements to go with it. If we don't do that, the property doesn't work standalone. As far as I understand, web compat efforts around -webkit-appearance so far have not been that, and instead rely on the existence of some other unspecified mechanism (-moz-appearance) to explain the rest of the form control's appearance, that `-webkit-appearance` overrides (in an undefined way) when it has a specified value. A normal css property needs to have a computed value on all elements, and the few values that have been found needed for web compat are insufficient to cover all elements. We could specify that `-webkit-appearance` is not a regular property, but actually some kind of shorthand to a non specified property, and in that way, limit the values we support in `-webkit-appearance` to those needed by cross-browser web compat. I don't object to doing that, but specifying the shorthand without the longhand feels a little weird. That said, we could prioritize that, since it is needed for compat, and worry about that rest later. I suspect that for "the rest", there's only two alternatives though: * one that uses auto (in addition to the few values needed for compat) to explain form control behavior in general * one that has the full laundry list of everything imaginable, and comes with a bunch of pseudos elements. > and I think I can safely say that this goes for Mozilla as a whole I don't know. In previous CSS meeting representatives from Mozilla have specifically pushed back to having any other value than `none` and `auto`. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-417247523 using your GitHub account
Received on Thursday, 30 August 2018 09:09:39 UTC