-
Notifications
You must be signed in to change notification settings - Fork 707
[css-cascade] Do we need a keyword similar to revert
, but for cascade layers?
#5793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We should make sure that the preshint rules are given their own layer so that this works to unwind author rules without affecting preshint mapping. See #5836. |
In another conversation, @fantasai suggested This would roll back the cascaded value of a declaration to the previous layer with a value specified, as if no current-layer rules were specified for this property on this element. |
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: CSS Cascade 5<bkardell_> q- <Rossen_> github: https://github.com//issues/5793 <fantasai> miriam: Cascade layers work like origins in that they stack on top of each other, containing specificity <fantasai> miriam: with origins, useful to revert to previous origns <fantasai> miriam: suggestion that this might be useful for layers <fantasai> miriam: might be possible also to say which level to revert to <fantasai> miriam: but that's the question here <fantasai> florian: I think we need at least one <fantasai> florian: if pple use and need more, can extend further <bkardell_> Rossen_: my q was whether we would want to put switch stuff in that same spec for now <argyle> q+ <fantasai> argyle: would be useful <Rossen_> ack argyle <fantasai> argyle: seems likely that I'd want to revert down to a particular layer <fantasai> argyle: think of Island app want to import their 3 layers <fantasai> argyle: might want to revert down to a particular one <argyle> background-color: revert(bootstrap); <fantasai> s/Rossen_: my q/Rossen_, my q/ <leaverou> what about revert just reverts to the result of every other layer being applied *but* the current layer? <fantasai> miriam: I'm open to both <fantasai> leaverou, that's * {all: revert} at the start of your style sheet <fantasai> [missed] <fantasai> florian: behavior is obvious, can spec both and see which ones have been implemented <leaverou> fantasai: I thought that reverted the entire current origin? <fantasai> Rossen_: ?? much easier to implement <dlibby> q+ <fantasai> Rossen_: specific-level revert is easier <fantasai> dlibby: for specific-layer revert, any concerns wrt footgun for authors <fantasai> dlibby: if referring to specific layer not applied yet? <fantasai> s/specific-level/revert-to-previous-layer/ <argyle> `background: revert(bootstrap, 'hotpink');` <fantasai> Rossen_: can refer to these as target-revert vs immediate-revert <fantasai> fantasai: current-level-revert <fantasai> florian: Seems confusing <fantasai> florian: targetted one, doesn't revert a particular layer, reverts all layers down to named one <fantasai> florian: if there's nothing there, it applies styles from previous layers <fantasai> dlibby: Florian might have answered, but if you didn't have layer with particular name / hasn't been applied, seems odd to target something might come later in the cascade <Rossen_> fantasai: my take, let's do the immediate layer revert. It is simpler to implement and spec. Say cascade 5 includes this and build use cases from there. <florian> +1 <Rossen_> fantasai: let's keep it simple and start from there <Rossen_> q? <Rossen_> ack fantasai <astearns> perhaps a note with the possible extension and an ask for use cases for it? <fantasai> sure <fantasai> Rossen_: Current proposal is go with current-level-revert for Cascade 5 <fantasai> fantasai: proposed name is revert-layer <fantasai> fantasai: if no immediate suggestions to rename, let's go with that <fantasai> RESOLVED: Add revert-layer to Cascade 5 <fantasai> <br duration=10min> <jfkthame> present- |
I saw that the Chrome intent to prototype (from @xiaochengh) and platform status mention this as a part of the spec that they do not intend to implement, for complexity/performance reasons:
I don't know if that's something we need to revisit in the spec, but I wanted to make sure that's documented here. |
Cascade Level 4 added the
revert
keyword for rolling back values to their definition in the previous origin.In the draft Cascade 5 specification we provide cascade layers, which are conceptually similar to origins – but controlled by authors. It might be helpful to provide a similar syntax for rolling back to the value defined in previous layers.
The text was updated successfully, but these errors were encountered: