Xiaocheng: This is about expsoing the current scroll state - whether you're scrolling up/down or scroll is currently snapped, so CSS can be done based on these factors. I think the use case is strong as it's a frequently-used design pattern. E.g. we want to show the header bar when scrolling in one direction, and hide it when scrolling in another. If you can do it in a declarative manner that'd be good. I didn't identify anything beyond the typical scope of concerns of CSS. The explainer already contains a lot of considerations such as whether we're exposing it via a container query or pseudo class.

Matthew: I haven't ben able to look at it in detail yet. Ome thing I would've been concerned about is if this is affecting anything other than presentation and it sounds like it's not. So I'd be ok with that.

Xiaocheng: Also, I'd like to confirm if there is any security/privacy considerations specific to this new feature. those sections in the spec are for the entire spec.

Another one, I'd like to discuss here. It's on eof those trendy, new CSS features that adds style dependency on layout. Some features are carefullly designed to avoid cyclic dependency, but others are more hand waving. Basic idea: i take a snappshot of the current layout and use that as input ot hte next styling. and there is a maximum number of retries if the layout doesn't stabilise. Something we should be aware of.

Hadley: Seems like a good idea to raise the point. Are you saying that in this case there's a possibility of it but it won't actually happen.

Xiaocheng: Currently the responsibility to avoid the cycling dependences is left to the developer.

Hadley: Sounds like this gives us or them two choices: (1) redesign it so it's impossible to have cyclic dependencies; and (2) provide information for developers to help them avoid cyclic dependencies, e.g. mdoc warnings, comments. Not sure what would be useful for implementers. I think it's worth asking them the question about how to avoid developers making mistakes with this. We should ask them this and about the S&P section.

Lola: Matthew mentioed that his is presentation-only... are we sure? Is there a scenario where a screen reader user won't be able to access or interact with something they need to.

Matthew: That's a good question. I haven't looked at it in huge detail. I was reassured by Xiaocheng's comment. I know he's thorough and good at explaining things. Your question is really good, but I think this is providing a way for developers to do somethign they can already do. So the prolem you're describing is something that would exist right now. Maybe they shoudl put in a note to remind authors that "If you do this pattern, you have to be aware of certain things?" We could start that off and get APA to comment. It wouldn't change anything, but woudl let us raise awareness.

Lola: even if developers are doing the thing now, in a different way, that doesn't mean that some users aren't being excluded. and we woudln't want this to be a better way to exclude users. So I just wanted to raise that in case. If it's a non-issue...? I would be comforted if APA could have a look.

Matthew: I agree. We don't want to make it too easy to do a bad thing. I'm now wondering too about the cases where this might be a bad thing. Let's bring it to APA and look at where to put notes or warnings in for authors. I suspect it's not necessary, but it's a good opportunity to check.

Hadley: actions arising: Xiaocheng to draft a comment; Matthew to ask APA to look into authoring considerations.