- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Sep 2018 14:34:16 +0000
- To: public-css-archive@w3.org
> Do you have implementer buy-in for what you suggest?
My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins), and of the CSS-WG at large every time we discussed this, is that there's fairly strong agreement that we should have `appearance` with only `auto` `none`, with `auto` as the initial value (and no particular need for anything else in the UA stylesheet), plus a small set of additional values limited to those needed for for compat reasons, with a preference if compat allows for defining the other values to do the same as auto, so that they work for reverting a `none`, but not for turning arbitrary things into arbitrary other things. And I believe that everybody agrees that what is required for back compat is required, so we'll have to spec `-webkit-appearance` as well. We have not discussed whether the `auto` value needed to be excluded from the webkit prefixed version. I made the proposal above as a solution to combine `-webkit-appearance` with the set of values (and only these) defined by the compat spec with `appearance` as defined above. If there is no need for excluding the `auto` value from the prefixed version, we can simply alias the two. But the whole CSS-WG does have fairly strong agreement that we don't want to have a enormous list of values to cover all form controls in the UA stylesheet, and that the only way we've found to do that without resorting to undefined behavior is to have an `auto` value.
> It seems simpler to support the values necessary for web compat, and have -webkit-appearance be a simple alias
As a simple alias to what? I am not sure what you're proposing.
1. Alias `-webkit-apperance` to `appearance`, and both have an `auto` value, which is the initial value?
That's totally fine, as discussed above. But I don't think this is what you're proposing. More than happy to be mistaken.
2. Alias to an `appearance` property that takes the same limited set of keywords needed for web compat and only these?
That's not possible, as you cannot express the UA stylesheet using only the values listed as necessary for webcompat.
3. Alias to an unspecified `appearance` or `-other-vendor-appearance` property that takes the same limited set of keywords needed for web compat **plus** whatever each vendor wants to have to express the UA stylesheet?
If both properties don't actually have the same set of keywords, they're cannot really be strict aliases. But one could be a shorthand for the other or something like that. However <s>aliasing</s>shorthanding to an undefined thing feels really weird, as then you're not really defining how things work. And if you're going to <s>alias</s>shorthand to a property with a different set of values so that you can express the UA stylesheet, why not do what I said above, which is <s>aliasing</s>shorthanding to a defined thing, and use `auto` rather than a giant list of values? At least that way, Chrome could also implement the `auto` value, and try to remove all other values not needed for web compat, and we'd have a chance of converging on a finite set of values.
4. Alias to an unspecified `-other-vendor-appearance` property, and both properties that takes the same limited set of keywords needed for web compat **plus** whatever they need to express the UA stylesheet?
The still leaves the basic mechanism undefined, which not only feels weird, but also means that over time, we will get continuing pressure to align closer and closer with the market-share dominant player. This means that we're buying time, but in the long run, it isn't terribly different from the next one:
5. Forget about only supporting only the `-webkit-appearance` values needed for web compat, and just wholesale copy every value of the original `-webkit-appearance`, so that we can write the UA stylesheet with that?
Which `-webkit-appearance`? Blink and Webkit support different values. But even if we'd pick one (Blink, presumably), we still have problems:
1. The list is huge, and standardizing all that is going to be very painful
2. Many values in that list are meant to be used in the UA stylesheet by being applied to proprietary pseudo-elements. Are we going to standardize those as well? We'd have to, otherwise many values are useless, and many form controls cannot be given their look and feel.
3. Form controls look different on different browsers or on different platforms, and have different sub-components/proprietary pseudos. That is best left to the discretion of each vendor. And it evolves. So a fixed list is not desirable. And an everchanging list is not fun to try to standardize or to converge on.
--
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-421029292 using your GitHub account
Received on Thursday, 13 September 2018 14:34:18 UTC