Mats Palmgren (inactive) Reporter
	Description • 7 years ago

The initial attempt at supporting [-webkit-]appearance (bug 1333482)
failed miserably because it's simply not web-compatible in the way
we first thought and how the CSS UI spec describes it.

I now believe that in order to be web-compatible we must implement
the *full* set of -webkit-appearance values.  Here's one list I've
found:
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-_webkit_appearance

We should also NOT support the unprefixed appearance property
unless Chrome/Safari also does so first, because doing so
unilaterally will inevitably lead to web-compat issues.

I think it's probably best to make -moz-appearance an alias for
-webkit-appearance (or vice versa), and then add the missing
-webkit-appearance keywords that we don't yet have.

	Mats Palmgren (inactive) Reporter
	Comment 1 • 7 years ago

I note that an earlier attempt at aliasing was backed out in bug 1249134.
The reason given was "-webkit-appearance:none works differently on
checkbox/radio controls".  However, we have now fixed that in bug 605985.

Daniel/Mike do you recall if there were other incompatibilities?

	Marco Zehe (:MarcoZ)
	Comment 3 • 7 years ago

Making bug 1349835 dependent on this one since we need to make sure if anything other than input type checkbox causes any accessibility curn. Mats' WIP patch in there fixes the bug in case of appearance: none;. Just want to make sure we track all of this in sync.

	Karl Dubost💡 :karlcow
	Comment 4 • 7 years ago

I'll try to document all the cases I meet/met (new and old).

leroy-merlin - mobile site
https://webcompat.com/issues/7064
https://codepen.io/webcompat/pen/awzPbw

relies on 

select {
	-webkit-appearance: initial;
}

to remove the widget, aka default to -webkit-appearance: none;

	Karl Dubost💡 :karlcow
	Comment 5 • 7 years ago

Only -webkit-appearance: none is provided.
This is the most common case.
https://webcompat.com/issues/7091


#LANG_FORM select { -webkit-appearance: none; } 

The fix we can usually recommend is:
    provide -moz-appearance: none;

	Karl Dubost💡 :karlcow
	Comment 6 • 7 years ago

-webkit-appearance: none and appearance: none are provided.
https://webcompat.com/issues/7524

for the site bet365.com on mobile

```css
.mmm-PreferencesRow_List {
	width: 100%;
	border: 0;
	background-color: #ddd;
	font-size: 15px;
	color: #666;
	line-height: 20px;
	padding: 22px 11px 7px;
	margin-top: -22px;
	background-clip: content-box;
	-webkit-appearance: none;
	appearance: none;
}
```

	Karl Dubost💡 :karlcow
	Comment 7 • 7 years ago

Same than previous comment
-webkit-appearance: none and appearance: none are provided.
https://webcompat.com/issues/7612

	Karl Dubost💡 :karlcow
	Comment 8 • 7 years ago

https://webcompat.com/issues/7760
-webkit-appearance: none and background image.

```css
.selects-container select {
	margin: 0;
	border-radius: 3px;
	-moz-border-radius: 3px;
	-webkit-border-radius: 3px;
	width: 130px;
	padding-left: 10px;
	-webkit-box-sizing: border-box;
	-moz-box-sizing: border-box;
	-webkit-appearance: none;
	box-sizing: border-box;
	height: 40px;
	color: #a2a2a2;
	font-size: .9em;
	font-weight: normal;
	overflow: hidden;
	background: url(../images/website/select-arrows.svg) no-repeat 115px 12px #282828;
	border: 0;
}
```

	Karl Dubost💡 :karlcow
	Comment 9 • 7 years ago

https://webcompat.com/issues/1006#issuecomment-181161213
https://codepen.io/anon/pen/QyJMGx


about -webkit-appearance: button
and   background-image invisible on Gecko.


#areaNavi select {
    …
    -webkit-appearance: button;
    -moz-appearance: button;
    appearance: button;
    …
    background: url("/iphone/img/icon_sort.png") no-repeat scroll 100% 50% transparent !important;
    background-size: 7px 9px !important;
    …
}

On WebKit and Blink, "-webkit-appearance: button" becomes "none". To note that the default select is "-webkit-appearance: menulist-button"

On Gecko, the -moz-appearance: button is a button and so the image is not displayed. To note that the default select is "-moz-appearance: menulist"

(the site has changed design since)

	Karl Dubost💡 :karlcow
	Comment 10 • 7 years ago

Similar to the previous comment from
https://webcompat.com/issues/1005#issuecomment-120774729


div.domModule table td select {
    …
    background-color: transparent;
    background-position: 97% 50%;
    …
    -webkit-appearance: button;
    -moz-appearance: treeitem;
    appearance: button;
    background-image: url(/common/img/bg_dom_select_arw.png);
    background-repeat: no-repeat;
    background-size: 14px 14px;
    -webkit-background-size: 14px 14px;
}


people seems to use -webkit-appearance: button without realizing that it means -webkit-appearance: none while -moz-appearance: button or treeitem in this case is working.

	Karl Dubost💡 :karlcow
	Comment 11 • 7 years ago

Other cases have been documented on https://groups.google.com/d/msg/mozilla.dev.platform/oZ9cPF8Y1pE/LiSUtpeHBwAJ

	Karl Dubost💡 :karlcow
	Comment 12 • 7 years ago

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1357655 about -webkit-appearance: inherit.

	Karl Dubost💡 :karlcow
	Comment 13 • 7 years ago

In the current state of YouTube.
This is a case where `-webkit-appearance: none` will break things once implemented in Firefox. 
https://webcompat.com/issues/8034#issuecomment-326163969

putting it here as a reminder.

	Karl Dubost💡 :karlcow
	Comment 14 • 7 years ago

input[type="checkbox"] {
	background-image: url("https://ir.ebaystatic.com/rs/v/u4v4rbewii4nxcrsboppckq4520.png");
	background-position: -28px -2px;
	background-attachment: scroll;
	background-size: auto 33px;
	background-clip: border-box;
	background-origin: padding-box;
	background-repeat: no-repeat;
	border-width: 0;
	height: 32px !important;
	margin-left: 5px;
	margin-right: 0;
	vertical-align: middle;
	width: 32px !important;
	display: table-cell;
	-webkit-appearance: none;
	padding: 16px;
	box-sizing: border-box;
	background-color: initial;
}

	Louis Chang [:louis]
	Comment 15 • 7 years ago

Hi mats,

Since bug 605985 and bug 1352238 are fixed, I think we are good to make -webkit-appearance an alias for -moz-appearance (or vice versa) first?
Or is there any other concerns that I miss to take into account?

	Karl Dubost💡 :karlcow
	Comment 16 • 7 years ago

I don't think it's possible to blindly alias -webkit-appearance with -moz-appearance, except for the none value. 

Also note that there's work going on Chrome side to determine which values they could drop. 
https://bugs.chromium.org/p/chromium/issues/detail?id=767757

In September 2017, with Mike and Eric, we check all the combinations and their behavior and it's a bit hectic. 
* form elements
* vs style attributes -webkit-appearance / -moz-appearance
* with variation of borders and background
See https://miketaylr.com/bzla/webkit-appearance.html


Our WebCompat position (extracted from our threads about the topic):

* Removing -moz-appearance is an issue.
* Sometimes the CSS cascade doesn't help resolving the web compatibility issue.
* -webkit-appearance: none is the top priority (with side effects related to background and border)
* Go step by step to implement/allow other values for -webkit-appearance. Rinse and Repeat.

	Mike Taylor [:miketaylr]
	Comment 17 • 7 years ago

Here's a portion of an email reply I sent a few weeks back that is relevant to the idea of aliasing (vs removing):

> The only question I have is if we should remove -moz-appearance (for web
> content) or if we should expose it as an alias for -webkit-appearance.
> (Whichever breaks the web the least has my vote.)

I think removing -moz-appearance is problematic. It's not uncommon for popular sites to serve different stylesheets to different browsers (based on UA strings).

Aliasing might be possible, with some kind of intelligent mapping between similar-ish values. This would also possibly fix the issue where sites server different values for -moz-appearance and -webkit-appearance[1]:

[1] https://webcompat.com/issues/1005#issuecomment-120774729

div.domModule table td select {
    [...]
    -webkit-appearance: button;
    -moz-appearance: treeitem;
    appearance: button;
    background-image: url(/common/img/bg_dom_select_arw.png);
    [...]
}

I suppose the alternative is supporting both, but preferring -webkit-appearance (breaking the cascade...). Note: we don't have evidence that this pattern is wide-spread. But it's non-theoretical, and possibly something that could be researched via HTTP archive or similar.

Whatever we decide, some time baking in non-release builds would be good to see what gets fixed and what pops up as site bustage.

> Fwiw, implementing the extra -webkit-appearance values shouldn't be much
> work (I think).  I've looked at them briefly and they appear to be
> slight style/behavior-variations of well-known controls.

If they could be aliased to well-known controls, or a single "base" value, that seems reasonable, perhaps.

> The important thing is to *recognize them as valid values* to avoid
> using a value from some other rule, which is what causes web-compat
> issues.  If they look/behave exactly as in Chrome is unimportant as long
> as they are usable; for example, we could implement 'square-button' as
> an alias for 'button'.

Here's a test page with the known values https://miketaylr.com/bzla/webkit-appearance.html. Most of them are nonsense (and some are sensitive to border/bg image properties -- see the toggle buttons on the top right).

FWIW, the latest Edge Mobile only supports the following:

-webkit-appearance: none on radio/checkbox suppresses the widget, and for <select> hides the dropdown arrow. <select> seems to be sensitive to more values and hides the dropdown.

That's a good place to start a first implementation, I think. The majority of our bugs fall into the following categories:

-webkit-appearance: none + bg/border to style a custom checkbox
-webkit-appearance: none + bg/border (sometimes on parent elm) to style a custom select (so we end up painting 2 dropdown arrows....):

e.g., see images @ https://webcompat.com/issues/7064

-webkit-appearance: button on select to hide the dropdown arrow (treated as none, at least if you look at computed style)

Support for that would solve the majority compat cases.

	Mats Palmgren (inactive) Reporter
	Comment 18 • 7 years ago

(In reply to Mike Taylor [:miketaylr] (58 Regression Engineering Owner) from comment #17)
> I think removing -moz-appearance is problematic. It's not uncommon for
> popular sites to serve different stylesheets to different browsers (based on
> UA strings).

Fair enough.  I guess we can do that as a separate bug later in any case.

> I suppose the alternative is supporting both, but preferring
> -webkit-appearance (breaking the cascade...).

I think we should try with a regular alias to begin with.
I'm hoping / expecting that will work out just fine.
(i.e. make -webkit-appearance the property name, with -moz-appearance
as an alias, so that we serialize to -webkit-appearance)

> Here's a test page with the known values
> https://miketaylr.com/bzla/webkit-appearance.html. Most of them are nonsense
> (and some are sensitive to border/bg image properties -- see the toggle
> buttons on the top right).

Right, specifying some properties such as background / border turns
off the native theme for some values of -moz-appearance:
http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/widget/nsNativeTheme.cpp#345-354
http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/widget/windows/nsNativeThemeWin.cpp#2091-2100
http://searchfox.org/mozilla-central/search?q=HasAuthorSpecifiedRules

This should probably be a separate investigation to see which properties
does that, and for which -moz-/-webkit-appearance values in Firefox / Chrome.
(This should probably be handled in a separate bug.)

I think the initial step in this bug would be to understand what the values
we don't currently support, but that Chrome supports, actually do in terms
of rendering / behavior.  Then we can decide if those need any work in layout,
or if we can simply map them to existing controls (which I expect we can, with
some minor tweaks perhaps).

	Mats Palmgren (inactive) Reporter
	Comment 19 • 7 years ago

BTW, I think we can ignore the scrollbar* values listed in 
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-_webkit_appearance
They don't seem to be supported as valid values in Chrome.

Note also that the list in the above URL is incomplete.  For example, <progress>
has the value 'progressbar' in Gecko and 'progress-bar' in Chrome (sigh).
We need to check what the initial value is for those newer HTML elements in
Firefox vs. Chrome.

	Mats Palmgren (inactive) Reporter
	Comment 20 • 7 years ago

This might be a better reference of which values Chrome actually supports:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/ThemeTypes.h?sq=package:chromium&dr=C&l=48

	Karl Dubost💡 :karlcow
	Comment 21 • 7 years ago

https://webcompat.com/issues/12821

input[type="submit"],input[type="text"],input[type="password"] {
 -webkit-appearance:none;
 -webkit-border-radius:0;
 background-color:#fff
}
select {
 -webkit-appearance:none;
 -webkit-border-radius:0;
 background:#fff url(images/dropdown.gif) no-repeat right center;
}
.reevoo-select {
 -webkit-appearance:menulist;
 background-image:initial
}

	Philip Jägenstedt [:foolip]
	Comment 22 • 7 years ago

We have some use counters for the property values in Chromium:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParserHelpers.cpp?l=1594

The results:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1351
https://www.chromestatus.com/metrics/feature/timeline/popularity/1352
https://www.chromestatus.com/metrics/feature/timeline/popularity/1353
https://www.chromestatus.com/metrics/feature/timeline/popularity/1354
https://www.chromestatus.com/metrics/feature/timeline/popularity/1355
https://www.chromestatus.com/metrics/feature/timeline/popularity/1356
https://www.chromestatus.com/metrics/feature/timeline/popularity/1357
https://www.chromestatus.com/metrics/feature/timeline/popularity/1358
https://www.chromestatus.com/metrics/feature/timeline/popularity/1359
https://www.chromestatus.com/metrics/feature/timeline/popularity/1360
https://www.chromestatus.com/metrics/feature/timeline/popularity/1361
https://www.chromestatus.com/metrics/feature/timeline/popularity/1362

	Louis Chang [:louis]
	Comment 25 • 7 years ago

I have investigated into the 51 -webkit-appearance values listed here
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/ThemeTypes.h?sq=package:chromium&dr=C&l=48
Basically, I just compare the attachment 8923730 [details] and attachment 8923732 [details] manually on Mac.
And I think there are 24 media-* related values that Chrome don't (completed) support yet.
For other 27 values, I list the results below respectively:
"<--" means there is a -moz-appearance value that I think its rendering / behavior is similar enough to map to the value.
"X" means Chrome supports the value but FF don't (or no any rendering / behavior of the -moz-appearance value is similar to it).
"unsupported" means Chrome don't (completed) support the value yet.

-webkit-appearance                        -moz-appearance
none                        <--           none
checkbox                    <--           checkbox
radio                       <--           radio
push-button                               X
square-button               <--           button-bevel
button                      <--           button
button-bevel                              unsupported
inner-spin-button                         X
listbox                                   unsupported
listitem                                  unsupported
menulist                    <--           menulist
menulist-button                           X
menulist-text                             unsupported
menulist-textfield                        unsupported
meter                                     unsupported
progress-bar                              unsupported
progress-bar-value                        unsupported
slider-horizontal           <--           scrollbarthumb-horizontal
slider-vertical             <--           scrollbarthumb-vertical
sliderthumb-horizontal      <--           scale-horizontal
sliderthumb-vertical        <--           scale-vertical
caret                                     unsupported
searchfield                 <--           searchfield
searchfield-cancel-button                 X
textfield                                 unsupported
textarea                                  unsupported
caps-lock-indicator                       unsupported
 
Mats, what do you think about the result?
So next step would be implement those values annotated as "X" so we could make -webkit-appearance the property name and -moz-appearance as an alias?

	Mats Palmgren (inactive) Reporter
	Comment 26 • 7 years ago

(In reply to Louis Chang [:louis] from comment #25)
> -webkit-appearance                        -moz-appearance
> push-button                               X

Yes, add a new value and handle it as 'button' in widget code.
push-button/button looks the same to me on both Linux/OSX in Chrome.

> square-button               <--           button-bevel

Interesting, 'square-button' looks more like 'button' in Chrome *on Linux*,
so we should probably also check that our -moz-appearance values looks
reasonable across platforms and spawn off some bugs to fix any differences.
In this case, our rendering on OSX seems more correct to me, so we should
fix the rendering on Linux (make it "flat" look with 1px solid border).

But yes, renaming our current button-bevel value to square-button seems like
the right fix here.

> button-bevel                              unsupported

After renaming our button-bevel value to square-button, we can implement
a new button-bevel value as in Chrome (which appears to have no background,
no borders, no states; so should be trivial to implement in widget/)

> inner-spin-button                         X

Yes, we need to implement the rendering for this value (up+down arrow).
I wonder if the native platforms have some support for it?

> listbox                                   unsupported

'listbox' is the default value for <select multiple> in Gecko (and Chrome),
so I don't understand why you say this is "unsupported".
I think we can map this value as is.

> listitem                                  unsupported

Looks the same as Chrome button-bevel to me.  Can we handle it the same?
We might want to rename our current value -moz-listitem and then add
a new listitem value if there's any difference to Chrome.

> menulist-button                           X

Looks similar to menulist.  We can probably implement it by just
falling in to menulist code.  But since we already support menulist-button
with a different rendering we probably need to preserve that for internal use.
That is, rename our current menulist-button to -moz-menulist-button first,
then add a new menulist-button that renders as menulist.

(BTW, -moz-appearance:menulist-button already looks quite broken to me,
e.g. <button style="-moz-appearance:menulist-button">Text</button> renders
"Text" but no chevron on Linux, but suppress the text and only renders
a chevron on OSX.  That seems like a bug to me.)

> menulist-text                             unsupported
> menulist-textfield                        unsupported

It seems Chrome doesn't do anything special for these values in the testcase.
They are parsed as valid values though.

It seems the rendering of these values varies between platforms in Firefox.
menulist-textfield has a chevron on OSX, but not on Linux for example.
So we should probably rename our current values -moz-menulist-* and then
add new menulist-text/textfield values to implement the Chrome rendering.

> meter                                     unsupported

We should first rename our 'meterbar' value to 'meter', then add 'meterbar'
as a synonym for 'meter' in the style system (map it to the same internal
NS_THEME_METER computed value).

> progress-bar                              unsupported

We should first rename our 'progressbar' value to 'progress-bar',
then add 'progressbar' as a synonym in the style system.

> progress-bar-value                        unsupported

It's not clear to me what this value does in Chrome.  Is there an associated
pseudo-element where it actually does something?  If not, just add the value
and make it behave as button-bevel.

> slider-horizontal           <--           scrollbarthumb-horizontal
> slider-vertical             <--           scrollbarthumb-vertical
> sliderthumb-horizontal      <--           scale-horizontal
> sliderthumb-vertical        <--           scale-vertical

Rename our values to the -webkit-appearance values first, then add synonyms.

> caret                                     unsupported

Add the value, handle it as 'button-bevel' in the widget code.

> searchfield-cancel-button                 X

We should implement this value, rendering a "X" cancel icon.

> textfield                                 unsupported
> textarea                                  unsupported

Why can't we map these to our values?  How is Chrome incompatible?

> caps-lock-indicator                       unsupported

This value doesn't seem to be a valid -webkit-appearance value in Chrome.
I think we can skip it.  (all the -internal-media-* values are also invalid
in Chrome, so those should be removed from the testcase)

> So next step would be implement those values annotated as "X" so we could
> make -webkit-appearance the property name and -moz-appearance as an alias?

Sounds good to me.  We also need to fix the blocking bugs before this can
be enabled.  We should probably also triage older bugs about incompatible
-webkit/-moz-appearance to make sure we don't miss something important.

We also need to add the media-* values (but not the -internal- ones).
We can make them all like button-bevel, i.e. do nothing in widget code.

For documentation purposes, I think it's clearer if we refer to values that
we do not currently support in -moz-appearance as "unsupported" (e.g. caret),
and refer to values that we currently do support but that are incompatible with
-webkit-appearance as "incompatible" (e.g. menulist-button) together with
a detailed description of *how* it's incompatible.

While implementing the above, I think it's important that we verify that 
the rendering in Firefox/Chrome is reasonably compatible on *all* our
Tier-1 platforms (assuming that Chrome supports them).  Please note that
most of our users are on Windows, so that's probably the most important
platform to test.

	Karl Dubost💡 :karlcow
	Comment 27 • 7 years ago

(In reply to Mats Palmgren (:mats) from comment #26)
> > progress-bar-value                        unsupported
> 
> It's not clear to me what this value does in Chrome.  Is there an associated
> pseudo-element where it actually does something?  If not, just add the value
> and make it behave as button-bevel.


I found only two mentions on chromium 
https://bugs.chromium.org/p/chromium/issues/detail?id=87249
https://bugs.chromium.org/p/chromium/issues/detail?id=79596

And one in WebKit
https://bugs.webkit.org/show_bug.cgi?id=40823

on macOS on Chrome Canary and Safari Tech Preview, they both seem to have no effect.
https://codepen.io/anon/pen/ZaGNYr

	Mats Palmgren (inactive) Reporter
	Comment 28 • 7 years ago

Right, it appears to be associated with the ::-webkit-progress-value
pseudo element:
https://trac.webkit.org/wiki/Styling%20Form%20Controls

We have a corresponding ::-moz-progress-bar pseudo(*) which has
'-moz-appearance: progresschunk':
http://searchfox.org/mozilla-central/rev/423b2522c48e1d654e30ffc337164d677f934ec3/layout/style/res/forms.css#859

so we might want to handle it as:
-webkit-appearance                        -moz-appearance
progress-bar-value           <--          progresschunk

(i.e. add the 'progress-bar-value' value and make 'progresschunk'
a synonym in the style system)

(*) our pseudo name seems a bit unfortunate since it might be
mistaken to correspond to ::-webkit-progress-bar

	Mats Palmgren (inactive) Reporter
	Comment 29 • 7 years ago

> so we might want to handle it as:
> progress-bar-value           <--          progresschunk

... then again, perhaps not since it doesn't actually do anything
in Chrome on other elements AFAICT, unlike our 'progresschunk'.
So maybe we should just it handle it as 'button-bevel' for now.
We can emulate it more closely if we decide to add aliases
for the ::-webkit-* pseudos in the future.

	Louis Chang [:louis]
	Comment 30 • 7 years ago

For documentation and to make sure if I understand your points correctly?
We can divide the values implementation into three groups:
1. existing -moz-appearance values that can directly map to -webkit-appearance values (no need to change)
none
checkbox
radio
button
listbox
menulist
searchfield
textfield
textarea

2. existing -moz-appearance values but need different implementation
button-bevel: rename to square-button and implement new button-bevel where its rendering/behavior is like Chrome
listitem: rename to -moz-listitem and implement new listitem where its rendering/behavior is like new button-bevel
menulist-button: rename to -moz-menulist-button and implement new menulist where its rendering/behavior is like menulist
menulist-text: rename to -moz-menulist-textfield and implement new menulist-text where its rendering/behavior is like new
               button-bevel
menulist-textfield: rename to -moz-menulist-textfield and implement new menulist-textfield where its rendering/behavior is like 
                    new button-bevel
caret: change the implementation to make it render/behave like new button-bevel

3. new added -moz-appearance values
push-button: use implementation of button
square-button: rename from button-bevel, use implementation of old button-bevel
inner-spin-button: implement inner-spin-button where its rendering/behavior is like Chrome
-moz-listitem: rename from listitem, use implementation of old listitem
-moz-menulist-button: rename from menulist-button, use implementation of old -menulist-button
-moz-menulist-text: rename from menulist-text, use implementation of old menulist-text
-moz-menulist-textfield: rename from menulist-textfield, use implementation of old menulist-textfield
meter: rename from meterbar (add meterbar as a synonym for meter)
progress-bar: rename from progressbar (add progressbar as a synonym for progress-bar)
progress-bar-value: implement the value where its rendering/behavior is like new button-bevel
searchfield-cancel-button: implement searchfield-cancel-button where its rendering/behavior is like Chrome
slider-horizontal: rename from scrollbarthumb-horizontal
slider-vertical: rename from scrollbarthumb-vertical
sliderthumb-horizontal: rename from scale-horizontal
sliderthumb-vertical: rename from scale-veritcal
media-*(15): implement the values where their rendering/behavior are like new button-bevel

	Louis Chang [:louis]
	Comment 31 • 7 years ago

A picture of mapping table between -webkit-appearance and -moz-appearance. (Just ignore it if it doesn't make you clearer...)

	Mats Palmgren (inactive) Reporter
	Comment 32 • 7 years ago

(In reply to Louis Chang [:louis] from comment #25)
> slider-horizontal           <--           scrollbarthumb-horizontal
> slider-vertical             <--           scrollbarthumb-vertical

I think these need more investigation.  For example, slider-horizontal
is the default value for  <range> in Chrome, whereas we use
'-moz-appearance: range'.

> sliderthumb-horizontal      <--           scale-horizontal
> sliderthumb-vertical        <--           scale-vertical

These also need more investigation.  The sliderthumb-* values appears
to only render the thumb part (of a <range>?), whereas our scale-* is for
the "bar part" (i.e. the background) of some part of our video controls?
http://searchfox.org/mozilla-central/source/toolkit/themes/shared/scale.css#8

I'm guessing the above values maps to our range / range-thumb values
respectively, except that we don't have any corresponding *-vertical values.
Our rendering of the thumb is round so it works for both (at least on Linux,
but please check other tier-1 platforms).  We should probably implement
rendering for slider-vertical at some point, but I don't see it as
blocking this bug.

So, we should probably just rename our range / range-thumb values to
slider-horizontal / sliderthumb-horizontal, and add synonyms for the old
values.  Also add the new *-vertical values as distinct values, but map
them internally in widget code to the *-horizontal code paths for now.

	Mats Palmgren (inactive) Reporter
	Comment 33 • 7 years ago

(In reply to Louis Chang [:louis] from comment #30)
> 1. existing -moz-appearance values that can directly map to
> -webkit-appearance values (no need to change)

For clarity, 1. really affects all existing -moz-appearance values
that are not explicitly mentioned in 2. or 3.
Once we alias -moz-appearance to -webkit-appearance then we will
accept '-webkit-appearance: number-input' for example, and it will
render as a number input.

Other than that, and comment 32, your summary looks OK.

	Karl Dubost💡 :karlcow
	Comment 34 • 7 years ago

```css

.btn {
	font-family: Helvetica, Arial, sans-serif;
	font-weight: bold;
	position: relative;
	display: inline-block;
	-webkit-box-sizing: border-box;
	-moz-box-sizing: border-box;
	box-sizing: border-box;
	cursor: pointer;
	-webkit-user-select: none;
	-moz-user-select: none;
	-ms-user-select: none;
	user-select: none;
	vertical-align: middle;
	-webkit-appearance: none;
}

select.is-tab-dropdown-more {
	position: absolute;
	right: -1px;
	width: 42px;
	height: 42px;
	background-image: url("/images/chevron_right.png");
	background-repeat: no-repeat;
	background-position: 50%;
	background-color: #fff;
	text-indent: -9999px;
}
```

	Maire Reavy [:mreavy]
	Comment 35 • 6 years ago

Talked to Jet earlier today, and this really is a critical webcompat issue that we need to start implementing.

	Maire Reavy [:mreavy]
	Comment 36 • 6 years ago

Thanks for taking this one, Jonathan!

	Jonathan Watt [:jwatt] Assignee
	Comment 37 • 6 years ago

Removing various webcompat.com reports that have been fixed by the site authors since being reported.

	Jonathan Watt [:jwatt] Assignee
	Comment 38 • 6 years ago

Putting back https://webcompat.com/issues/7612 which I removed by mistake, and removing three other issues that have also been fixed by the site authors.

	Jonathan Watt [:jwatt] Assignee
	Comment 39 • 6 years ago

18 of the webcompat issues that still exist are fixed by flipping the pref layout.css.webkit-appearance.enabled set to true:

https://webcompat.com/issues/7007
https://webcompat.com/issues/7612
https://webcompat.com/issues/7760
https://webcompat.com/issues/9169
https://webcompat.com/issues/9896
https://webcompat.com/issues/9899
https://webcompat.com/issues/9973
https://webcompat.com/issues/12315
https://webcompat.com/issues/12821
https://webcompat.com/issues/12964
https://webcompat.com/issues/13038
https://webcompat.com/issues/13195
https://webcompat.com/issues/13895
https://webcompat.com/issues/15584
https://webcompat.com/issues/16344
https://webcompat.com/issues/17089
https://webcompat.com/issues/17090
https://webcompat.com/issues/17157

	Jonathan Watt [:jwatt] Assignee
	Comment 40 • 6 years ago

The only webcompat issue that's not fixed by enabling the pref is:

https://webcompat.com/issues/7309

where the <select>s continue to get both themed and unthemed dropdown arrows.

Google is serving different CSS inline in that page to Firefox vs. Chrome.

  For Firefox:  appearance:button;appearance:button

  For Chrome:   -webkit-appearance:button;appearance:button

Firefox does not recognize 'appearance:button', so the <select> gets the default -moz-appearance value of 'menulist', but it also gets the 'background' image ( https://ssl.gstatic.com/ui/v1/disclosure/grey-disclosure-arrow-up-down.png ) that displays the other arrows.

Chrome treats '-webkit-appearance:button' as computing to the value 'none' since the properties 'border', 'border-radius' and 'background-position' are set, so it only gets the arrows from the background image. (If -webkit-appearance wasn't set, the setting of those other properties would change the computed value from 'menulist' to 'menulist-button' for the record.)

If Google was to serve '-moz-appearance:button' to Firefox then the <select>s would display correctly, although the computed value would be 'button' unlike for Chrome (since we don't disable theming when the properties 'border', 'border-radius' and 'background-position' are set). Serving '-moz-appearance:none' would also work and would also result in the same computed value.

	Jonathan Watt [:jwatt] Assignee
	Comment 41 • 6 years ago

Turns out issue 8034 is not fixed, it's just been hidden by the native Android theming implemented in bug 1352238 (thanks, Karl, for noticing!). However, flipping the pref on fixes the site.

	Jonathan Watt [:jwatt] Assignee
	Comment 42 • 6 years ago

I created this testcase to make it easier to compare the behavior of specific -webkit-appearance values across browsers and platforms. (The huge table isn't very conducive to that.)

	Jonathan Watt [:jwatt] Assignee
	Comment 43 • 6 years ago

Bug 1480073 turned on the -webkit-appearance alias for 63 (now in beta) behind EARLY_BETA_OR_EARLIER. Early beta finishes today, the next beta being beta 10 which will ship in 3 days (Friday).

The only bug that I'm aware of that has been reported in beta 63 so far is bug 1492043, which seems like a WONTFIX. Given the lack of any other issues being reported let's go ahead with letting this ride to release in 63 as planed (baring any other issues turning up of course).

	Jonathan Watt [:jwatt] Assignee
	Comment 45 • 6 years ago

Comment on attachment 9011755 [details]
Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio

Approval Request Comment
[Feature/Bug causing the regression]: no regression, just keeping pref on for later-beta
[User impact if declined]: lots of webcompat.com bugs
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: yes, and early beta
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: seems low
[Why is the change risky/not risky?]: been through nightly and early beta. have done what we can to reduce risk via an investigation into how -webkit-appearance is used.
[String changes made/needed]: none

	Emilio Cobos Álvarez (:emilio)
	Comment 46 • 6 years ago

Comment on attachment 9011755 [details]
Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio

Emilio Cobos Álvarez (:emilio) has approved the revision.

	Pascal Chevrel:pascalc (PTO until April 26)
	Comment 47 • 6 years ago

Comment on attachment 9011755 [details]
Bug 1368555. Let -webkit-appearance ride the trains in v63. r?emilio

Activated on nightly and beta since early August with only a minor issue reported (bug 1492043), on the other hand this fixes webcompat issues (comment #39) we have with many websites using the webkit-appearance property, among which high visibility sites. Uplift approved for 63 beta 10, thanks.

	Pulsebot
	Comment 48 • 6 years ago

Pushed by jwatt@jwatt.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fcd1fdbbad0d
Let -webkit-appearance ride the trains in v63. r=emilio

	Jonathan Watt [:jwatt] Assignee
	Comment 49 • 6 years ago
uplift

The link to the landing on beta seems to be taking its time to show up here. In case that doesn't happen, here's the link:

https://hg.mozilla.org/releases/mozilla-beta/rev/871364095b27

	Ryan VanderMeulen [:RyanVM]
	Comment 50 • 6 years ago

Pushes to release branches don't get marked automatically.

	Mike Taylor [:miketaylr]
	Comment 51 • 6 years ago

This is so cool. Thanks everybody.

	Andrei Ciure[:aciure]
	Comment 52 • 6 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/fcd1fdbbad0d

	Chris Mills [:cmills]
	Comment 53 • 6 years ago

Note to docs team:

I've added a note about this to the Fx64 rel notes:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#CSS

The rest of the docs work still needs doing (BCD, making sure we list all the available values, etc.).