- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 16:25:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations-1] blocking effects of timeline-scope`, and agreed to the following: * `RESOLVED: A timeline-scope also prevents the timeline from being scoped even higher.` * `RESOLVED: contain:style prevents timeline names from leaking out past it` * `RESOLVED: Don't add any additional keywords to timeline-scope for this use-case (for now)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: I just wanted to confirm with the WG the behavior<br> <TabAtkins> fantasai: The timelie-scope property is defined to pull the scope of a timeline name up to an ancestor, which makes it available to a larger subtree<br> <TabAtkins> fantasai: as we were drafting, robert clarified that it also blocks the timeline from being pulled further up into a higher ancestor<br> <TabAtkins> fantasai: so i'm just confirming that it desired behavior<br> <TabAtkins> fantasai: and second to ask if we want to add keywords to make this blockign behavior work for all timeline names on an element<br> <TabAtkins> flackr: the motivation is that if you define a timeline scope for an element, you're isolating the effects of the timeline named there from affecting anything outside that element<br> <TabAtkins> flackr: so it's similar to containment in a way<br> <TabAtkins> fantasai: so any thoughts or comments about this blockign behavior?<br> <TabAtkins> fantasai: if it seems good we can resolve on that<br> <TabAtkins> (don't really have an opinion, seems fine)<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: A timeline-scope also prevents the timeline from being scoped even higher.<br> <TabAtkins> fantasai: do we want to add keywords that add this scope-blocking on all possible names in a subtree, or all names declared by the element with timeline-scope?<br> <TabAtkins> fantasai: So if you're doing a bunch on a subtree, you want none of the timleine names to escape the subtree, you don't want to list them all out<br> <TabAtkins> fantasai: or if you're declaring several that you want to be scoped but you don't wnat to block your children from lifting their scopes, maybe a local thing<br> <TabAtkins> astearns: apologies, not actually clear what this would do, i assume rob and others have an opinion?<br> <TabAtkins> fantasai: will explain again. if you declare scroll-timeline on a scroller it's available to its descendants only<br> <TabAtkins> fantasai: If you want that timeline avaialble higher, you ahve to use timeline-scope on an ancestor referring to it, then it's visible to the scoping element's descendants.<br> <TabAtkins> fantasai: The blocking effect we jsut talked about means it can't go even higher<br> <TabAtkins> fantasai: [explains in more detail]<br> <TabAtkins> fantasai: if you want to encapsulate all the possible scrollers inside you, you might not know all the names on your contents<br> <flackr> q+<br> <TabAtkins> fantasai: if you're in a component or whatever<br> <astearns> ack fremy<br> <TabAtkins> fantasai: some higher element in your chain might say "timeline-scope: foo" and not be looking for your "foo" timeline, but another one it knows about. but it finds yours instead.<br> <TabAtkins> fantasai: To prevent this you ahve to preemptively timeline-scope all of your names.<br> <astearns> ack flackr<br> <TabAtkins> fantasai: so do we want to make this easier<br> <TabAtkins> flackr: it feels a bit odd to re-use timeline-scope for this since you're not raising the scope<br> <TabAtkins> flackr: coudl we say contain:style prevents the leakage or would that be too restrictive?<br> <TabAtkins> fantasai: think that's a good idea anyway<br> <TabAtkins> flackr: if we need that, do we need a timeline-scope:all?<br> <TabAtkins> fantasai: we might bea ble to get away without it, yeah<br> <TabAtkins> I agree that contain:style should prevent names leaking out<br> <TabAtkins> that's the point<br> <TabAtkins> flackr: so that's my proposal, use contain:style<br> <TabAtkins> fantasai: sounds good<br> <TabAtkins> astearns: yeah makes sense<br> <ydaniv> +1<br> <TabAtkins> astearns: any other opinions?<br> <TabAtkins> astearns: objections?<br> <emilio> q+<br> <TabAtkins> emilio: are there use-cases for scoping timeline names but not counters?<br> <TabAtkins> astearns: whether or not there is, shoudl contain:style scope both anyway?<br> <TabAtkins> emilio: it should yeah<br> <TabAtkins> astearns: so i think we can resolve on contain:style and then your question is about maybe still adding a separate control<br> <emilio> ack emilio<br> <TabAtkins> astearns: so any objections to contain:style?<br> <TabAtkins> RESOLVED: contain:style prevents timeline names from leaking out past it<br> <TabAtkins> astearns: so emilio's question is an argument for adding a keyword to do just the one thing<br> <TabAtkins> astearns: i can't immediatly think of a case where you'd want to do them separately<br> <TabAtkins> fantasai: If we did add the keywords, i just thought of 'contain-all' and 'contain-self'<br> <flackr> q+<br> <TabAtkins> astearns: i suggest we leave the keywords out until we have evidence that just using contain:style is insufficient<br> <astearns> ack flackr<br> <TabAtkins> flackr: if we did have an "all" on timeline scope, I'd also expect them to raise the scopes they captured<br> <TabAtkins> fantasai: yeah that's why i thought of the "contain-*" names to separate them a little more from that concept<br> <TabAtkins> flackr: ah right. but for now I think we're comfortable with not doing this<br> <TabAtkins> fantasai: so proposed resolution is to not add keywords for ow<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Don't add any additional keywords to timeline-scope for this use-case (for now)<br> <fantasai> Side comment: 'contain: style' should probably also affect anchor-name<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8915#issuecomment-1645939339 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 16:25:59 UTC