[css-anchor-position-1] Define interaction with the cascade in `@position-try`

[cdoublev]

The spec does not seem to define the interaction of property declarations with the cascade in @try, as required by CSS Syntax:

If any declarations are valid, and are property declarations, it must define whether they interact with the cascade; if they do, it must define their specificity and how they use !important.

Sorry, I am not very familar with the CSS Anchor Position spec yet, but I guess they interact like declarations in keyframe rules (!important is invalid), right?

[fantasai]

Fwiw, I think they should go in the Animation Origin, prior to actual animations. (This is what I suggested for the analogous @position-area proposal option presented at the F2F.) I think the spec currently implies that they win over everything, which imho is not great.

[xiaochengh]

I think the spec currently implies that they win over everything

This is also my understanding of the spec, and what the Chromium implementation is doing.

...which imho is not great.

Agreed it's not great, but it would be very hard to change.

The main difficulty is that we need to run layout to decide which fallback position to apply, at which time the cascade is already finished. That's why everything is done at used value time.

It would be really great if we can resolve fallback postion at computed value time, which not only prevents overwriting e.g. !important UA style, but also supports smooth transitions between fallback positions.

[fantasai]

Copying over comment from #9331:

Reading through the issues, apparently rules in the @try blocks apply “at used value time”, which means they don't fit into the cascade at all—even !important rules won't apply.

This is problematic to begin with, and it becomes more problematic the more properties you allow in @try.

Relates also to #9332

[xiaochengh]

Also copying from #9331:

But preventing them from overriding !important style should be implementable, and I agree that should be probably be done now for sanity.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Define interaction with the cascade in `@try` , and agreed to the following:

• RESOLVED: !important must win and the issue of putting @try properties in their place in the cascade will be investigated

The full IRC log of that discussion

<emeyer> TabAtkins: When you are doing fallback positions, you’re overwriting various properties
<emeyer> …The question is, what does it mean to do that?
<emeyer> …Right now, it means you’re overwriting values, which means it’s higher than specificity, because when you’re doing layout, the cascade has already been resolved
<xiaochengh> q+
<emeyer> …You might not always want to do that, but implementation seems hard
<emeyer> xiaochengh: Right now, fallback is completely post-cascade
<emeyer> …If we want to make it part of cascade, it’s very to specify in that way
<emeyer> …It’s sort of like the container query situation, where part of the stlye depends on layout
<emeyer> …For at least level 1, we want to avcoid this problem and make it a post-cascade effect
<emilio> Just realized I filed this as https://github.com//issues/9229
<iank_> q+
<astearns> ack xiaochengh
<emeyer> …There’s a related issue that fallbacks override all the !important style, which is counterintuitive to authors
<emeyer> …If we want to stop that, it’s actually implementable
<emeyer> …I propose we keep it so it doesn’t participate in the cascade but does not override !important
<emeyer> TabAtkins: Does this mean we keep around a notion of whether a styles was important or not past the end of the cascade resolution?
<emeyer> xiaochengh: Currently we don’t allow too many properties in fallbacks
<emeyer> …So we can add a flag whether a value is important or not
<astearns> ack iank_
<emeyer> TabAtkins: So it would still be an addition, but a much easier one, got it
<emeyer> iank_: It’s somewhat different to the container query case
<emeyer> …Here we’re messing around with the style of the thing we’re targeting
<dbaron> （I have vague memories of this approach being taken for compositor animations in some engine, though I don't remember which engine!)
<dbaron> (and compositor animations have the similar characteristic that they're for a limited set of properties)
<emeyer> …If the !important case can be done, but for simplicity’s sake people don’t think it’s important, mild preference to keep things simple
<astearns> ack fantasai
<jensimmons> q+
<emeyer> fantasai: My take is that it’s not okay to have stuff that some lower level of the cascade can insert but can’t be written by !important
<emeyer> …We fixed it for animations and should not create the problem here
<astearns> +1 to not overriding !important. It would be an attractive nuisance for CSS crimes
<TabAtkins> +1 to what fantasai's saying wrt bad to make something not overrideable
<emeyer> …The more styles we allow into @Try blocks, the bigger this problem will become
<emeyer> …You end up with a problem where somebody who’s set up these styles end up with it slotted into the wrong part of the cascade
<TabAtkins> and we use UA !important for some invariants, bad to defeat that
<emeyer> …At a minimum, we need to fix this for !important
<emeyer> …But we also need to have things interact with the cascade at the level they entered it
<astearns> ack jensimmons
<emeyer> (scribe missed)
<TabAtkins> TabAtkins: The fallback doesn't really have an associated style rule, does it?
<emeyer> jensimmons: I feel like it would be confusing for authors to have a certain hole in the ground where if they step in it, everything they do there overrides everything else
<TabAtkins> fantasai: The rule that applies the 'position-fallback' prop.
<astearns> +1 to jensimmons
<emeyer> …Why would we do that? The cascade is so core to CSS
<fantasai> [note to Dael, that comment from me is in response to Tab above, goes higher]
<emeyer> …I get that there’s a problem with implementing, which is a sign that we need to keep going and figure this out
<fantasai> +1 to jensimmons
<emeyer> fantasai: I don’t know if my proposal is the best idea
<kizu> q+
<emeyer> …I agree with Jen that we should figure this out
<jensimmons> Yes, I didn't say, but I believe that just having !important have effect, but not everything else is a problem.
<emeyer> xiaochengh: We still have another problem of having to run layout to decide which fallback to use
<emeyer> …Without seeing a solution for that, I don’t see how we b ring fallbacks to the cascade
<emeyer> TabAtkins: I believe it would work as what you described for !important, just more complicated
<emeyer> …When a fallback is chosen, we’d record the necessary cascade information and do the same for all overwritable properties, and then compare them
<emilio> q+
<emeyer> …This is a more complicated version of what you describe for !important
<emeyer> …Instead of a boolean for !important, we’d store more complicated information
<astearns> ack dbaron
<Zakim> dbaron, you wanted to react to jensimmons
<emeyer> dbaron: An alternate of describing what Tab just said is that you can think of it as turning every property that can be overridden by the try blocks into a shorthand
<TabAtkins> oooh yeah that works
<TabAtkins> weird but it woudl be internal
<emeyer> …that sets a bunch of booleans you than check to see if overriding is okay
<astearns> ack kizu
<emeyer> …This turned out to be awful when we did it for directionality, and it’s a lot of overhead, but it’s a way of thinking about it
<emeyer> kizu: +1 to Jen; from an author perspective, it can be hard to tell where styles come from
<emeyer> …This would be another case where the author doesn’t know where the styles come from
<emeyer> …If it’s hard for implementation to lay out things in a way that’s not outside the scope of the current rule, we should at least be able to override with !important
<TabAtkins> (when we're done with the q, i have a proposed resolution)
<emeyer> …Ideally, this is a case where we’d want to consider other cases like area positioning
<emeyer> …In my experiments with trying to use variables in @Try rules, we have to repeat a lot of things
<astearns> custom property use in @Try is a *good* consideration
<emeyer> …Maybe the proposals of Miriam with functions could help
<emeyer> …I don’t know if the fallbacks with the current anchor positioning is something okay
<emeyer> …As an author, I’d be kind of okay with fallback later rather than right now
<emeyer> …Fallbacks are not that well formed and it would b e nice to consider area fallbacks as well
<emeyer> emilio: Excluding insets from fallbacks seems okay
<emeyer> …Changing position is not all that bad, because you can read the used value
<iank_> q+
<emeyer> …If you’re going to change order etc., it becomes really confusing
<astearns> ack emilio
<astearns> ack iank_
<emilio> emilio: revert might make it harder
<emeyer> iank_: Reply to emilio: we may file an issue to revisit border-padding speficially
<emeyer> s/speficially/specifically/
<fantasai> border padding issue -> https://github.com//issues/9195
<emilio> emilio: haven't fully grasped dbaron's proposal but I think you might need to keep track of declarations that would otherwise be ignored
<emeyer> TabAtkins: I propose we resolve that !important properties will win over @Try blocks and investigate the feasibility of doing proper cascade checking
<emilio> q+
<emeyer> astearns: Concerns?
<emilio> q- later
<emeyer> astearns: Proposed resolution is that !important must win and the issue of putting @Try properties in their place in the cascade will be investigated
<emeyer> RESOLVED: !important must win and the issue of putting @Try properties in their place in the cascade will be investigated
<emeyer> emilio: I assume the use cases for non-positioning properties in @Try are mostly around being able to, if you have an arrow and it’s flipped, the arrow will point the other way
<dbaron> fyi, emilio, I was proposing to handle it similar to the way we handled logical properties when things were only ltr vs. rtl, which didn't extend properly to adding vertical text because it created too many possibilities. Essentially 'top' would become a shorthand for 'top' and 'top-source', and 'position-fallback' (??) would also set 'top-source' but to the other possible value, and then the ...
<emeyer> …I’m not proposing anything like that, but for the record, in Gecko, we do expose position events
<dbaron> emilio, ... computed value of 'top-source' would determine whether the try block could apply 'top'
<emeyer> …Whenever a fallback happens, we would schedule an event so the fallback could be tweaked by CSS
<emeyer> …That’s used for things like making sure arrows point the right direction
<emeyer> iank_: I think we need a container query like thing that lets you style the insides based on the position that was selected
<emeyer> …You might have to add a wrapper and get the desired decorative elements
<emeyer> …We could investigate also adding an event as well
<emeyer> TabAtkins: I think there’s a lot of discussion to be had here about the exact mechanics
<emeyer> …I think we can get something productive out in the future
<emilio> dbaron, ah, interesting... I think my concern is orthogonal. Does `@try {}` allow `revert` / `revert-layer` or so? If so you might need to end up recording arbitrarily many specified values

[xiaochengh]

In the last meeting we mentioned another sub-issue, which is the behavior of revert in @try.

This won't be an issue if @try rules can properly cascade, but right now they don't. I suppose the only choice for now is to disallow revert until we figure out how to make @try rules cascade.