Intent to Implement and Ship: 'auto' keyword for '-webkit-appearance' CSS property

[TAMURA, Kent]

Contact emails tk...@chromium.org Explainer N/A Design docs/spec Specification: https://drafts.csswg.org/css-ui-4/#valdef-appearance-auto TAG review None; This is a very small addition to an existing feature Summary '-webkit-appearance' CSS property will have new 'auto' keyword, which indicates the default appearance of the target element. Motivation It's hard to remember correct keywords for each of element types. For example, what's the correct keyword for the default appearance of <input type=range>; 'slider', '-webkit-slider', 'horizontal-slider', 'horizontalslider', 'or slider-horizontal'? Risks

Interoperability and Compatibility No compatibility risk. This is a new feature and won't break existing behavior. Low interoperability risk. A Firefox engineer expressed support for this change in private email. Firefox: No public signals Edge: No public signals Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-January/031026.html) No response Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/css/css-ui Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=965432 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5913213940006912

--

TAMURA Kent
Software Engineer, Google

[Mounir Lamouri]

This is a small addition that pushes the appearance property in the right direction, non-owner LGTM.

I'm wondering if we could link to a Firefox bug for this in chromestatus or file one if there isn't?

-- Mounir

--
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/CAGH7WqEYbeEV69uyYo6tgSxZSvcZnaExFXPT5%2BeJJX7WUuY63w%40mail.gmail.com.

[Simon Pieters]

I support this intent.

I would say that the compatibility risk is (probably very) low, but not zero. There are pages that use 'appearance: auto' or '-webkit-appearance: auto', and some expect it to be ignored like today. In httparchive I see 626 occurrences in 510 pages (~0.01% of all pages).

https://docs.google.com/spreadsheets/d/1Idrp1kfqmBikCPW2TAbvq4hxE3oL9YYkQRXb7YbAhEA/edit?usp=sharing

cheers,

--

Simon Pieters

Bocoup https://bocoup.com/

[Simon Pieters]

Den tors 5 mars 2020 kl 15:15 skrev Simon Pieters <si...@bocoup.com>:

I support this intent.

I would say that the compatibility risk is (probably very) low, but not zero. There are pages that use 'appearance: auto' or '-webkit-appearance: auto', and some expect it to be ignored like today.

Sorry, I missed a word. Some *may* expect it to be ignored. I haven't analyzed any of these cases.

 

In httparchive I see 626 occurrences in 510 pages (~0.01% of all pages).

https://docs.google.com/spreadsheets/d/1Idrp1kfqmBikCPW2TAbvq4hxE3oL9YYkQRXb7YbAhEA/edit?usp=sharing

cheers,

--

Simon Pieters

https://bocoup.com/

[Yoav Weiss]

The motivation section explains why we'd want to ship the new behavior for the non-prefixed variant.

Why would we change the prefixed variant?

--

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/CAHWN20Vr%3DpSK4qUfNissZ%2BvZYp0EkjNN-Ks6tBX62JFBGdqyaQ%40mail.gmail.com.

[Simon Pieters]

Den tors 5 mars 2020 kl 23:11 skrev Yoav Weiss <yo...@yoav.ws>:

The motivation section explains why we'd want to ship the new behavior for the non-prefixed variant.

Why would we change the prefixed variant?

To make '-webkit-appearance' a proper "legacy alias name" of 'appearance'. If they support different keywords, they aren't quite aliases, which I believe would complicate the implementation. Supporting different sets of keywords seems like it could be confusing to web developers, too.

[Chris Harrelson]

The problem is that we have a policy of not shipping updates to prefixed CSS features. If the reason to do so is mostly to avoid a small implementation difficulty (a conditional treatment in this case), then it seems we should just accept that difficulty. If developers want to use "auto" then they could just unprefix their usage, right?

--

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/CAHWN20VF9W4wfHdWuyvXGViwnZr2Xdk6g3RA0ozG34OS%2BYabgQ%40mail.gmail.com.

[Emilio Cobos Álvarez]

On 3/6/20 1:06 AM, Chris Harrelson wrote:
> The problem is that we have a policy of not shipping updates to prefixed
> CSS features. If the reason to do so is mostly to avoid a small
> implementation difficulty (a conditional treatment in this case), then
> it seems we should just accept that difficulty. If developers want to
> use "auto" then they could just unprefix their usage, right?

Making them two independent properties has been tried before and is not
web-compatible, see:

https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

If you don't make them an alias, now you have the problem of what to
serialize when you specify `appearance: auto` and ask for
`getComputedStyle(element).WebkitAppearance`, which seems
not-particularly-trivial to solve.

So I wouldn't consider it _just_ an implementation difficulty.

-- Emilio

>
> On Thu, Mar 5, 2020 at 2:53 PM Simon Pieters <zco...@gmail.com
> <mailto:zco...@gmail.com>> wrote:
>
>
>
> Den tors 5 mars 2020 kl 23:11 skrev Yoav Weiss <yo...@yoav.ws

> <mailto:yo...@yoav.ws>>:

>
> The motivation section explains why we'd want to ship the new
> behavior for the non-prefixed variant.
> Why would we change the prefixed variant?
>
>
> To make '-webkit-appearance' a proper "legacy alias name" of
> 'appearance'. If they support different keywords, they aren't quite
> aliases, which I believe would complicate the implementation.
> Supporting different sets of keywords seems like it could be
> confusing to web developers, too.
>
> --
> Simon Pieters

> https://bocoup.com/ <https://bocoup.com/>

>
> --
> 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

> <mailto:blink-dev+...@chromium.org>.

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

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHWN20VF9W4wfHdWuyvXGViwnZr2Xdk6g3RA0ozG34OS%2BYabgQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9EOb_vYvS3OpibD-Vd%3DnbLoXp9MJ6AnQaFB2AbavQM4A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9EOb_vYvS3OpibD-Vd%3DnbLoXp9MJ6AnQaFB2AbavQM4A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Simon Pieters]

Den fre 6 mars 2020 kl 01:52 skrev Emilio Cobos Álvarez <emi...@mozilla.com>:

On 3/6/20 1:06 AM, Chris Harrelson wrote:
> The problem is that we have a policy of not shipping updates to prefixed
> CSS features.

I didn't know about this policy. Where is it documented? I found http://www.chromium.org/blink#vendor-prefixes but I think it doesn't say what you said.

> If the reason to do so is mostly to avoid a small
> implementation difficulty (a conditional treatment in this case), then
> it seems we should just accept that difficulty. If developers want to
> use "auto" then they could just unprefix their usage, right?

Making them two independent properties has been tried before and is not
web-compatible, see:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

If you don't make them an alias, now you have the problem of what to
serialize when you specify `appearance: auto` and ask for
`getComputedStyle(element).WebkitAppearance`, which seems
not-particularly-trivial to solve.

I think the easy way is to serialize 'auto'. But then it's inconsistent with what is accepted for input.

So I wouldn't consider it _just_ an implementation difficulty.

 

What Emilio said. :-)

I noticed that the spec for "legacy name alias" mentions "or a subset of the value space". I don't know which property exercises this, if any. It also doesn't say to do anything different for serialization, making the subset only a parse-time subset.

[Chris Harrelson]

On Thu, Mar 5, 2020 at 5:35 PM Simon Pieters <zco...@gmail.com> wrote:

Den fre 6 mars 2020 kl 01:52 skrev Emilio Cobos Álvarez <emi...@mozilla.com>:

On 3/6/20 1:06 AM, Chris Harrelson wrote:
> The problem is that we have a policy of not shipping updates to prefixed
> CSS features.

I didn't know about this policy. Where is it documented? I found http://www.chromium.org/blink#vendor-prefixes but I think it doesn't say what you said.

Hmm, interesting. Maybe it's not documented on the site, I'll fix it. However, we have had this policy for a long time, since "updates to prefixed CSS features" and "new prefixed CSS features" are sometimes not distinguishable, and does not achieve our goals of interop or reducing use of prefixing.

 

> If the reason to do so is mostly to avoid a small
> implementation difficulty (a conditional treatment in this case), then
> it seems we should just accept that difficulty. If developers want to
> use "auto" then they could just unprefix their usage, right?

Making them two independent properties has been tried before and is not
web-compatible, see:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

If you don't make them an alias, now you have the problem of what to
serialize when you specify `appearance: auto` and ask for
`getComputedStyle(element).WebkitAppearance`, which seems
not-particularly-trivial to solve.

I think the easy way is to serialize 'auto'. But then it's inconsistent with what is accepted for input.

So I wouldn't consider it _just_ an implementation difficulty.

 

What Emilio said. :-)

I noticed that the spec for "legacy name alias" mentions "or a subset of the value space". I don't know which property exercises this, if any. It also doesn't say to do anything different for serialization, making the subset only a parse-time subset.

Got it. You've convinced me that this is not trivial and not worth the effort to deal with in this case!

LGTM1 to ship, assuming auto will also be on the unprefixed version of 'appearance', which I think is implied by the other intent?

[TAMURA, Kent]

On Fri, Mar 6, 2020 at 10:54 AM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Mar 5, 2020 at 5:35 PM Simon Pieters <zco...@gmail.com> wrote:

Den fre 6 mars 2020 kl 01:52 skrev Emilio Cobos Álvarez <emi...@mozilla.com>:

On 3/6/20 1:06 AM, Chris Harrelson wrote:
> The problem is that we have a policy of not shipping updates to prefixed
> CSS features.

I didn't know about this policy. Where is it documented? I found http://www.chromium.org/blink#vendor-prefixes but I think it doesn't say what you said.

Hmm, interesting. Maybe it's not documented on the site, I'll fix it. However, we have had this policy for a long time, since "updates to prefixed CSS features" and "new prefixed CSS features" are sometimes not distinguishable, and does not achieve our goals of interop or reducing use of prefixing.

I also think we have the policy.

I remember we had a similar intent, adding new keywords or behavior to a prefixed property, and we approved it.  But I don't remember what it was.

Also, in this case, css-ui specifies -webkit-appearance.  It's different from other prefixed properties

 

 

> If the reason to do so is mostly to avoid a small
> implementation difficulty (a conditional treatment in this case), then
> it seems we should just accept that difficulty. If developers want to
> use "auto" then they could just unprefix their usage, right?

Making them two independent properties has been tried before and is not
web-compatible, see:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

If you don't make them an alias, now you have the problem of what to
serialize when you specify `appearance: auto` and ask for
`getComputedStyle(element).WebkitAppearance`, which seems
not-particularly-trivial to solve.

I think the easy way is to serialize 'auto'. But then it's inconsistent with what is accepted for input.

So I wouldn't consider it _just_ an implementation difficulty.

 

What Emilio said. :-)

I noticed that the spec for "legacy name alias" mentions "or a subset of the value space". I don't know which property exercises this, if any. It also doesn't say to do anything different for serialization, making the subset only a parse-time subset.

Got it. You've convinced me that this is not trivial and not worth the effort to deal with in this case!

LGTM1 to ship, assuming auto will also be on the unprefixed version of 'appearance', which I think is implied by the other intent?

Yes.

 

--
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/CAOMQ%2Bw8RUP_QoHB_9y0SWMP0yhx5eFk7kCHfrPWuBg8Oi6r6XA%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEDm-ffGw7X2LJEnMiBHu3w2CDG-aHR%2BfArbAE6oddVjw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

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

--

TAMURA Kent
Software Engineer, Google

--
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 blin...@chromium.org.