Summary
-------
I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to
turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref
simultaneously changes the behavior of the 'menulist-button' value, and shortly
the 'button-bevel' value.
Spec: None. We're reverse engineering Chrome and ignoring
https://drafts.csswg.org/css-ui-4/#appearance-switching
since the 'appearance' property defined there is not
web compatible.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480073
Preferences: layout.css.webkit-appearance.enabled
Platfrom coverage: All
Estimated release: 63 (tentatively)
Known webcompat impact: 19 out of 20 of the open -webkit-appearance
webcompat.org issues are fixed by this change.
The alias
---------
The primary concern currently is to get `-webkit-appearance: none` shipped to
fix a bunch of web compat issues and unblock geckoview. That said, previously we
tried to implement and ship the 'appearance' property with only the values
'none' and 'auto' (as per CSS UI 4), along with a '-webkit-appearance' alias.
That attempt was unsuccessful for various reasons, but mainly because cascading
of a '-moz-appearance' other than 'none'/'auto' would not replace a lower
specificity 'appearance' value, breaking current web content and user
expectations about how the properties should cascade.
This time around by aliasing '-webkit-appearance' to '-moz-appearance' our
implementation of '-webkit-appearance' will support all the values that
'-moz-appearance' supports, avoiding the funky cascading issues.
Changes in behavior for existing values
---------------------------------------
Aliasing means that we'll recognize and react to a bunch of other
'-webkit-appearance' values that sites set, so to minimize the chances of
undesirable changes on existing web content, we've also been changing the
behavior of some '-moz-appearance' values to more closely align with the way
that Chrome handles the values of the same name for '-webkit-appearance'. Some
of those changes have shipped. The two that haven't are guarded behind the same
pref that turns on the '-webkit-appearance' alias: 'menulist-button' and
'button-bevel'. (They probably don't need to be though, so we could potentially
ship those separately if desirable.)
Both 'menulist-button' and 'button-bevel' occur two orders of magnitude fewer
than 'none' as a '-moz-appearance' value in github repos, and almost all the
occurrences for the two values seem to be non-interesting.
menulist-button
https://github.com/search?o=desc&q=-moz-appearance+menulist-button&type=Code
I dug through hundreds of these and didn't encounter any instances
that would impact web content. The vast majority appear to occur in
forks of the Mozilla source or appear in a list of possible values in
csslint.js.
The change here makes us display the appearance of an entire (collapsed)
menulist, not just the drop marker to its right. That makes the change
here more substantial and so in principal breakage could be significant.
button-bevel
https://github.com/search?o=desc&q=-moz-appearance+button-bevel&type=Code
Again, I dug through hundreds of these with the same observation as
for menulist-button. Even in the places where it is used, border is
typically overridden meaning that there will likely be no visual
change for consumers.
Additionally, the difference between the way button-bevel currently
displays and how it will be changed to match Chrome is minimal.
Perhaps more significant is the usage count of the various values reported by
the crawl MS did for Edge:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/
Blink/Webkit have no equivalent to our old behavior for 'menulist-button' (show
a dropmarker) which indicates that demand hasn't been high enough for them to
add that functionality. Given that, I expect the number of sites using and
depending on our old 'menulist-button' behavior are extremely low.
Blink's 'square-button' (which behaves the same as our 'button-bevel') was only
used on 0.002% of the pages that they crawled, and again, the visual appearance
change we're making is minimal.
Further aligning '-moz-appearance' with '-webkit-appearance'
------------------------------------------------------------
I've filed a bunch of bugs for the differences that I'm aware of between the
behavior of '-moz-appearance' in Firefox and '-webkit-appearance' in Chrome, and
marked them as blocking this meta bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1481581
The possible uses and permutations of '-moz/webkit-appearance' are vast, so if
anyone is aware of anything significant that I may have missed please file a new
bug and make it block that meta bug.
I don't think fixing/not fixing any of the issues that that meta bug tracks so
far is likely to cause significant improvements/regressions for a significant
amount of web content, or prevent us from shipping the alias. (Comment here or
in the bugs if you disagree, please.) That said I intend to fix some of them
before 63 rides the trains to improved alignment between Firefox and Chrome, and
reduce the risk of shipping the alias (we have 16 days before the start of the
soft freeze/30 before uplift).
-Jonathan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
