Intent to Implement and Ship: Unprefixed 'appearance' CSS property

175 views
Skip to first unread message

TAMURA, Kent

unread,
Mar 4, 2020, 12:30:54 AM3/4/20
to blink-dev, Simon Pieters
tk...@chromium.org N/A Specification: https://drafts.csswg.org/css-ui-4/#appearance-switching None; Very small change. This feature introduces 'appearance' CSS property, which is the unprefixed version of '-webkit-appearance'. Developers should avoid vendor-prefixed CSS properties, but Chrome have never provided unprefixed version of '-webkit-appearance'.
Low compatibility risk. Existing sites might specify prefixed one and unprefixed one in a single ruleset. However, they have the same value typically. .foo { -webkit-appearance: none; appearance: none; } Low interoperability risk. A Firefox engineer expressed support for this change. No objection from WebKit team. Firefox: No public signals Edge: No public signals Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-January/031026.html) Web developers: No signals
Yes Yes https://wpt.fyi/results/css/css-ui https://bugs.chromium.org/p/chromium/issues/detail?id=963551 https://chromestatus.com/feature/4715298156445696

--
TAMURA Kent
Software Engineer, Google


TAMURA, Kent

unread,
Mar 4, 2020, 12:38:36 AM3/4/20
to blink-dev, Simon Pieters
I should have mentioned:

-webkit-appearance currently supports many non-standard keywords. e.g. -webkit-appearance: inner-spin-button
The new 'appearance' will support such keywords too initially, but I'm going to add console warnings for non-standard keywords.
So,
  -webkit-appearance: inner-spin-button;   /* This doesn't show any warnings as ever.*/
  appearance: inner-spin-button; /* This will show a warning about the non-standard keywords. */

I'm going to deprecate and remove non-standard keywords later.

Chris Harrelson

unread,
Mar 4, 2020, 11:52:06 AM3/4/20
to TAMURA, Kent, blink-dev, Simon Pieters
Hi,

I have several questions:

* Has this step been discussed recently at the CSSWG?
* Is there consensus there that the current prefixed behavior is as close as we can get it to the optimal state without breaking the web?
* You mentioned a Firefox engineer was supportive of this step, do you have more details on Mozilla's position? It would be best to make sure all browsers can ship the same appearance property together, and given recent discussions, I think that may be possible.
* Why should we ship non-standard values in the unprefixed property?


--
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/CAGH7WqEXYCFg3XU32KPfLpk7B6kB_CW2qhe0ObkaYaJdjgjuyA%40mail.gmail.com.

TAMURA, Kent

unread,
Mar 4, 2020, 10:01:45 PM3/4/20
to Chris Harrelson, blink-dev, Simon Pieters
On Thu, Mar 5, 2020 at 1:52 AM Chris Harrelson <chri...@chromium.org> wrote:
Hi,

I have several questions:

* Has this step been discussed recently at the CSSWG?

The CSSWG telecon on 2019-11-20 discussed 'appearance' property, and concluded to remove implementation-not-ready warning from the specification.

 
* Is there consensus there that the current prefixed behavior is as close as we can get it to the optimal state without breaking the web?

I think the consensus was made at https://github.com/w3c/csswg-drafts/issues/3024.

 
* You mentioned a Firefox engineer was supportive of this step, do you have more details on Mozilla's position? It would be best to make sure all browsers can ship the same appearance property together, and given recent discussions, I think that may be possible.

An engineer said that the current 'appearance' definition and the plan to implement it in Chrome were 'nice'. They didn't say they'll implement it, and I don't think it can be assumed as Mozilla's official position.
 
* Why should we ship non-standard values in the unprefixed property?

I wrote a document about this intent. Quote from it:

Why won't we ship 'appearance' property without unspecified keywords?

It's very difficult to have consistent behavior in that case.

For example, if '-webkit-appearance: inner-spin-button' is specified, what's the computed value of 'appearance', which doesn't support 'inner-spin-button'?

Why won't we deprecate and remove unspecified keywords before shipping 'appearance'?

If we deprecate unspecified keywords without shipping 'appearance' property, Chrome would show a deprecation message like "inner-spin-button is deprecated and will be removed M??. Please use '-webkit-appearance: auto' instead." But we should not recommend using prefixed -webkit-appearance.  The message should be ".. use 'appearance: auto' instead".


We don't think we can remove slider*-vertical keywords soon because Blink and WebKit have no other ways to render vertical sliders. [whatwg/html#4177]


 

Yoav Weiss

unread,
Mar 5, 2020, 3:38:27 AM3/5/20
to TAMURA, Kent, Chris Harrelson, blink-dev, Simon Pieters
On Thu, Mar 5, 2020 at 4:01 AM TAMURA, Kent <tk...@chromium.org> wrote:



On Thu, Mar 5, 2020 at 1:52 AM Chris Harrelson <chri...@chromium.org> wrote:
Hi,

I have several questions:

* Has this step been discussed recently at the CSSWG?

The CSSWG telecon on 2019-11-20 discussed 'appearance' property, and concluded to remove implementation-not-ready warning from the specification.

 
* Is there consensus there that the current prefixed behavior is as close as we can get it to the optimal state without breaking the web?

I think the consensus was made at https://github.com/w3c/csswg-drafts/issues/3024.

 
* You mentioned a Firefox engineer was supportive of this step, do you have more details on Mozilla's position? It would be best to make sure all browsers can ship the same appearance property together, and given recent discussions, I think that may be possible.

An engineer said that the current 'appearance' definition and the plan to implement it in Chrome were 'nice'. They didn't say they'll implement it, and I don't think it can be assumed as Mozilla's official position.
 
* Why should we ship non-standard values in the unprefixed property?

I wrote a document about this intent. Quote from it:

Why won't we ship 'appearance' property without unspecified keywords?

It's very difficult to have consistent behavior in that case.

For example, if '-webkit-appearance: inner-spin-button' is specified, what's the computed value of 'appearance', which doesn't support 'inner-spin-button'?

Why won't we deprecate and remove unspecified keywords before shipping 'appearance'?

If we deprecate unspecified keywords without shipping 'appearance' property, Chrome would show a deprecation message like "inner-spin-button is deprecated and will be removed M??. Please use '-webkit-appearance: auto' instead." But we should not recommend using prefixed -webkit-appearance.  The message should be ".. use 'appearance: auto' instead".


Wouldn't this be possible if we were to ship `appearance` only with specified keywords and deprecate them from `-webkit-appearance` (at least for the ones where we have a replacement)? 

Simon Pieters

unread,
Mar 5, 2020, 8:58:47 AM3/5/20
to Yoav Weiss, TAMURA, Kent, Chris Harrelson, blink-dev

I wrote a document about this intent. Quote from it:

Why won't we ship 'appearance' property without unspecified keywords?

It's very difficult to have consistent behavior in that case.

For example, if '-webkit-appearance: inner-spin-button' is specified, what's the computed value of 'appearance', which doesn't support 'inner-spin-button'?

Why won't we deprecate and remove unspecified keywords before shipping 'appearance'?

If we deprecate unspecified keywords without shipping 'appearance' property, Chrome would show a deprecation message like "inner-spin-button is deprecated and will be removed M??. Please use '-webkit-appearance: auto' instead." But we should not recommend using prefixed -webkit-appearance.  The message should be ".. use 'appearance: auto' instead".


Wouldn't this be possible if we were to ship `appearance` only with specified keywords and deprecate them from `-webkit-appearance` (at least for the ones where we have a replacement)? 

The spec requires a "legacy name alias":

> For compatibility with legacy content, UAs must also support -webkit-appearance as a legacy name alias of appearance.

Doing something else would violate this requirement and you'd have to somehow deal with complications like the one tkent mentioned above.

If we find later that a keyword can't be removed from -webkit-appearance, the right action is to add it to the spec, not to have different set of supported keywords between the prefixed and unprefixed properties, in my opinion.

I support this intent as-is. I'm happy to see this happening. I worked on the spec and tests for this property in 2018 and 2019, and it was a goal to make it possible for browsers to ship this change (and supporting the 'auto' keyword) without breaking web compatibility. CSS prefixes is a pain point for web developers, so we should get rid of them where possible!

cheers,
--
Simon Pieters

sligh...@chromium.org

unread,
Mar 5, 2020, 11:51:54 AM3/5/20
to blink-dev, yo...@yoav.ws, tk...@chromium.org, chri...@chromium.org
Thanks for all the background, Simon and Tamura-san. Glad to see ongoing work to turn off prefixes that have escaped the lab.

Have any other vendors shipped unprefixed appearance?

Regards

Yoav Weiss

unread,
Mar 5, 2020, 5:15:45 PM3/5/20
to Alex Russell, blink-dev, TAMURA, Kent, Chris Harrelson
On Thu, Mar 5, 2020 at 5:51 PM <sligh...@chromium.org> wrote:
Thanks for all the background, Simon and Tamura-san. Glad to see ongoing work to turn off prefixes that have escaped the lab.

Have any other vendors shipped unprefixed appearance?

If the answer to that is "no", could you file bugs to that effect? 

TAMURA, Kent

unread,
Mar 5, 2020, 6:38:48 PM3/5/20
to Yoav Weiss, blink-dev
I think Chrome will be the first browser to ship 'appearance'.

Chris Harrelson

unread,
Mar 5, 2020, 6:57:20 PM3/5/20
to TAMURA, Kent, Yoav Weiss, blink-dev
LGTM1

--
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/CAGH7WqGy-wjT4u0ygPJ-BcOSU%3D8JLc-MgFd-adVEd8WBy%2BJH9Q%40mail.gmail.com.

Boris Zbarsky

unread,
Mar 5, 2020, 11:00:57 PM3/5/20
to Simon Pieters, Yoav Weiss, TAMURA, Kent, Chris Harrelson, blink-dev
On 3/5/20 8:58 AM, Simon Pieters wrote:
> If we find later that a keyword can't be removed from
> -webkit-appearance, the right action is to add it to the spec, not to
> have different set of supported keywords between the prefixed and
> unprefixed properties, in my opinion.

Given <https://bugzilla.mozilla.org/show_bug.cgi?id=1365614>, should
"checkbox" and "radio" be added to the spec?

-Boris

Boris Zbarsky

unread,
Mar 5, 2020, 11:03:35 PM3/5/20
to Simon Pieters, Yoav Weiss, TAMURA, Kent, Chris Harrelson, blink-dev
On 3/5/20 11:00 PM, Boris Zbarsky wrote:
> Given <https://bugzilla.mozilla.org/show_bug.cgi?id=1365614>, should
> "checkbox" and "radio" be added to the spec?

Ah, I see, they're in <compat-auto>. Nevermind!

-Boris

Yoav Weiss

unread,
Mar 6, 2020, 1:55:32 AM3/6/20
to Boris Zbarsky, Simon Pieters, TAMURA, Kent, Chris Harrelson, blink-dev
LGTM2

Philip Jägenstedt

unread,
Mar 12, 2020, 8:14:16 AM3/12/20
to Yoav Weiss, Boris Zbarsky, Simon Pieters, TAMURA, Kent, Chris Harrelson, blink-dev
LGTM3, this has been a long time coming and I'm glad it's finally happening. Yay!

--
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/CACj%3DBEhbm7sWL3t7of%3DmU6Ormy6x513%3D%3Dvegka9a4YSk%2BX%3Di%3Dg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages