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

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

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);
}

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: var(--invalid) !revertable;
}

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 better ergonomics is harder.

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