[css-cascade][css-syntax] New !revertable flag to mark a declaration as "can be reverted when IACVT"

[LeaVerou]

This came out of #5319 but I figured I should make a new post for this for visibility, since it’s a distinct proposal.
#5319 discusses a keyword like revert-declaration, however I don’t think a keyword will work, since anything that is part of the value cannot be known in advance (it can be part of a variable for example).

The problem is that UAs throw the other declarations away when they see a new one in the same scope. It's impossible to know whether the new one will ever use that keyword so they can keep the old ones around too. It works with revert and revert-layer because the other declarations are kept around anyway since they’re in a separate origin/layer.

However, I think a new !-flag may actually work. TBB, but some potential names could be !revertable, !revocable, !transient, !layered. Since !-flags need to be present at parse time and are always at the end, it doesn’t have the issues that a keyword would.
When a declaration with this flag is encountered, the UA keeps old declarations around instead of replacing them with this.

/* Will not reset border-radius to 0 if --pill-radius is not set, it will just cascade normally */
border-radius: var(--pill-radius) !revertable; 

There can be more than one:

* {
	/* Will not override animation if --effect is not set to one of these values */
	animation: if(style(--effect: grow), 1s grow) !revertable;
	animation: if(style(--effect: pulse), 4s pulse infinite) !revertable;
}

One open question is how would this work in the CSS OM. But we could just expose the last declaration, and authors can use Typed OM to get all of them (which allows append).

[andruud]

There's overlap here with the ideas in #1594.

The problem is that UAs throw the other declarations away when they see a new one in the same scope.

Ideally, we'd just not do that, and make it always possible to revert to the previous "winner" of the cascade (using a keyword). We'd need to investigate the performance implications of this, though.

[LeaVerou]

That’s the idea for the opt-in: that authors would not be doing this for every single declaration, so the performance implications should be minimal.

[Loirooriol]

#foo {
  height: 1px;
  block-size: 2px;
  height: var(--invalid) !revertable;
}

Assuming an horizontal writing mode, should this revert to 2px or 1px? I guess 2px like revert-layer would do in different layers, but it seems extra annoying for CSSOM.

I wonder if it would make more sense to add an entirely new rule like

@revertable #foo {
  height: 1px;
  block-size: 2px;
  height: var(--invalid);
}

[LeaVerou]

#foo {
  height: 1px;
  block-size: 2px;
  height: var(--invalid) !revertable;
}

Assuming an horizontal writing mode, should this revert to 2px or 1px? I guess 2px like revert-layer would do in different layers, but it seems extra annoying for CSSOM.

This seems orthogonal to the issue we’re discussing? It would revert to whatever this would revert to:

#foo {
	height: 1px;
	block-size: 2px;
	height: invalid;
}

Not sure how UAs handle the aliasing, but that doesn't seem particularly difficult to define. They'd probably keep both around?

I wonder if it would make more sense to add an entirely new rule like

@revertable #foo {
  height: 1px;
  block-size: 2px;
  height: yolo;
}

I would be strongly opposed to doing this as a rule. Rules are far more heavyweight, scoping has to be defined from scratch, and authors cannot port knowledge about it from other parts of CSS. @-rules should be a last resort, not the first thing we reach for because defining syntax with good ergonomics is hard.

[LeaVerou]

Agenda+ since I had some discussions with implementers at the CSS WG meeting last week that indicated this is very implementable.

[Loirooriol]

This seems orthogonal to the issue we’re discussing?

It isn't orthogonal. If we are only reverting to the same property, we could just shift down all declarations for the same property to the last one, then store the values together as a list, say that getPropertyValue provides the last one, and add getPropertyValues to get all of them. Similar for the setter and the priority. But we can at least keep the same indexing as now.

However, if we can revert to other properties, we can't keep assuming that a given property can only appear at most at one index. So it seems the API and the data structures used by browsers will need considerably bigger changes.

I would be strongly opposed to doing this as a rule.

Well, I would be strongly opposed to not exposing the necessary information via CSSOM.

And it doesn't seem great to pollute CSSStyleDeclaration with several things that aren't needed by normal style rules.

[LeaVerou]

Most aliases are known in advance. The only complication with the issue you're pointing out is that the aliasing can be dynamic. These cases are sufficiently few they can just be stored in a data structure (if they aren’t already).

Nothing is polluting CSSStyleDeclaration, please read the first post more carefully?
But as a general principle, the ergonomics of the language itself are more important than CSS OM ergonomics. That doesn't mean the CSS OM doesn't matter, but the weightings of tradeoffs are different.

[Monknow]

I wonder if it would make more sense to add an entirely new rule like

@revertable #foo {
 height: 1px;
 block-size: 2px;
 height: var(--invalid);
}

Even if an at-rule and a !-flag are both present after parse time, I think an at-rule would prompt users to put all their styles inside the block, instead of narrowing down which properties they want to enforce the revertable behavior.

Besides, as specified on the original issue at #5319, the fallback property may be on another CSS rule (or even on third-party styles), like the following:

<p class="lorem">Lorem ipsum dolor</p>

p {
 background-color: red; // declaration gets thrown away
} 

.lorem { 
 background-color: var(--not-a-color);  // declaration is IACVT 
}

If the rule with the IACVT is more specific, the declaration on the lesser specific rule gets thrown away. If I understand your approach correctly, both declarations would need to be in the at-rule, which is harder if they are in different rules.

I think putting a !-flag (or even the initial proposal for a keyword) after the custom property that may be IACVT is cleaner and gives the user the necessary control.

[Loirooriol]

If I understand your approach correctly, both declarations would need to be in the at-rule

@Monknow No. When the second winner of the cascade is in another rule, then it's no different than !revertable. It's not thrown away at parse time, it's just a matter of discussion whether browsers can afford to keep it during the cascade or not.

The problem with normal rules is that duplicate declarations for the same properties get overridden at parse time. So we need a different data structure. Then a different kind of rule may be cleaner.

Nothing is polluting CSSStyleDeclaration, please read the first post more carefully?

@LeaVerou Please read my comment more carefully: "I would be strongly opposed to not exposing the necessary information via CSSOM", which clashes with your proposal in the first post of not exposing it via CSSOM.

[LeaVerou]

Nothing is polluting CSSStyleDeclaration, please read the first post more carefully?

@LeaVerou Please read my comment more carefully: "I would be strongly opposed to not exposing the necessary information via CSSOM", which clashes with your proposal in the first post of not exposing it via CSSOM.

I did. Exposing it via the CSS OM doesn't mean exposing it via every single CSS OM API. If .style does the most commonly needed thing, and .styleMap gives you all the information, that sounds like it would meet your requirements?

---

I would be strongly opposed to doing this as a rule.

That said, there may be value in having an @-rule as well, as sugar for applying !revertable to a bunch of declarations. But as it was pointed out, it should probably not be done from the start, so that authors don’t use it to wrap all their declarations without thinking. The entire reason !revertable might work is because the idea is an !flag is not going to be used everywhere.

[miragecraft]

How would the !revertable work with custom properties, if at all?

I imagine registered custom property would force variable resolution during type checking, so below should work right?

.example {
  --registered: revert to this value;

  --IACVT: max(invalid);
  --registered: var(--IACVT) !revertable;
}

@property --registered {
  syntax: "<number>";
  inherits: false;
  initial-value:0;
}

What about unregistered custom property?

Would the presence of the !revertable force the variable to resolve in order to check for IACVT?

.example {
  --unregistered: revert to this value;

  --IACVT: max(invalid);
  --unregistered: var(--IACVT) !revertable;
}

[kizu]

Good question! For registered custom properties, things should be relatively straightforward and work as for any other custom properties. In your example it will be 0, as no --registered is defined with a valid value, and if we will have something like:

.example {
  --registered: 1;
  --IACVT: max(invalid);
  --registered: var(--IACVT) !revertable;
}

then it will revert to 1.

For unregistered custom properties, the most logical thing to do is to treat them as they're treated now: always valid until used, in the same way it currently “taints” any declaration making fallbacks impossible (and for which we'll have first-valid() — #5055).

I don't know if it is currently possible to determine if an unregistered custom property is invalid before using it? If so, I can see it useful to be able to revert to previous values when doing !revertable. Otherwise it will be useless, and making it work this way should not break anything, as !revertable is itself new, so we can define how it works for this case (again, if this is technically possible/feasible).

[miragecraft]

In your example it will be 0, as no --registered is defined with a valid value

Good catch on my code snippet, I forgot that the reverted value needs to conform to the syntax specified.

I don't know if it is currently possible to determine if an unregistered custom property is invalid before using it? If so, I can see it useful to be able to revert to previous values when doing !revertable.

That's what I'm hoping it can do, I believe currently registered property with "any token" syntax behave the same as unregistered property, correct? So simply doing so doesn't solve the problem.

My simplified use case is follows - I want to create a design system where you can specify width as fractions.

.example {
  width: calc(100% * var(--width));
  --width: 2/3;
  --width: max(invalid) !revertable;
}

As you can see here there isn't any syntax I can use other than any token, since "2/3" doesn't conform to any type.

Of course I can use calc(2/3) instead, but it's no longer elegantly expressed.

If we can force IACVT checking with !revertable then this problem would be solved.

Edit: I thought about using an intermediate variable with calc() and use !revertable on that instead, but while the syntax checking would work the revert would not target the correct variable.

[LeaVerou]

The thing is, --width: max(invalid) is not IACVT — it just makes other declarations IACVT. !revertable can't do anything if the property is not IACVT.

[miragecraft]

The thing is, --width: max(invalid) is not IACVT — it just makes other declarations IACVT. !revertable can't do anything if the property is not IACVT.

I think this use case is more of a limitation of @property than !revertable, having !revertable work for registered custom property (that's not using syntax:"*") is good enough.

[Loirooriol]

Yes, we can't decide whether a --width declaration is valid or not depending on where var(--width) is used, because it could be used in different places which expect different grammars.
You would need to define it with syntax: "<number> | <number> / <number>", which I don't think is valid.