- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Nov 2023 17:35:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Define a syntax for state-based container queries`, and agreed to the following: * `RESOLVED: create ED of css-contain-4 with all editors of css-contain-3 as a diff spec` * `RESOLVED: add scroll-state() to css-contain-4` * `RESOLVED: move explainer into the csswg-drafts repo` <details><summary>The full IRC log of that discussion</summary> <bramus> futhark: State Contqiner Queries allow you to do container queries based on scroll position. TAG was positive about it. previously this was resolved to delay to L2 of the spec (contain 4) and I started on the prototype with sticky pos and am now asking if we can start working out a spec for a new function state in the @container rule and introduce 3 new SQ types (sticky, snap, and overflow)<br> <TabAtkins> +1 obvs, this would be great<br> <bramus> … second thing is that i am not sure to resolve on, but what i investigated is that it requires a modifcaition to the the HTML event loop similar to scroll driven animations.<br> <bramus> … eg for sticky it needs a snapshot<br> <bramus> astearns: q on the second bit: exactly the same changes?<br> <bramus> futhark: yes, exactly the same thing – at the same time<br> <miriam> q+<br> <bramus> astearns: any questions?<br> <astearns> ack miriam<br> <emilio> q+<br> <bramus> miriam: what do the container type values do on the container? do they apply containment or just mark it as available?<br> <bramus> futhark: just available, but might want to impose some containment restrictions. you can have same issue with hover here (flipping between states)<br> <bramus> … needs to investigaged. Do we impose the restrictions or do authors need to do it themselves?<br> <bramus> astearns: Is it OK if we start out with no extra containmenbt effects and then figure it out?<br> <bramus> miriam: I think we want to resolve that before shipping, but now not opposed<br> <astearns> ack emilio<br> <bramus> emilio: state is also used for custom state psuedo, so might be confusing<br> <bramus> futhark: yeah, syntax is up for bikeshedding<br> <fantasai> maybe call it scroll() or scroll-state() or something?<br> <bramus> emilio: other thing: you mention HTML event loop level snapshotting such as SDA. For animaitions you can get away with that, but I wonder for the rest, as you can query it outside of anmiations. I wonder if you need to ??? a bit more.<br> <bramus> futhark: not sure what you mean by that … it is not possible to call getboudningclientrect in between these two ???<br> <bramus> emilio: yeah, but I expect these queries to work outside of the rendering loop<br> <bramus> … what happens if I run random JS task, does it need to eavluatie these query when not having performed the snapshotting yet?<br> <flackr> qq+<br> <bramus> futhark: I would assume that you need to do that snapshot as well when doing that. seeing similartyt with size container queries affecting gCS.<br> <bramus> emilio: fine if this is TBD<br> <bramus> futhark: needs to be investigated<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to emilio<br> <bramus> flackr: FWIW you can do same thing with scroll animations. gBCR is affected by ?? and you can call outside of lifecycle update<br> <astearns> s/??/animations/<br> <bramus> … when you call it before the first rendering update, the timeline is inactive bc it is not snapshotted yet<br> <bramus> … when applied to state queries, they could be not active until first rendering update<br> <bramus> futhark: makes sense to me but … q is: is this important use case or does it need to be defined/specced?<br> <emilio> q+<br> <bramus> flackr: its not great for the author bc they get incorrect values when called before 1st rendering update<br> <astearns> ack emilio<br> <bramus> emilio: my q was more in line to make sure this is defined<br> <bramus> … authors are much more used to animations not returning super precise states but i think this would be kind of a first<br> <bramus> … that may be fine. no strong opinion.<br> <bramus> flackr: hover is a bit similar I think, but expectation is that hover doesnt get updated until you move th emouse<br> <bramus> emilio: but it is different … this is not like a pseudo class that does/doesnt apply … not sure, maybe hover analogy is OK?<br> <bramus> astearns: I think we can resolve on adding the values and function and then try to define the interaction (or open a new issue for that)<br> <bramus> futhark: yes, but css-contain-4 doesnt exist yet<br> <bramus> astearns: yes, that would be created<br> <bramus> fantasai: we should add resolution for that<br> <bramus> astearns: PROPOSED RESOLUTION: create ED of css-contain-4 with all editors of css-contain-3 as a diff spec<br> <bramus> RESOLVED: create ED of css-contain-4 with all editors of css-contain-3 as a diff spec<br> <bramus> astearns: PROPOSED RESOLUTION: add sticky, snap, and overflow as new container type values<br> <bramus> RESVOLED: add sticky, snap, and overflow as new container type values<br> <bramus> astearns: state as conflict … scroll or scroll-state were suggested … can add scroll-state to start with?<br> <bramus> futhark: yeah, no strong opinion about the name<br> <bramus> astearns: PROPOSED RESOLUTION:add scroll-state() to css-contain-4<br> <bramus> … objections?<br> <bramus> RESOLVED: add scroll-state() to css-contain-4<br> <bramus> astearns: other things about this?<br> <bramus> futhark: No<br> <emilio> q+<br> <bramus> astearns: thanks for the epxlainer and tag review<br> <dbaron> should the explainer move into the csswg-drafts repo?<br> <astearns> ack emilio<br> <bramus> emilio: last minute q: do we need 3 different container types here?<br> <bramus> futhark: I think it makes sense given the current prototytping. only thing is i fyou want to select different ones you need to use names<br> <bramus> emilio: so we need 1 or 3?<br> <bramus> futhark: 1 makes sense<br> <miriam> +1 to a single container type, if it works technically<br> <bramus> astearns: no resolution on that just yet, lets wait on prototype<br> <bramus> astearns: PROPOSED RESOLUTION: move explainer into the csswg-drafts repo<br> <bramus> RESOLVED: move explainer into the csswg-drafts repo<br> <dbaron> (in contain-4)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6402#issuecomment-1812973013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 November 2023 17:35:29 UTC