Issue 513516  is about measuring usage, doing that ASAP would be a good idea.

Related to this compat issue: https://github.com/webcompat/web-bugs/issues/7309

Also here is a related Mozilla issue with more compat links: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555

Current usage numbers from chromestatus for the following added in  Issue 513516 

- none: 8.63%
- not none: 0.25%
- button: 6.33%
- caret: 0.05%
- checkbox: 0.24%
- menulist: 0.10%
- menulist-button: 0.13%
- listbox: 0.09%
- radio: 0.15%
- searchfield: 0.05%
- textfield: 4.26%

Is the first a subset of the second?
- textfield: 4.26%
- not none: 0.25%
Or are they mutually exclusive (basically meaning, "the unmentioned rest")?

It's looking like this is pretty important for interop.  Eddy, do we have any mechanism for internal CSS properties that can used only from within our UA stylesheet?

I see there's something for internal values (which relies on calls to IsUASheetBehavior), but I don't see anything for internal properties.  Perhaps that wouldn't be too hard to add to the parser (and just hide such properties from CSS OM)?

If so then ideally I think we'd switch our form control implementation to use such an property, and implement -webkit-appearance behavior for only the bare minimum necessary for web compat (probably 'none', maybe a few other special cases).

I'd like to at least figure out what work this would entail and (if it were to be important enough to get prioritized) what team(s) would own the different pieces.

Perhaps we could drop handling of -webkit-appearance incrementally on a control by control basis?  I suspect there are a lot of control types which really don't need it (or need it only for the 'none' value).

Related twitter thread: https://twitter.com/RickByers/status/913528773642997760

We seem to have -internal prefixed pseudo elements already (e.g. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/html.css?l=630), so there's precedent for having things like that. AFAIK there isn't a full property that's internal-only right now though.

In terms of effort required to add a new internal property - I imagine it'd be similar to adding a new property in general. If most of the implementation is already there (say, making -webkit-appearance internal-only), then as you say, we'd  need to change the parser so that the property is rejected when being set, and hide getting it from the CSS OM. I'm not sure the effort to hide thing from the CSS OM, that code is pretty complicated...

Maybe instead of an internal property, it would be simpler to rely on an internal pseudo element?  Eg. we'd change the implementation of -webkit-appearance to permit the unusual usage only when applied to some "-internal-form-control" pseudo (which is only parsed in UA mode)?

Maybe, since there are already internal pseudos? My knowledge of pseudos is also a little fuzzy - I'm not sure how they get styled after being parsed..

Marking this as BlockedBug. Seems to be part code, part spec. Probably needs some management from a TL to decide what to do.

FYI Firefox intends to unship a bunch of Gecko-specific values.

https://groups.google.com/forum/#!topic/mozilla.dev.platform/odBz2i8xnno