Intent to Ship: 'revert' keyword

398 views
Skip to first unread message

Anders Hartvoll Ruud

unread,
Mar 25, 2020, 9:58:05 AM3/25/20
to blink-dev

Contact emails

and...@chromium.org


Explainer

This allows an author to roll back the cascade to the previous cascade level. This is mainly useful if you want to reset an element to the style provided by the user-agent.


For example, specifying 'all:revert' on a <div> element, will cause e.g. the 'display' property to compute to 'block' (as specified by the UA sheet)*. Contrast this with the best approximation of a "reset" we have currently (all:unset), which would set the 'display' property of a <div> to 'inline', which is less useful. The author currently needs to manually re-apply the user-agent style to get the desired behavior.


*: Assuming no extensions/user-styles.


Spec

https://drafts.csswg.org/css-cascade/#default


Unsure about TAG review status. This is however already shipped by Firefox and Safari.


Link to “Intent to Prototype” blink-dev discussion

N/A


Link to Origin Trial feedback summary

N/A


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo link

N/A


Debuggability

No extra work should be needed for devtools support.


Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Shipped

Safari: Shipped

Web / Framework developers: The bug as 75 stars at the time of writing.


Ergonomics

N/A


Activation

N/A


Code-wise impact

Currently there's a desire to make less "sweeping changes" because of the COVID-19/release situation. This change is almost entirely isolated to third_party/blink/renderer/core/css. For example, the change is invisible to layout and paint, since 'revert' is an instruction for the cascade (hence, it does not end up on ComputedStyle).


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.


https://wpt.fyi/results/css/css-cascade?label=master&label=experimental&aligned&q=revert


Although there is some coverage already, there is room for improvement on the WPT side. My CLs will add tests for:


- 'revert' in @keyframes

- 'revert' in css-typed-om

- 'revert' with registered custom properties

- 'revert' via css-logical properties

- 'revert' using the 'all' property


... all of which are currently missing, or partially missing.


Entry on the feature dashboard

Please include a deeplink (e.g. http://www.chromestatus.com/feature/4785074604081152). If there’s no entry, please explain why you think this change doesn’t need one (eg “small change”, “fits under an existing entry”). You may be asked to create one.

Anders Hartvoll Ruud

unread,
Mar 25, 2020, 10:00:58 AM3/25/20
to blink-dev

Yoav Weiss

unread,
Mar 26, 2020, 5:30:01 AM3/26/20
to Anders Hartvoll Ruud, blink-dev
LGTM1 as this is catching up with what's already shipped Firefox and Safari, therefore reducing interop risk while providing developers with better tools. 

Thanks for improving the tests!
 

Entry on the feature dashboard

Please include a deeplink (e.g. http://www.chromestatus.com/feature/4785074604081152). If there’s no entry, please explain why you think this change doesn’t need one (eg “small change”, “fits under an existing entry”). You may be asked to create one.

--
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/CAKFBnUqPo7M3ncbEZSOmCd-iPCOwb_ENMm8Fg-wS_4VpH0V0pA%40mail.gmail.com.

Mike West

unread,
Mar 26, 2020, 8:22:41 AM3/26/20
to Yoav Weiss, Anders Hartvoll Ruud, blink-dev
LGTM2, for similar reasons.

I do wonder about the devtools support, though. It seems like we'd want to do some work there to expose `revert`'s behavior in the cascade. Have you talked with the devtools team about it?

-mike


Daniel Bratell

unread,
Mar 26, 2020, 9:38:54 AM3/26/20
to blin...@chromium.org

LGTM3 (but note Mike's question)

/Daniel

Chris Harrelson

unread,
Mar 26, 2020, 1:51:12 PM3/26/20
to Daniel Bratell, blink-dev
Also: this intent is actually an intent to implement-and-ship, correct?

Anders Hartvoll Ruud

unread,
Mar 27, 2020, 2:50:50 AM3/27/20
to Chris Harrelson, Daniel Bratell, blink-dev
On Thu, Mar 26, 2020 at 6:51 PM Chris Harrelson <chri...@chromium.org> wrote:
Also: this intent is actually an intent to implement-and-ship, correct?

In the sense that no code has landed on master yet, yes. (But the work is not at an early stage either: it's almost done).

On Thu, Mar 26, 2020 at 6:38 AM Daniel Bratell <brat...@gmail.com> wrote:

LGTM3 (but note Mike's question)

/Daniel

On 2020-03-26 13:22, Mike West wrote:
LGTM2, for similar reasons.

I do wonder about the devtools support, though. It seems like we'd want to do some work there to expose `revert`'s behavior in the cascade. Have you talked with the devtools team about it?

-mike
I haven't, but the current behavior is the same as the other css-wide keywords. I.e. 'revert' appears as the winning declaration in the "Styles" panel, and in "Computed" the computed value is shown, expandable to the 'revert' declaration that caused it. I think it's fine.

But I can reach out to the devtools team. What specifically would you like to see, though? Showing which cascade origin we reverted to?

Mike West

unread,
Mar 27, 2020, 3:12:38 AM3/27/20
to Anders Hartvoll Ruud, Chris Harrelson, Daniel Bratell, blink-dev
On Fri, Mar 27, 2020 at 7:50 AM Anders Hartvoll Ruud <and...@chromium.org> wrote:
On Thu, Mar 26, 2020 at 6:51 PM Chris Harrelson <chri...@chromium.org> wrote:
Also: this intent is actually an intent to implement-and-ship, correct?

In the sense that no code has landed on master yet, yes. (But the work is not at an early stage either: it's almost done).

On Thu, Mar 26, 2020 at 6:38 AM Daniel Bratell <brat...@gmail.com> wrote:

LGTM3 (but note Mike's question)

/Daniel

On 2020-03-26 13:22, Mike West wrote:
LGTM2, for similar reasons.

I do wonder about the devtools support, though. It seems like we'd want to do some work there to expose `revert`'s behavior in the cascade. Have you talked with the devtools team about it?

-mike
I haven't, but the current behavior is the same as the other css-wide keywords. I.e. 'revert' appears as the winning declaration in the "Styles" panel, and in "Computed" the computed value is shown, expandable to the 'revert' declaration that caused it. I think it's fine.

But I can reach out to the devtools team. What specifically would you like to see, though? Showing which cascade origin we reverted to?

I don't have a specific suggestion, I'm just asking you to ask the devtools team, as I expect them to have opinions about how they'd like to represent this cascade. What you've got now might well be perfect, but it seems reasonable to let the folks responsible for that interface weigh in. :)

-mike
 

Anders Hartvoll Ruud

unread,
Mar 27, 2020, 3:56:31 AM3/27/20
to Mike West, Chris Harrelson, Daniel Bratell, blink-dev
On Fri, Mar 27, 2020 at 8:12 AM Mike West <mk...@chromium.org> wrote:
On Fri, Mar 27, 2020 at 7:50 AM Anders Hartvoll Ruud <and...@chromium.org> wrote:
On Thu, Mar 26, 2020 at 6:51 PM Chris Harrelson <chri...@chromium.org> wrote:
Also: this intent is actually an intent to implement-and-ship, correct?

In the sense that no code has landed on master yet, yes. (But the work is not at an early stage either: it's almost done).

On Thu, Mar 26, 2020 at 6:38 AM Daniel Bratell <brat...@gmail.com> wrote:

LGTM3 (but note Mike's question)

/Daniel

On 2020-03-26 13:22, Mike West wrote:
LGTM2, for similar reasons.

I do wonder about the devtools support, though. It seems like we'd want to do some work there to expose `revert`'s behavior in the cascade. Have you talked with the devtools team about it?

-mike
I haven't, but the current behavior is the same as the other css-wide keywords. I.e. 'revert' appears as the winning declaration in the "Styles" panel, and in "Computed" the computed value is shown, expandable to the 'revert' declaration that caused it. I think it's fine.

But I can reach out to the devtools team. What specifically would you like to see, though? Showing which cascade origin we reverted to?

I don't have a specific suggestion, I'm just asking you to ask the devtools team, as I expect them to have opinions about how they'd like to represent this cascade. What you've got now might well be perfect, but it seems reasonable to let the folks responsible for that interface weigh in. :)

-mike
 

Of course. Done.

Joe Medley

unread,
Mar 27, 2020, 12:33:24 PM3/27/20
to Anders Hartvoll Ruud, blink-dev
Can you please create a Chrome Status entry.
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


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

Anders Hartvoll Ruud

unread,
Mar 30, 2020, 4:01:46 AM3/30/20
to Joe Medley, blink-dev
On Fri, Mar 27, 2020 at 5:33 PM Joe Medley <jme...@google.com> wrote:
Can you please create a Chrome Status entry.

I did! (Just failed to include it in the original post).
Reply all
Reply to author
Forward
0 new messages