Lea: seems great, does address real author needs. What percentage of use cases would be esatisfied by container queries. Eg. stack elements with position sticky, want to style stack element not descendents. At least it introduces a workaround whereas right now you have to use js. Didn't get the part about a two pass rendering update that this introduces. Does anyone understand it better?

Peter: cycles in rule matching you avoid with container queries but if you detect something being stuck and you change sizes of things it could no longer be stuck, right?

Lea: can it? Something that is stuck is also positioned

Peter: but it can scroll or be stuck to the edge based on the scroll position

Lea: in my opinion cycles are something that prevents implementers from implementing css that might involve cycles, it's not usually usability concern. A lot of very useful features are not being done because they could introduce cycles. If this has implementer support I'm not that concern. Remember when I proposed a design principle that css features could not have cycles? Peter said rather not because lots of useful things can introduce cycles. If implementers are happy I'm happy.

Peter: agree with that. I don't think the fact it can cause cycles is a reason to not do it. CSS just needs better detection and resolution of cycles. If they're willing to do the work of dealing with it then great.

Rossen: agree. Is this different than the scroll driven animations have? If it exacerbates it or it's more or less the same.. at the high level as a proposal I'm happy with it.

Lea: Are implementers happy with this? Everybody seems to be... there are no signals from mozilla or safari on the chrome status issue. I don't know if standards positions have been filed

Rossen: it's also an early review

Lea: [writes comment]