Intent to Deprecate and Remove: -webkit-appearance keywords for arbitrary elements

162 views
Skip to first unread message

TAMURA, Kent

unread,
Jul 10, 2019, 9:13:50 PM7/10/19
to blink-dev, Emilio Cobos Álvarez
tk...@chromium.org Specification: https://drafts.csswg.org/css-ui-4/#propdef-appearance Some -webkit-appearance keywords work with arbitrary element types, and some other keywords work only with specific element types. According to css-ui-4 draft, all -webkit-appearance keywords should work only with specific element types. If a keyword is applied to a non-supported element, the element should have the default appearance.

Full list of keyword => supported elements

    "checkbox", input[type=checkbox]
    "radio", input[type=radio]
    "push-button", input[type=button/reset/submit]
    "square-button", input[type=color]
    "button", button, input[type=button/reset/submit] (*1)
    "inner-spin-button", ::-webkit-inner-spin-button
    "listbox", list box <select>
    "menulist", drop-down box <select>, input[type=color/date/datetime-local/month/time/week]
    "menulist-button", Ditto.
    "meter", meter
    "progress-bar", progress
    "slider-horizontal", input[type=range]
    "slider-vertical", input[type=range]
    "sliderthumb-horizontal", ::webkit-slider-thumb, ::-webkit-media-slider-thumb
    "sliderthumb-vertical", Ditto.
    "searchfield", input[type=search]
    "searchfield-cancel-button", ::-webkit-clear-button, ::-webkit-search-cancel-button
    "textfield", input[type=search], input[type=email/number/password/tel/text/url/date/datetime-local/month/time/week]
    "textarea", textarea

*1: It's stricter than css-ui-4 draft, which allows to apply 'button' to many other element types. We try the stricter set, and will give feedback to css-ui-4.

Some of keywords already have such behavior. We should expand it to all keywords for consistency and to reduce implementation complexity.
Chrome will be the first browser implementing the new behavior.
Page view impact would be 0.000001% to 0.019%, depending on keywords.  Affected pages will have elements rendered with their default appearance.

Edge: No signal
Firefox: Supported in private email
Safari: No signal

Alternative implementation suggestion for web developers

No alternative. Developers needs to make appearances with their own way.


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/2560
https://www.chromestatus.com/metrics/feature/timeline/popularity/2562
https://www.chromestatus.com/metrics/feature/timeline/popularity/2585
https://www.chromestatus.com/metrics/feature/timeline/popularity/2587
https://www.chromestatus.com/metrics/feature/timeline/popularity/2774
https://www.chromestatus.com/metrics/feature/timeline/popularity/2564
https://www.chromestatus.com/metrics/feature/timeline/popularity/2817
https://www.chromestatus.com/metrics/feature/timeline/popularity/2583
https://www.chromestatus.com/metrics/feature/timeline/popularity/2614
https://www.chromestatus.com/metrics/feature/timeline/popularity/2817
https://www.chromestatus.com/metrics/feature/timeline/popularity/2569
https://www.chromestatus.com/metrics/feature/timeline/popularity/2571
https://www.chromestatus.com/metrics/feature/timeline/popularity/2573
https://www.chromestatus.com/metrics/feature/timeline/popularity/2575
https://www.chromestatus.com/metrics/feature/timeline/popularity/2577
https://www.chromestatus.com/metrics/feature/timeline/popularity/2579
https://www.chromestatus.com/metrics/feature/timeline/popularity/2822
https://www.chromestatus.com/metrics/feature/timeline/popularity/2581

Up to 0.019%.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5070237827334144

Requesting approval to remove too?

Yes.

Plan:
  M77: Show deprecation messages
  M78: Change the behavior

--
TAMURA Kent
Software Engineer, Google


Florian Rivoal

unread,
Jul 11, 2019, 4:17:43 AM7/11/19
to blink-dev, emi...@mozilla.com
Hi,

I am very supportive of this, and look forward to your findings about how much of this is web compatible. You have listed "no signal" from Edge and Safari, but at the same time, this is in line with what the spec says, and that was decided in CSS-WG meetings where they did participate, so I'd count that as some degree of support. This is the direction the CSSWG wants to move towards, and having Chrome do the first move will make it much easier for other browsers to do it as well.

Thanks a lot, Kent.
—Florian

Chris Harrelson

unread,
Jul 11, 2019, 3:46:40 PM7/11/19
to Florian Rivoal, blink-dev, Emilio Cobos Álvarez
LGTM1 to try to make this change. Please come back to this thread with data if there are any compat issues found.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/accc7efc-20c4-4d35-806b-78c0fede1ca0%40chromium.org.

Daniel Bratell

unread,
Jul 11, 2019, 4:06:56 PM7/11/19
to Florian Rivoal, Chris Harrelson, blink-dev, Emilio Cobos Álvarez
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

https://www.chromestatus.com/metrics/feature/timeline/popularity/2579 - search that are not really search. What is the worst case scenario here? Is it just  that the cross button stops being available in a text field or is there more to it?

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8XCOczW6iOOKrZhvfp%2BhSggWpw02pOLHfKjyYR88WOkQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

TAMURA, Kent

unread,
Jul 11, 2019, 11:02:33 PM7/11/19
to Daniel Bratell, Florian Rivoal, Chris Harrelson, blink-dev, Emilio Cobos Álvarez
On Fri, Jul 12, 2019 at 5:07 AM Daniel Bratell <bra...@opera.com> wrote:
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

I'd like to categorize this into three use cases:
a) Drop-down box <select> with 'button' appearance
b) Hyper-link <a href="..."> with 'button' appearance; https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
c) Others; e.g. <div> with 'button' appearance

In any case, an element will be painted with its default appearance; a) 'menulist' or 'menulist-button', b) 'none', and c) 'none'.
Though they will have rendering results which web authors don't expect,  I think users still can operate with A and B elements.  C would have troubles that users can't know elements are clickable.
 

https://www.chromestatus.com/metrics/feature/timeline/popularity/2579 - search that are not really search. What is the worst case scenario here? Is it just  that the cross button stops being available in a text field or is there more to it?

The cross button in input[type=search] won't be affected.  If a web page has style like "div.cancel { -webkit-appearance: searchfield-cancel-button; }", the element will have no cross button, and users might be unable to find the element.
Actually, this counter value is too high due to a bug of the counting code.  The counter unexpectedly contains usage with ::-webkit-clear-button pseudo elements, which is used in input[type=date/datetime-local/month/time/week] on non-Android Chrome and won't change behavior.  The fixed counter is https://www.chromestatus.com/metrics/feature/timeline/popularity/2905, and the counter is available since Chrome 76.
 

Yoav Weiss

unread,
Jul 12, 2019, 1:34:01 AM7/12/19
to TAMURA, Kent, Daniel Bratell, Florian Rivoal, Chris Harrelson, blink-dev, Emilio Cobos Álvarez
On Fri, Jul 12, 2019 at 5:02 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 5:07 AM Daniel Bratell <bra...@opera.com> wrote:
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

I'd like to categorize this into three use cases:
a) Drop-down box <select> with 'button' appearance
b) Hyper-link <a href="..."> with 'button' appearance; https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
c) Others; e.g. <div> with 'button' appearance

In any case, an element will be painted with its default appearance; a) 'menulist' or 'menulist-button', b) 'none', and c) 'none'.
Though they will have rendering results which web authors don't expect,  I think users still can operate with A and B elements.  C would have troubles that users can't know elements are clickable.

C is indeed the scary case. Could we remove everything but C and look at usage at that point?
  
 

https://www.chromestatus.com/metrics/feature/timeline/popularity/2579 - search that are not really search. What is the worst case scenario here? Is it just  that the cross button stops being available in a text field or is there more to it?

The cross button in input[type=search] won't be affected.  If a web page has style like "div.cancel { -webkit-appearance: searchfield-cancel-button; }", the element will have no cross button, and users might be unable to find the element.
Actually, this counter value is too high due to a bug of the counting code.  The counter unexpectedly contains usage with ::-webkit-clear-button pseudo elements, which is used in input[type=date/datetime-local/month/time/week] on non-Android Chrome and won't change behavior.  The fixed counter is https://www.chromestatus.com/metrics/feature/timeline/popularity/2905, and the counter is available since Chrome 76.

OK, that can significantly lower the counters...
 

TAMURA, Kent

unread,
Jul 12, 2019, 2:00:14 AM7/12/19
to Yoav Weiss, Daniel Bratell, Florian Rivoal, Chris Harrelson, blink-dev, Emilio Cobos Álvarez
On Fri, Jul 12, 2019 at 2:33 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jul 12, 2019 at 5:02 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 5:07 AM Daniel Bratell <bra...@opera.com> wrote:
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

I'd like to categorize this into three use cases:
a) Drop-down box <select> with 'button' appearance
b) Hyper-link <a href="..."> with 'button' appearance; https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
c) Others; e.g. <div> with 'button' appearance

In any case, an element will be painted with its default appearance; a) 'menulist' or 'menulist-button', b) 'none', and c) 'none'.
Though they will have rendering results which web authors don't expect,  I think users still can operate with A and B elements.  C would have troubles that users can't know elements are clickable.

C is indeed the scary case. Could we remove everything but C and look at usage at that point?

For now, we have a counter for A + C.  https://www.chromestatus.com/metrics/feature/timeline/popularity/2775  0.005%.  So C must be less than 0.005%.
If 0.005% still looks high, how about changing the plan like:
  M77: Show deprecation messages for all cases, and add a counter for C.
  After M77 stable promotion: Check the counter value, and make a decision about C.
  M79: Change the behavior with/without C.
 

Yoav Weiss

unread,
Jul 12, 2019, 2:21:49 AM7/12/19
to TAMURA, Kent, Daniel Bratell, Florian Rivoal, Chris Harrelson, blink-dev, Emilio Cobos Álvarez
On Fri, Jul 12, 2019 at 8:00 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 2:33 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jul 12, 2019 at 5:02 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 5:07 AM Daniel Bratell <bra...@opera.com> wrote:
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

I'd like to categorize this into three use cases:
a) Drop-down box <select> with 'button' appearance
b) Hyper-link <a href="..."> with 'button' appearance; https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
c) Others; e.g. <div> with 'button' appearance

In any case, an element will be painted with its default appearance; a) 'menulist' or 'menulist-button', b) 'none', and c) 'none'.
Though they will have rendering results which web authors don't expect,  I think users still can operate with A and B elements.  C would have troubles that users can't know elements are clickable.

C is indeed the scary case. Could we remove everything but C and look at usage at that point?

For now, we have a counter for A + C.  https://www.chromestatus.com/metrics/feature/timeline/popularity/2775  0.005%.  So C must be less than 0.005%.

0.005% is lower than what I thought it would be initially.
 
If 0.005% still looks high, how about changing the plan like:
  M77: Show deprecation messages for all cases, and add a counter for C.
  After M77 stable promotion: Check the counter value, and make a decision about C.
  M79: Change the behavior with/without C.

That plan SG, but might be a bit too restrictive. Maybe we could go ahead with everything but C, while collecting data on C and making a separate decision about it for M79?

Chris Harrelson

unread,
Jul 12, 2019, 12:23:28 PM7/12/19
to Yoav Weiss, TAMURA, Kent, Daniel Bratell, Florian Rivoal, blink-dev, Emilio Cobos Álvarez
On Fri, Jul 12, 2019 at 2:21 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jul 12, 2019 at 8:00 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 2:33 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jul 12, 2019 at 5:02 AM TAMURA, Kent <tk...@chromium.org> wrote:


On Fri, Jul 12, 2019 at 5:07 AM Daniel Bratell <bra...@opera.com> wrote:
Hi tkent!

This looks like a nice cleanup and for all but two the usage numbers are so low that there is no reason to worry, but there are two that are a bit higher.

https://www.chromestatus.com/metrics/feature/timeline/popularity/2774 - for things that are not buttons but want to look like buttons. What is the worst case scenario here? What happens if this appearance disappears?

I'd like to categorize this into three use cases:
a) Drop-down box <select> with 'button' appearance
b) Hyper-link <a href="..."> with 'button' appearance; https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
c) Others; e.g. <div> with 'button' appearance

In any case, an element will be painted with its default appearance; a) 'menulist' or 'menulist-button', b) 'none', and c) 'none'.
Though they will have rendering results which web authors don't expect,  I think users still can operate with A and B elements.  C would have troubles that users can't know elements are clickable.

C is indeed the scary case. Could we remove everything but C and look at usage at that point?

For now, we have a counter for A + C.  https://www.chromestatus.com/metrics/feature/timeline/popularity/2775  0.005%.  So C must be less than 0.005%.

0.005% is lower than what I thought it would be initially.
 
If 0.005% still looks high, how about changing the plan like:
  M77: Show deprecation messages for all cases, and add a counter for C.
  After M77 stable promotion: Check the counter value, and make a decision about C.
  M79: Change the behavior with/without C.

That plan SG, but might be a bit too restrictive. Maybe we could go ahead with everything but C, while collecting data on C and making a separate decision about it for M79?

+1 to going ahead with the rest now, and C in 79.
 

Philip Jägenstedt

unread,
Jul 12, 2019, 12:40:25 PM7/12/19
to Chris Harrelson, Yoav Weiss, TAMURA, Kent, Daniel Bratell, Florian Rivoal, blink-dev, Emilio Cobos Álvarez

Yoav Weiss

unread,
Jul 12, 2019, 12:42:11 PM7/12/19
to Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Daniel Bratell, Florian Rivoal, blink-dev, Emilio Cobos Álvarez
LGTM3

TAMURA, Kent

unread,
Jul 15, 2019, 8:04:45 PM7/15/19
to Yoav Weiss, Philip Jägenstedt, Chris Harrelson, Daniel Bratell, Florian Rivoal, blink-dev, Emilio Cobos Álvarez
ok, so, This intent excludes the case C.
M77 will show deprecation messages except for C, and M79 will remove them.
I'll make another intent only for C after M77 stable promotion.

PhistucK

unread,
Jul 16, 2019, 7:02:47 AM7/16/19
to TAMURA, Kent, Yoav Weiss, Philip Jägenstedt, Chris Harrelson, Daniel Bratell, Florian Rivoal, blink-dev, Emilio Cobos Álvarez
The popular Bootstrap CSS library has a too loose selector for -webkit-appearance: button -

[type=button],[type=reset],[type=submit],button{-webkit-appearance:button}

So <i type="button"> (for example) would be affected. From the list of sites from HTTP archive, shown in ChromeStatus, this is used by, for example, dixi-bg.com -
return '<i type="button" style="color:#d0205e;" class="ultsl-record" data-role="none"></i>';
And indeed, the point-buttons below the big image carousel at the top of the page have button designs. Now, that actually looks like a bug and not the intended outcome, so this intent would actually fix this website rather than harm it.
But, still, having this code in Bootstrap is not great and I guess you will be able to lower the counters even more after that is removed (assuming people update).

PhistucK


Reply all
Reply to author
Forward
0 new messages