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
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
