Intent to Spec, Implement & Ship: CSS Variables: Persistent guaranteed-invalid values

[Anders Hartvoll Ruud]

Contact emails

and...@chromium.org

Specification

https://drafts.csswg.org/css-variables/

Summary

There is a desire to change the fallback/invalid-value handling of custom properties, and all major browser engine vendors seem to be on board with the change, provided that we don't think it's a compat issue. Hence I'm sending this I2S to determine that.

Note that the order of things is a bit irregular this time: approved IS2 -> then make the spec edit via the normal CSSWG process -> then ship. This is because we'll probably just not make the change (to the spec) if we think it's a compat issue here. (At least until some other browser vendor comes to a different conclusion).

What we want to change:

Whenever a custom property references another unknown (or guaranteed-invalid) custom property, that custom property becomes invalid at computed-value time (IACVT).

<style>
  #outer { --x: foo; }
  #inner { --x: var(--unknown); } /* --x becomes IACVT */
</style>
<div id=outer>
  <div id=inner></div>
<div>

So what is the computed value of '--x' on #inner in this case? This is what we want to change.

The current behavior is that IACVT causes --x to behave as 'unset', and since custom properties inherit by default, the computed value becomes ' foo'.

The desired behavior is that IACVT causes --x to become the guaranteed-invalid value, hence it does not inherit from #outer, and gets no computed value at all.

Why:

1. There are certain "nested component patterns" that are more ergonomic if the guaranteed-invalid value is allowed to persist through the custom property reference chain. This is because the guaranteed-invalid value can trigger fallbacks, and having the guaranteed-invalid value persist means the author has greater control over when fallbacks happen, without "interference" from inheritance which might make some intermediate custom property suddenly not guaranteed-invalid anymore.

Here is an example provided by an author (source).

(The innermost "smaller input" is not smaller, because of inheritance "interfering" with the fallback mechanism).

This issue can be worked around by wrapping the component in an element as a "reset layer", but this is not always desirable.

2. A model in which the guranteed-invalid value is recognized as part of the value space of custom properties is more consistent and useful for our future plans for invalid-value handling of registered custom properties. (E.g. you can't currently register a property as a <color>, and also utilize the fallback functionality, but we want to allow that in the future). Tab explains about this in this comment.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

I've added a use-counter for this which currently shows that ~0.02% of page loads may be affected by this. This is an upper-bound, and it does not automatically mean that 0.02% of page loads are broken, but that up to 0.02% can be affected. (Crafting a perfect use-counter is hard ...)

Gecko: emilio@ seems willing to change Gecko: https://github.com/w3c/csswg-drafts/issues/5370#issuecomment-665601918

Edge: No signal

WebKit: smfr@ seems willing to change Webkit, if we don't think it's a compat issue. https://github.com/w3c/csswg-drafts/issues/5370#issuecomment-669723384

Is this feature fully tested by web-platform-tests?

We have WPTs that test the old behavior. I'll adjust them if/when the new behavior ships.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1110188

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6265214410424320

This intent message was generated by Chrome Platform Status.

[Manuel Rego Casasnovas]

On 07/01/2021 15:02, Anders Hartvoll Ruud wrote:
>
> Interoperability and Compatibility
>
> I've added a use-counter

> <https://www.chromestatus.com/metrics/feature/timeline/popularity/3377>

> for this which currently shows that ~0.02% of page loads may be affected
> by this. This is an upper-bound, and it does not automatically mean that

> 0.02% of page loads are broken, but that /up to/0.02% /can/ be affected.

> (Crafting a perfect use-counter is hard ...)

How bad is the breakage? Have you tested some of the sites that are
hitting the use counter to check if there are regressions or not?

Bye,
Rego

[Anders Hartvoll Ruud]

I was planning to do that, but the list of sites which hit the use-counter is empty. (I guess this means affected sites are not in the HTTP Archive?)

 

Bye,
   Rego

[Chris Harrelson]

If you're referring to the widget on the chromestatus.com page, I think it's probably just that there hasn't been another run of the HTTPArchive table generation with the version of Chrome you added the UseCounter in. There should be a way to verify that on the archive site..

 

 

Bye,
   Rego

--
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/CAKFBnUo7FkaqH%3D4ecBr8u9BsR%3Dpisg7BmRMW5QOY5nMWy1zoxw%40mail.gmail.com.

[Manuel Rego Casasnovas]

On 11/01/2021 17:33, Chris Harrelson wrote:
>
>
> On Mon, Jan 11, 2021 at 4:29 AM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
>
>
> On Thu, Jan 7, 2021 at 8:55 PM Manuel Rego Casasnovas
> <re...@igalia.com <mailto:re...@igalia.com>> wrote:
>
>
>
> On 07/01/2021 15:02, Anders Hartvoll Ruud wrote:
> >
> >         Interoperability and Compatibility
> >
> > I've added a use-counter
> >
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/3377
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/3377>>
>
> > for this which currently shows that ~0.02% of page loads may
> be affected
> > by this. This is an upper-bound, and it does not
> automatically mean that
> > 0.02% of page loads are broken, but that /up to/0.02% /can/
> be affected.
> > (Crafting a perfect use-counter is hard ...)
>
> How bad is the breakage? Have you tested some of the sites that are
> hitting the use counter to check if there are regressions or not?
>
>
> I was planning to do that, but the list of sites which hit the
> use-counter is empty. (I guess this means affected sites are not in
> the HTTP Archive?)
>
>
> If you're referring to the widget on the chromestatus.com

> <http://chromestatus.com> page, I think it's probably just that there

> hasn't been another run of the HTTPArchive table generation with the
> version of Chrome you added the UseCounter in. There should be a way to
> verify that on the archive site..

Another option is to query the HTTPArchive manually to verify that you
cannot get any URL.

It'd be nice to understand the kind of breakage this might cause or not.

Bye,
Rego

[Anders Hartvoll Ruud]

Thanks, I didn't know that was possible. I can confirm that I get an empty result by querying manually (using the query shown on chromestatus.com), and I do get something when querying for a more established use-counter (CSSAtRuleFontFace).

However, I suspect Chris is right; I tested a few other use-counters added after CSSInvalidVariableUnset, and they are also suspiciously empty (also when queried manually). The HTTP Archive table does contain recent data (from december), but the Chrome version used is probably old.

So I guess we'll wait for that data to come in.

[Anders Hartvoll Ruud]

The data is in, it lists only 10 sites, and I've now tested all of them:

tl;dr: Can't find any breakage.

Detailed investigation:

1. https://oen.pressbooks.pub/

Offending declaration: --primary-dark: var(--footer-color)

Picked up by the use-counter because of --footer-color not existing. The custom property --primary-dark will now become invalid instead of the inherited value of rgb(131,35,128), but it doesn't seem to matter, since --primary-dark doesn't seem to be referenced by anything. When toggling the declaration of/off in devtools, nothing happens.

2. https://haval-autolight.ru/

Couldn't find the offending declaration. Nothing obviously broken.

3. https://wisc.pb.unizin.org/

This is Pressbooks-based, so it's exactly the same as (1).

4. https://shop-pobedinedug.ru/

Couldn't find the offending declaration. Nothing obviously broken.

5. https://methodes.pressbooks.com/

Pressbooks-based, same as (1).

6. https://promotions.comeon.com/

Offending declaration: --footer-payment-icon: var(--footer-payment-icon-inverted)

Doesn't seem like --footer-payment-icon is referenced by anything. Nothing changes when the declaration is toggled.

7. https://clamphitsuzen.pressbooks.com/

Pressbooks-based, same as (1).

8. https://pressbooks.bccampus.ca/

Pressbooks-based, same as (1).

9. http://pressbooks-dev.oer.hawaii.edu/

Pressbooks-based, same as (1).

10. https://install.advancedrestclient.com/

Offending declaration: --light-primary-color: var(--paper-indygo-100)

Yet another case where the affected custom property isn't used. Nothing changes when the declaration is toggled.

For the record, since some of the custom property names sound like they are theme-related, I also tested using --force-dark-mode, but it had no effect on the results. (None of the sites responded to the dark mode).

[Chris Harrelson]

LGTM1! Thanks for the thorough investigation.

--

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/CAKFBnUq4Dv_E%3D_aEAcUH8OnQeT1gu-vv1JHfJ2SHndShUjaLvA%40mail.gmail.com.

[Manuel Rego Casasnovas]

LGTM2.

Maybe you could contact pressbooks.pub (as several cases were related to
that) so they're aware of the issue and maybe they can fix it.

Bye,
Rego

On 16/02/2021 01:51, Chris Harrelson wrote:
> LGTM1! Thanks for the thorough investigation.
>
> On Mon, Feb 15, 2021 at 6:03 AM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
>
>
> On Tue, Jan 12, 2021 at 10:46 AM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
>
>
> On Tue, Jan 12, 2021 at 7:55 AM Manuel Rego Casasnovas
> <re...@igalia.com <mailto:re...@igalia.com>> wrote:
>
>
>
> On 11/01/2021 17:33, Chris Harrelson wrote:
> >
> >
> > On Mon, Jan 11, 2021 at 4:29 AM Anders Hartvoll Ruud
> > <and...@chromium.org <mailto:and...@chromium.org>

> <mailto:and...@chromium.org <mailto:and...@chromium.org>>>

> wrote:
> >
> >
> >
> >     On Thu, Jan 7, 2021 at 8:55 PM Manuel Rego Casasnovas
> >     <re...@igalia.com <mailto:re...@igalia.com>

> > <http://chromestatus.com <http://chromestatus.com>> page,

> I think it's probably just that there
> > hasn't been another run of the HTTPArchive table
> generation with the
> > version of Chrome you added the UseCounter in. There
> should be a way to
> > verify that on the archive site..
>
> Another option is to query the HTTPArchive manually to
> verify that you
> cannot get any URL.
>
>
> Thanks, I didn't know that was possible. I can confirm that I
> get an empty result by querying manually (using the query shown

> on chromestatus.com <http://chromestatus.com>), and I /do/ get

> something when querying for a more established use-counter
> (CSSAtRuleFontFace).
>
> However, I suspect Chris is right; I tested a few other
> use-counters added after CSSInvalidVariableUnset, and they are
> also suspiciously empty (also when queried manually). The HTTP
> Archive table does contain recent data (from december), but the
> Chrome version used is probably old.
>
> So I guess we'll wait for that data to come in.
>
>
> The data is in, it lists only 10 sites, and I've now tested all of them:
>

> *tl;dr: Can't find any breakage.*
>
> Detailed investigation:
>
> 1. https://oen.pressbooks.pub/ <https://oen.pressbooks.pub/>

>
> Offending declaration: --primary-dark: var(--footer-color)
>
> Picked up by the use-counter because of --footer-color not
> existing. The custom property --primary-dark will now become
> invalid instead of the inherited value of rgb(131,35,128), but
> it doesn't seem to matter, since --primary-dark doesn't seem to
> be referenced by anything. When toggling the declaration of/off
> in devtools, nothing happens.
>

> 2. https://haval-autolight.ru/ <https://haval-autolight.ru/>

>
> Couldn't find the offending declaration. Nothing obviously broken.
>

> 3. https://wisc.pb.unizin.org/ <https://wisc.pb.unizin.org/>

>
> This is Pressbooks-based, so it's exactly the same as (1).
>

> 4. https://shop-pobedinedug.ru/ <https://shop-pobedinedug.ru/>

>
> Couldn't find the offending declaration. Nothing obviously broken.
>
> 5. https://methodes.pressbooks.com/
> <https://methodes.pressbooks.com/>
>
> Pressbooks-based, same as (1).
>

> 6. https://promotions.comeon.com/ <https://promotions.comeon.com/>

>
> Offending declaration: --footer-payment-icon:
> var(--footer-payment-icon-inverted)
>
> Doesn't seem like --footer-payment-icon is referenced by
> anything. Nothing changes when the declaration is toggled.
>
> 7. https://clamphitsuzen.pressbooks.com/
> <https://clamphitsuzen.pressbooks.com/>
>
> Pressbooks-based, same as (1).
>

> 8. https://pressbooks.bccampus.ca/ <https://pressbooks.bccampus.ca/>

>
> Pressbooks-based, same as (1).
>
> 9. http://pressbooks-dev.oer.hawaii.edu/
> <http://pressbooks-dev.oer.hawaii.edu/>
>
> Pressbooks-based, same as (1).
>
> 10. https://install.advancedrestclient.com/
> <https://install.advancedrestclient.com/>
>
> Offending declaration: --light-primary-color:
> var(--paper-indygo-100)
>
> Yet another case where the affected custom property isn't used.
> Nothing changes when the declaration is toggled.
>
> For the record, since some of the custom property names sound like
> they are theme-related, I also tested using --force-dark-mode, but
> it had no effect on the results. (None of the sites responded to the
> dark mode).
>
>
> It'd be nice to understand the kind of breakage this might
> cause or not.
>
> Bye,
>    Rego
>
> --
> 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/CAKFBnUq4Dv_E%3D_aEAcUH8OnQeT1gu-vv1JHfJ2SHndShUjaLvA%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUq4Dv_E%3D_aEAcUH8OnQeT1gu-vv1JHfJ2SHndShUjaLvA%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%2Bw9ZuHHXngwcrwcgmQd%3DLV5ECdM%3DJhw8D1oTRvnZZeGcig%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ZuHHXngwcrwcgmQd%3DLV5ECdM%3DJhw8D1oTRvnZZeGcig%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Yoav Weiss]

LGTM3

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/57f42dad-6ff6-45d8-41b0-e7ca8a9c4849%40igalia.com.