- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Aug 2018 05:00:34 +0000
- To: public-css-archive@w3.org
Following up from the points I make above, I think the `-webkit-appearance` as described in https://compat.spec.whatwg.org/#css-non-aliased is problematic, as it's trying to take an easier path that doesn't really exist, and leads to contradictions. > The initial value must be none Therefore, it has an initial value. Therefore it has a value on all elements, and isn't something like a shorthand. In the absence of author styles, the value is either `none`, or what the UA stylesheet specifies for each form control. Since `none` is expected to suppress the native look and feel of every form control, form controls that do have a native look and feel must be set to some value other than `none`. Let's see what that value can be. > These values must be supported: […] The UA stylesheet can use these, and the corresponding form controls will have their native look. So far so good. (note that it is neither a giant list, nor includes auto) > More values may be supported, but [...] Ok, let's see what the restrictions are. > The appearance property must not be supported, since it is not web-compatible as currently defined I believe this argues against having an `auto` value, since that is the main difference. So there cannot be a neutral/magic/normal/auto value, that just let form controls look like their normal selves without specifying what that self is. > Implementers are encouraged to only support values that are necessary for web compatibility As a mechanical consequence of the previous points, implementers either have to ignore that recommendation and do the full giant list anyway, or add `auto` (but there's a must against it), or decide that they will not have a native appearance any other form control than those listed in the short list of required values (plus the few more values that should be added to that list for web compat). ---- I don't believe that the intention of this piece of text was to make a recommendation that is impossible to follow, nor that it intended to limit the list of form controls available on the web to just 13+ε types. This means that that definition is broken. ---- Here's what I suggest we do: 1. Spec both `-webkit-appearance` and `appearance` 2. Limit the values of `-webkit-appearance` to `none` and the values needed for web compat, using those listed in https://compat.spec.whatwg.org/#css-non-aliased as a starting point 3. Do **not** define that `-webkit-appearance` has an initial value. Instead, define it as a shorthand of `appearance`. This means `appearance` may have values that cannot be expressed in `-webkit-appearance` (as needed for the UA stylesheet), and `-webkit-appearance` can be limited to the values that are required for web compat. 4. Define the values of `appearance` to be, `none`, `auto`, plus all the values that `-webkit-appearance` has. 5. Make `auto` the initial value of `-webkit-appearance` Optional steps: 6. If we only care about the web compat values for the sake of undoing an earlier `none`, and not for the sake of turning any arbitrary element (including form controls) into any other arbitrary form control, we can define that the effect of the compat values is the same as auto. 7. If we need it for compat reasons on the OM, we could make `auto` compute to `none` on non form controls. 8. If we need it for compat reasons on the OM, we could make `auto` compute to the appropriate web compat value on the appropriate form controls. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-417552188 using your GitHub account
Received on Friday, 31 August 2018 05:01:06 UTC