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.

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.

ping @MatsPalmgren Any opinion on the above?

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.

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?

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

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 .

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

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

@karlcow CSS F2F in Paris starts tomorrow. If you haven't had the chance yet to give webcompat cases to @MatsPalmgren and @dbaron, now would be a good time.

@frivoal
Most of the case I met for webcompat are documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368555#c4 and subsequent comments.

@karlcow I think that's not the list that we needed -- we need the list of compat problems that caused @MatsPalmgren's patch to be backed out.

(And I'd also note that I'm skeptical of things being classified as a "compat problem" if they're reported by the developer of the site rather than a user of it.)

The CSS Working Group just discussed CSS UI 4 and appearance, and agreed to the following resolutions:

• RESOLVED: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.

In Edge we do not need a behavior more complex than if (appearance == none) { A() } else { B() } anywhere but this one exception:

• When -webkit-appearance is none, webkit based browsers do not show the action part nor does it consume space.
• When -webkit-appearance is not the default, webkit based browsers do not show the action part but it does consume space.

@dbaron

(And I'd also note that I'm skeptical of things being classified as a "compat problem" if they're reported by the developer of the site rather than a user of it.)

If you are talking about codepen stuff, it's usually me trying to reduce real issues.

The backout was generated by a new issue we didn't have in webcompat (aka not reported by us). I guess we could not know about them without having the change made. When @MatsPalmgren released its build, I tested the previous issues and it was working.

Before the backout (aka before the new issue) I had mentioned that for GECKO

• -webkit-appearance: none should behave like it does on webkit
• appearance: none is used in code like an alias of -webkit-appearance
• -moz-appearance: none can not be removed.

So it looks like the options are:

1. Keep appearance: none | auto; and accept that it breaks use cases like the one mentioned earlier.
2. Let unrecognized keywords map to auto.
3. Change the none keyword to something else.
4. Change the property name.
5. Change initial value to none and overwrite it in UA style sheet with auto.
6. Remove the property from the spec.

Do I miss other options?

Sebastian

Paper trail https://log.csswg.org/irc.w3.org/css/2017-08-03/#e845293

1. given firefox had to remove it from their browser, this is probably not acceptable
2. would work if webkit browsers agreed to fix the case mentioned in my comment above
3. would defeat the reason why we want this property in the first place.
4. would defeat the reason why we want this property in the first place.
5. doesn't solve the problem reported by Mozilla.
6. doesn't solve anything either because we would need to specify the webkit one then.

There is also option 7:

7. create a list of keywords that browsers should support for the property and mention they should all behave like "auto" but may have other effects in some cases (we will try to document such cases; the only one I am aware is the one mentioned above)

I'd like to make progress on this. It seems to me that what @FremyCompany suggested in #1250 (comment) is a good way forward. We can do it "option 2" style, and accept any keyword for the auto behavior, or option 7 style, and white-list what we accept.

I think I lean towards white-listing the things that should behave as auto, so that if we ever decide we want to introduced some values with another behavior, we're not stuck, but this is merely a preference, and I'm happy to go with something else if there's implementer consensus.