Intent to prototype: unprefixed appearance property

[Cameron McCormack]

Summary:

The appearance property allows authors to specify that a widget element (such as a form control element) is to be rendered as a regular element without its usual themed appearance. For example, `appearance: none` on a <button> prevents the element from being rendered with its usual (currently platform specific) push button appearance, and instead it is rendered using only CSS rules from the UA style sheet and those that the author supplies.

There are a number of differences from what the current prefixed -moz-appearance property supports:

* There is a new auto value, which means "render the element with its usual appearance". The UA style sheet will be updated to specify `appearance: auto` for all widget elements.

* Most of the values supported by -moz-appearance are not supported by appearance.

* The remaining values (apart from none and auto) that are still supported have limited effect: the button value has no effect on certain widgets (instead of having an effect on any element); and the checkbox, listbox, menulist, meter, progress-bar, radio, searchfield, and textarea values all behave like auto. The need to keep these values around with limited effect is a result of Simon Pieters' Web compatibility research, and allows style sheets like the following to keep working, without needing to support styling all elements with a given widget appearance:

input[type=checkbox] { -moz-appearance: none; }
input[type=checkbox].native { -moz-appearance: checkbox; } /* turn native checkbox appearance back on */

Once all engines support the new auto value, authors will be recommended to use that instead of specific values like checkbox.

Telemetry that has been added for -moz-appearance indicates that the new limited effects of these values, and the removal of the others, will be safe.

-moz-appearance and -webkit-appearance will be pure aliases of appearance.

Because we currently use -moz-appearance in UA style sheets (and various chrome style sheets for XUL elements and other front end features) to define the widget style to use for particular elements, we'll need a new mechanism to specify this. This will be a new chrome/UA-only property -moz-default-appearance, which accepts the same extended set of values that -moz-appearance currently does. As a couple of examples, the rule for <input> elements in forms.css will change from

input { -moz-appearance: textfield; ... }

to

input { appearance: auto; -moz-default-appearance: textfield; ... }

and the rule for the places sidebar in browser/themes/osx/places/organizer.css will change from

#placesList { -moz-appearance: -moz-mac-source-list; ... }

to

#placesList { appearance: auto; -moz-default-appearance: -moz-mac-source-list; ... }


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1620467

Standard: https://drafts.csswg.org/css-ui-4/#styling-widgets

Platform coverage: all

Preference: none; it's difficult to make a large change to an existing property like this and have all of the consequent changes be pref controllable

DevTools bug: none

Other browsers:

* Chrome: Changes landed ~3 months ago, targeting M84: https://bugs.chromium.org/p/chromium/issues/detail?id=963551
* Safari: https://bugs.webkit.org/show_bug.cgi?id=143842 is filed and internally tracked, and I am told "we have no immediate plan to do it, but it seems likely to be something we will do eventually".

web-platform-tests: https://wpt.fyi/results/css/css-ui?label=master&label=experimental&aligned&q=appearance

Secure contexts: Not restricted to secure contexts. This is not a feature that authors will be looking for and which we could hold back from insecure contexts to convince them to change, and Chrome also does not plan to restrict this to secure contexts.

Is this feature enabled by default in sandboxed iframes? yes