Closed Bug 1699220 Opened 4 years ago Closed 3 years ago

Add support for the 'revert-layer' keyword

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
97 Branch
Tracking Status
firefox97 --- fixed

People

(Reporter: sebo, Assigned: emilio)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

The CSS Cascading and Inheritance Module Level 5 introduces a revert-layer keyword for properties that rolls back the cascaded value to the layer below.

This bug is meant to track the implementation of this keyword.

Sebastian

This patch looks bigger than it is, but it's mostly because
of plumbing.

To implement revert-layer we need not only the cascade origin of the
declaration, but the whole cascade level, plus also the layer order.

In order to do this, encapsulate these two things inside a 32-bit
CascadePriority struct and plumb it through the rule tree and so on.
This allows us to remove the packing and unpacking of CascadeLevel,
though I kept the ShadowCascadeOrder limit for now in case we need to
reintroduce it.

Fix !important behavior of layers while at it (implementing it in
CascadeLevel::cmp, spec quote included since it was tricky to find)
since some revert-layer tests were depending on it.

The style attribute test is failing now, but follow-up commit fixes
it, see spec issue.

In terms of the actual keyword implementation, it's sort of
straight-forward: We implement revert and revert-layer in a shared
way, by storing the cascade priority that reverted it.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

By modeling it as a separate layer that behaves somewhat specially.

See https://github.com/w3c/csswg-drafts/issues/6872.

The remaining revert-layer tests that we fail are because either we
don't implement a feature (like @property) or because it's used in
keyframes (where revert is a bit unspecified and we have existing
issues with it).

Depends on D133372

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4612b891713e Add support for the revert-layer keyword. r=boris https://hg.mozilla.org/integration/autoland/rev/97099edbe369 Fix style attribute important and revert-layer behavior. r=firefox-style-system-reviewers,layout-reviewers,boris
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Regressions: 1746620
Blocks: interop2022

Hello, I am documenting the "revert-layer" keyword. I require some help in understanding the implementation. While I am getting expected results in most cases, but for others I am seeing results different from what I understand. I have put my example code here: https://codepen.io/dipikabh/pen/BaJpQzo?editors=1100. I have added a table at the bottom that explains the different scenarios I am exploring and the scenario where I am seeing unexpected result.
I would really appreciate if someone could help me out. Thanks!

Sure, that's working as expected. The last case is a bit tricky, but the explanation is this. Test-case is, if I understand correctly:

<!doctype html>
<style>
@layer base, theme;

@layer base {
  .top {
    color: red;
  }
}

@layer theme {
  .top {
    color: green;
  }

  .bottom {
    color: revert-layer;
  }
}

.top, .bottom {
  font-size: 30px;
  margin: 1em;
}
</style>
<div class="top">
  This is on the top.
  <div class="bottom">
    This is in the bottom.
  </div>
</div>
  • <div class="top"> is clearly green, from the theme layer rule, so far so good.
  • <div class="bottom"> only matches two rules: .top, .bottom { } (which doesn't affect color) and .bottom { color: revert-layer }. So we revert-layer at the theme layer, but there's no other layer to revert to (note that .top { color: red } doesn't match <div class="bottom">). So instead it behaves as initial, which is inheriting the top color, which is green.

Does that make sense?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Sure, that's working as expected. The last case is a bit tricky, but the explanation is this. Test-case is, if I understand correctly:

  • <div class="top"> is clearly green, from the theme layer rule, so far so good.
  • <div class="bottom"> only matches two rules: .top, .bottom { } (which doesn't affect color) and .bottom { color: revert-layer }. So we revert-layer at the theme layer, but there's no other layer to revert to (note that .top { color: red } doesn't match <div class="bottom">). So instead it behaves as initial, which is inheriting the top color, which is green.

Does that make sense?

Thanks, :emilio, for taking the time to answer my query. This makes sense now!
Could you clarify the behavior in one more scenario?

<!doctype html>
<style>
@layer base, theme;

@layer base {
    div {
        color: cyan;
    }
}

@layer theme {
    .bottom {
        color: revert-layer;
    }

    div {
        color: yellow;
    }
}

.top, .bottom {
  font-size: 30px;
  margin: 1em;
}
</style>
<div class="top">
  This is on the top.
  <div class="bottom">
    This is in the bottom.
  </div>
</div>

In this case, div { } is in both theme and base.

  • With revert-layer in theme layer, <div class="bottom"> is cyan (base).
  • However, if no div { } is defined in base, <div class="bottom"> becomes yellow (theme).

So is the behavior to look for matching rule in previous layer and if none exists, inherit from current layer, if one exists?

The following line from the spec led me to expect the opposite, probably because I somehow (mis)read that as 'lower-priority' declarations in the same cascade 'layer', and thats why I was expecting div { color: yellow; } to take precedence over div { color: cyan; }

Note: If there are no lower-priority declarations in the same cascade origin as the revert-layer value, the cascaded value will roll back to the previous origin.

Doc updates for this new keyword can be tracked here: https://github.com/mdn/content/issues/13373

I also just submitted a PR that documents the revert-layer keyword. I would appreciate a technical review and review comments. Thank you!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: