Add support for the 'revert-layer' keyword
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
| 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
|
Reporter | |
Updated•3 years ago
|
|
Assignee | |
Comment 2•2 years ago
|
||
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.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 3•2 years ago
|
||
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
|
||
Comment 5•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4612b891713e
https://hg.mozilla.org/mozilla-central/rev/97099edbe369
|
|
Reporter | |
Updated•2 years ago
|
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!
|
|
Assignee | |
Comment 7•2 years ago
|
||
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 thethemelayer 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 werevert-layerat thethemelayer, 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 thethemelayer 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 werevert-layerat thethemelayer, 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-layerinthemelayer,<div class="bottom">is cyan (base). - However, if no
div { }is defined inbase,<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!
Description
•