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

[andruud]

Fwiw, I think they should go in the Animation Origin, prior to actual animations.

That position in the cascade makes sense to me, but maybe can add a new "Position Fallback Origin" there instead of claiming they're animations. (Like animations, it could be considered part of the author origin for the purposes of revert).

[andruud]

The spec says this at the moment:

These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values. They are applied as part of the author origin, as part of a theoretical UA-controlled final cascade layer.

This works, I think, but it would be good to clarify whether it's intended to be weaker or stronger than element attached styles. As written currently, it could be interpreted to mean weaker, since it's described as a layer.

[tabatkins]

Hmmmmm yeah, I wrote it as a layer because that's how you referred to it when we were discussing it. ^_^ But yes, element-attached styles should be weaker. (You should be able to style an element from style="", including a position-try-options that uses flip-* keywords, and have it work.)

So I think specifying it as a cascade origin (between author and animation) is indeed the right thing.

[tabatkins]

K, specified as a new origin now. We should move the definition fo the origin to Cascade so we're not monkey-patching the origin list, tho.

We also need to define the behavior of revert, as @xiaochengh pointed out in #9149 (comment). I'm inclined to either (a) say that revert isn't allowed, or (b) have it revert to the user origin, similar to how it works in animations.

[andruud]

OK. That also works.

revert isn't allowed

Now that we have functioning cascade interaction due to interleaving, there's no technical reason to ban reverts. I'd just go for (b).

[css-meeting-bot]

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

• RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)

The full IRC log of that discussion

<chrishtr> TabAtkins: we resolved earlier that rules from position fallbacks interact with the cascade in some way
<chrishtr> TabAtkins: now we want to define that
<chrishtr> TabAtkins: propose that rules applied by a posoition-try have a new origin after author origin and before animation origin
<chrishtr> TabAtkins: this lets such rules win over all author rules but lose to animation, important etc
<chrishtr> TabAtkins: revert keyword would also revert to user origin, just like animations
<emilio> q+
<Rossen_> ack emilio
<chrishtr> emilio: can can rules in this origin change position?
<chrishtr> TabAtkins: yes
<chrishtr> emilio: s/position/transition/
<chrishtr> TabAtkins: only once all of the cascade has finished is there a transition to start
<chrishtr> emilio: details of that seem fiddly. Seems the right behavior but needs edge case testing and spec text to make sure it's clear
<chrishtr> TabAtkins: current spec says to go through them in sequence and only declare the element's real style once all have done
<chrishtr> emilio: these things used to not be done until after layout?
<chrishtr> TabAtkins: these are inputs to layout and so are used styles
<chrishtr> emilio: but how does that cause transitions?
<chrishtr> TabAtkins: uses the same mechanism we discussed before
<TabAtkins> > These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even tho they depend on layout and used values.
<chrishtr> emilio: that causes interleaving then?
<chrishtr> emilio: performance may be an issue, but if that's what we want ok
<chrishtr> futhark: it's quite similar to container queries - might need to repeat style multiple times due to interleaved style and layout across containers
<dbaron> futhark: ... before starting transitions
<chrishtr> chrishtr: emilio was asking about performance concerns also?
<chrishtr> emilio: my question was about remembering rules from before and how are we supposed to do that?
<chrishtr> futhark: in Chromium that is part of the cascade implementation generally
<chrishtr> futhark: we need to handle that regardless for regular animations
<chrishtr> futhark: I forget the exact way that important overriddes animations?
<chrishtr> emilio: animations override important. but if we're just reusing the regular cascade then it's fine
<chrishtr> futhark: what we do is to insert these trys into the cascade as appropriate and re-run it
<chrishtr> emilio: still a bit concerned about performance, but it's fine
<chrishtr> futhark: some optimizations can be applied since the try blocks are more scoped
<chrishtr> emilio: haven't read the exact spec text but seems fine to me
<chrishtr> fantasai: wanted to say that this is the most reasonable place in the cascade to put these rules, other than possibly somehow inlining them somewhere, not sure
<astearns> let’s try to get as much of these fiddly details into a spec as we can
<chrishtr> fantasai: but that possible alternative sounds complicated
<chrishtr> fantasai: we should minimize what goes into these try blocks and put other features elsewhere
<chrishtr> fantasai: this way we can maximize the % of styles that end up in their regular place in the cascade
<chrishtr> fantasai: for inset and margin it's reasonable to put them in position-try, but for more stylistic items they should go in the cascade proper outside of a position-try rule whenever possible
<fantasai> s/somewhere/where the position-try declaration that sources them lives/
<fantasai> s/other features/other declarations/
<TabAtkins> proposed reoslution: fallback styles live in a new "Position Fallback Origin"
<TabAtkins> proposed resoultion: They revert like Animation styles (back to User origin)
<chrishtr> RESOLVED: fallback styles live in a new "Position Fallback Origin". They revert like Animation styles (back to User origin)