1481643 - Consider at least parsing the '-webkit-appearance' values that Chrome supports that we don't

Status: NEW

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

Description

[Jonathan Watt [:jwatt]]

Chrome has a bunch of '-webkit-appearance' values that we don't recognize for '-moz-appearance'. I think these are the following, with some comments:

 * inner-spin-button
     we have 'spinner-downbutton', 'spinner-upbutton' and
     'spinner-textfield'
 * media-enter-fullscreen-button
 * media-exit-fullscreen-button
 * media-mute-button
 * media-play-button
 * media-overlay-play-button
 * media-toggle-closed-captions-button
 * media-slider
 * media-sliderthumb
 * media-volume-slider-container
 * media-volume-slider
 * media-volume-sliderthumb
 * media-controls-background
 * media-controls-fullscreen-background
 * media-current-time-display
 * media-time-remaining-display
     we don't have equivalent 'appearance' values for our media controls
 * meter
     our value is 'meterbar' (chrome doesn't have a 'meterchunk')
 * progress-bar
     our value is 'progressbar'
 * progress-bar-value
     chrome doesn't appear to use this, on macOS at least
     our value is 'progresschunk'/'progresschunk-vertical'?
 * push-button
     !!! mats says "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"
 * searchfield-cancel-button
     we don't have any such button
 * slider-horizontal
 * slider-vertical
     our 'range' value covers both
 * sliderthumb-horizontal
 * sliderthumb-vertical
     our 'range-thumb' value covers both
 * square-button
 * textarea

I know that Mats wanted to consider at least parsing these values since that's what Edge appears to do that, even though Edge doesn't actually do anything with the computed values.

Implementing that doesn't seem necessary to ship our '-webkit-appearance' alias though, since these values are not frequently used according to the crawl that MS did:

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

Comment 1

[Jonathan Watt [:jwatt]]

We should start by seeing if Google will hide at least some of these values from the web.

Comment 2

[Mats Palmgren (inactive)]

We now support 'meter' (bug 1501483) and 'progress-bar' (bug 1481650).
(our old -moz-appearance values are aliases of those for now)

I've investigated the 'slider-horizontal'/'slider-vertical' values
a bit and my conclusion is that encoding the direction in the value
is bad because then you can't set '-webkit-appearance:none' on
a vertical control to override the styling.  Using a single value
('-webkit-appearance:range') like we do is a better alternative.
I've filed a spec issue:
https://github.com/whatwg/html/issues/4177

Comment 3

[Mats Palmgren (inactive)]

I added 'textarea' in bug 1507905 as the default for <textarea>
and made our current value 'textfield-multiline' an alias.

Regarding 'push-button' and 'square-button', I think we should
try to convince other UAs to deprecate those values.  They are
probably not needed for webcompat given that we don't currently
support them.  I suggested that we spec 'button' as the value
for both <button> and <input type=button>  in the draft spec
document that zcorpan is editing and I haven't seen any
objections about that so far.