[css-ui] 'auto' as the initial value for the 'appearance' property isn't web-compatible

[MatsPalmgren]

https://drafts.csswg.org/css-ui-4/#appearance-switching

Value: auto | none

For this testcase, the output in the Console in Chrome, Safari and Edge is:

div: none
select with -webkit-appearance:inherit: none
button: button
button w. -webkit-appearance:initial: none

I think that makes it clear that the initial value for -webkit-appearance is none in those UAs. I believe the initial value for appearance must be the same.

After implementing appearance according to spec in Gecko (with auto as the initial value and -webkit-appearance as an alias) we found that this isn't web-compatible.

We will now try with none as the initial value instead, and override that with appearance:auto in the UA sheet for elements that have a native theme in Gecko, <button> <select> etc.

[frivoal]

Sorry for the slow follow up.

The spec is not expected to be web compatible if used under the webkit prefix.

The different prefixed version by different browsers are different from eachother, as they have a separate value for lots and lots of replaced element / form control / parts of form controls, and they all have a different non standard set of these. It's not just the values of -foo-appearance that are non standards, but the actual things they represent.

Based on this, when drafting the spec for appearance, I concluded (and as far as meetings show, the CSSWG agreed) that what was currently implemented by browsers was not possible to standardize, and that we should try to build a saner thing that actually could be, so that in the long run it would take over. The result is replacing the long list of weird values with a single 'auto' value, and 'none'. Since that's not how the prefixed versions work, I am not surprised that implementing that and aliasing it to -webkit-appearance would be web incompatible.

However, would it still be web incompatible if you did not alias the two?

As far as I can tell, "something sane for all UAs and all platforms" and "something compatible with -webkit-appearance" are mutually exclusive goals.

We could make the change you suggest ('none' as the initial value instead, and override that with 'appearance:auto' in the UA sheet for elements that have a native look), but:

1. I suspect this would not be enough to make the appearance web compatible if aliased with the '-webkit-appearance'
2. It's a a kudge.

If 1. isn't actually true, and that's enough to make it possible to alias appearance and -webkit-appearance and have that be web compatible, maybe it's worth the ugliness.

However, I suspect that it will not and that you (unfortunately) will need to implement a both sane version of appearance, which is something like what's in the spec with more details filled in, and separately implement a -webkit-appearance that you'll be tweaking for years to come as you find more odd sites depending on yet another misunderstood aspect of it.

We should totally also specify that variant, since web compat requires it, but I hope we can also provide a clean and sane path forward to authors.

[frivoal]

ping @MatsPalmgren Any opinion on the above?

[MatsPalmgren]

FYI, we intend to implement -webkit-appearance with support for all values that Chrome supports. Sadly, that seems to be what is required to be web-compatible. I don't think we're particularly interested in implementing an unprefixed appearance property at this point. It would bring zero benefits with a lot web-compat risk. (If Chrome implements and ships that first, then we can reconsider.) As for standardization, I think it would probably be more useful to add -webkit-appearance to the compat spec.

However, would it still be web incompatible if you did not alias the two?

Right, we didn't try that. Assuming you cascade it separately and that appearance: none trumps the prefixed property(ies), then you get problems like:

input {
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}
input[type="checkbox"] {
  -webkit-appearance: checkbox;
  /* oops forgot to add the other properties here */
}

where the used value will be none. I'm also worried about about stray appearance: none that web developers added at some point and then forgot about. etc. Personally, I doubt an unprefixed appearance can be web-compatible in any form. (Sorry, I don't mean to discourage you.)

Anyway, auto must of course be the default for appearance if it's a separate property that trumps the other ones, so I withdraw my original request.

[frivoal]

Browser vendor representatives in the CSSWG, including mozilla, were very much not interested in a version of appearance with all the legacy values, and even a limited set got push back (button, textfield).

I think we need to revisit this discussion, taking into account compat data.

• Do we want/need the simpler/cleaner model focused on none and auto, possibly extensible to a few extra values, but explicitly not meant to have the full legacy list
• Do we want/need the full legacy list for company reasons?
• Do want/need both?

[frivoal]

I think it'd be good to talk about this at the upcoming paris F2F. To help, can we have:

• Info from Mozilla (ping @MatsPalmgren @dbaron) about what you are running into that makes you need more than auto and none
• usage data from Blink and Webkit (ping @tabatkins @RByers @grorg @smfr) on your prefixed variant
• usage data (and possible remaining problems) from Microsoft since for -webkit-appearance is supported in IE/Edge

[dbaron]

From Mats's link in #1250 (comment) at least one of the issues we were hitting was https://webcompat.com/issues/5910 . But probably the bigger one was https://bugzilla.mozilla.org/show_bug.cgi?id=1365614 .

[karlcow]

putting the dates here. So I can give all the webcompat cases to @MatsPalmgren and @dbaron prior to the meeting.

https://wiki.csswg.org/planning/paris-2017
Dates: Wednesday-Friday, August 2-4, 2017

[SebastianZ]

But probably the bigger one was https://bugzilla.mozilla.org/show_bug.cgi?id=1365614 .

Regarding this issue, the question is whether appearance values others than none and auto are already used in the wild.

The given example it obviously wrong, as it uses appearance: checkbox. If it looked like this, everything would be fine:

input {
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}
input[type="checkbox"] {
  -webkit-appearance: checkbox;
  -moz-appearance: checkbox;
  appearance: auto;
}

Sebastian