Closed Bug 1620467 Opened 4 years ago Closed 4 years ago

Support standard 'appearance' CSS property unprefixed

Categories

(Core :: CSS Parsing and Computation, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox80 --- fixed

People

(Reporter: tkent, Assigned: heycam)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, Whiteboard: [layout:backlog][layout:triage-discuss], [wptsync upstream])

Attachments

(13 files, 2 obsolete files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
Status: UNCONFIRMED → NEW
Ever confirmed: true

Kent, which of the <compat-auto> values is Chrome supporting?

Flags: needinfo?(tkent)
Priority: -- → P2

Kent, which of the <compat-auto> values is Chrome supporting?

Chrome currently supports all of them.
However, we might propose to drop some of them in the future.

Flags: needinfo?(tkent)

Thanks, we'll look at this soon.

Whiteboard: [layout:backlog]

FYI https://bugs.chromium.org/p/chromium/issues/detail?id=963551 is now fixed and looks like it's targeting M84 (reaching stable mid-July per https://www.chromestatus.com/features/schedule )

I think trying to coordinate on the timing on this can reduce compat problems, and allow for clearer messaging to web developers to start using unprefixed appearance.

Yes, it would be good to ship all this approximately the same time.

Whiteboard: [layout:backlog] → [layout:backlog][layout:triage-discuss]
Assignee: nobody → cam
Status: NEW → ASSIGNED

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Priority: P2 → P1
Depends on: 1642261

(Looks like I attached these to the wrong bug. Will move them across to bug 1642261 after updating.)

They have served their purpose.

XX Haven't done this yet. Also there are contradictory WPT tests --
one asserts that appearance is button on HTML button elements, another
that it's auto.

For none, button, textfield, and menulist-button (the four specific
values appearance values the spec supports that aren't treated as auto),
-moz-appearance rules in UA sheets, which are defining the inherent
appearance of widgets, are changed to

appearance: <value>;
-moz-default-appearance: <value>;

and those in non-UA sheets, which are using these values to obtain these
appearances on specific elements, are changed to:

appearance: <value>;

For all other values, rules are changed to:

appearance: auto;
-moz-default-appearance: <value>;

This includes all of the <compat-auto> values, plus menulist-button,
which doesn't behave any differently from menulist currently.

Emilio, if you have any good ideas about making this change safer in the absence of a pref, I'm happy to hear them.

Forgot to follow up on these two remaining non-standard values that may have
been being used to reset a <meter> or <input type=number> back to its
original appearance, but which telemetry showed no usage of.

See Also: → 1652930
Blocks: unprefix
Summary: Support standard 'appearance' CSS property → Support standard 'appearance' CSS property unprefixed
Pushed by cmccormack@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e31e608c3393
Part 1: Remove appearance use counters. r=emilio
https://hg.mozilla.org/integration/autoland/rev/7303087cc071
Part 2: Add unprefixed appearance property and make -moz-appearance and -webkit-appearance be aliases. r=emilio
https://hg.mozilla.org/integration/autoland/rev/d96951bf852e
Part 3: Defer to -moz-default-appearance when appearance is auto. r=emilio
https://hg.mozilla.org/integration/autoland/rev/7acbe8938c4e
Part 4: Change internal uses of -moz-appearance to appearance and -moz-default-appearance. r=emilio,webcompat-reviewers,geckoview-reviewers,preferences-reviewers,ntim,agi,miketaylr
https://hg.mozilla.org/integration/autoland/rev/71e7a079d3ad
Part 5: Remove appearance values not used by the browser or Web content. r=emilio
https://hg.mozilla.org/integration/autoland/rev/9247a06c2203
Part 6: Mark appearance values that are only used internally as chrome-only. r=emilio
https://hg.mozilla.org/integration/autoland/rev/7359d555bd1b
Part 7: Avoid exposing `appearance: range-thumb` to content. r=emilio
https://hg.mozilla.org/integration/autoland/rev/33a0e212af05
Part 8: Make `appearance: button` behave like auto on various elements. r=emilio
https://hg.mozilla.org/integration/autoland/rev/d0897b5ff3e4
Part 9: Make `appearance: textfield` behave like auto except on search and number inputs. r=emilio
https://hg.mozilla.org/integration/autoland/rev/2d55f97dbe38
Part 10: Make remaining appearance values behave like auto. r=emilio
https://hg.mozilla.org/integration/autoland/rev/de14ecb5046a
Part 11: Re-order Appearance values. r=emilio
https://hg.mozilla.org/integration/autoland/rev/4b04d694fb5c
Part 12: Hide range and number-input appearance values from content. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24640 for changes under testing/web-platform/tests
Whiteboard: [layout:backlog][layout:triage-discuss] → [layout:backlog][layout:triage-discuss], [wptsync upstream]

The upstream PR here didn't merge because update-built-tests failed; this runs the build scripts and checks there's no diff. In this case the diff was:

diff --git a/css/css-ui/webkit-appearance-button-001.html b/css/css-ui/webkit-appearance-button-001.html
index cdd69ba563..c71a914723 100644
--- a/css/css-ui/webkit-appearance-button-001.html
+++ b/css/css-ui/webkit-appearance-button-001.html
@@ -1,3 +1,7 @@
+<!-- DO NOT EDIT THIS FILE.
+Edit the appearance-* file instead and then run:
+    ./tools/appearance-build-webkit-reftests.py
+-->
 <!DOCTYPE html>
 <meta charset="utf-8">
 <title>CSS Basic User Interface Test: -webkit-appearance: button</title>

So there are a couple of possibilities here. One is to update that file to match the output of the build script. The other one is to stop the build script thinking it owns that file e.g. by moving it. Note that the generated files do need to be checked in; we don't build tests at runtime.

In terms of the mechanics of this, you can either push a change here with the same bug number, in which case the sync will add it to the PR, or you can push a change to the PR branch on GitHub in which case the sync will sync-back that change later.

Flags: needinfo?(cam)

Thanks, I didn't realize things would break if I didn't add the webkit-appearance-* test without using the script.

Upstream PR merged by moz-wptsync-bot
Flags: needinfo?(cam)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: