[scroll-animations-1] Do we need container-name references?

[fantasai]

Someone raised the question of whether we need the container-name reference in the scroll() notation in the #6674 proposal, or if the ability to name scroll timelines using the scroll-timeline properties is enough.

Note: @mirisuzanne and I had included both in our proposal because it wasn't clear which one was better, or if we in fact wanted both.

[bramus]

I think that someone was me, in #6674 (comment)

Adding an extra *-name property seemed a bit redundant:

main { /* Identifier 1 */
  container-type: size;
  container-name: page-layout; /* Identifier 2 */
  scroll-timeline-direction: block;
  scroll-timeline-name: main-scroller: /* Identifier 3 */
}

.foo {
  animation-timeline: scroller; /* Identifier 3, again */
}

If more CSS concepts in the future require a *-name property, we could end up with 10 different (or the same) values for all those *-name properties.

Adding *-name properties feels a bit weird as we already have a way to target elements built into CSS: selectors. Being a fan of the selector() function (sorry 😬), I landed on this hypothetical piece of code:

main { /* Identifier 1 */
  container-type: size;
  scroll-timeline-direction: block;
}

@container selector(main) (block-size > 12em) { /* Re-use Identifier 1 */
  /* … */
}

.foo {
  animation-timeline: selector(main); /* Re-use Identifier 1 */
}

In this approach the selector() function would act more document.querySelector(), accepting any selector – see #5884 (comment) for more details.

---

Now, I'm fine with not accepting a container-name inside scroll(), but do want to warn against having many *-name properties in the future as CSS grows and evolves.

[mirisuzanne]

I feel the other way about css-naming vs the selector() function. I like the fact that I can create names in CSS that I want to be able to reference in CSS, without needing those names to exactly match something in the DOM. I don't like digging through HTML to find and apply new selectors in various places, just for the sake of a presentational naming that is really specific to the current styles.

I do get the point about a proliferation of *-name properties, and in some ways those could all be merged into a single CSS naming property. The advantage of having distinct ones is that they can cascade in parallel, instead of overriding each other? That's been a big discussion in relation to Container Queries recently. But it sure would feel neater if we didn't need a whole list of similar properties.

[bramus]

Could be a spin-off feature, to think about a generic -name property that could be used by many properties that target a <custom-ident>.

As far as I'm concerned, this issue may be closed.

[css-meeting-bot]

The CSS Working Group just discussed container name references, and agreed to the following:

• RESOLVED: remove the container name argument from the scroll() function

The full IRC log of that discussion

<TabAtkins> Topic: container name references
<TabAtkins> github: https://github.com//issues/7046
<TabAtkins> bramus: if we ahve a scroll-timeline name, we add some ident to it, and we do the same for containers
<TabAtkins> bramus: so you're adding names here and there
<TabAtkins> bramus: q is when referring to a scroll timeline, could we reuse the container-name so we don't have to add multiple names for various purposes?
<flackr> q+
<TabAtkins> bramus: going forward, do we want a way to specify a type of reference so you can reuse them in various contexts?
<TabAtkins> bramus: example in issue is the main element which adds a name both as container and scroller, setting both properties to the same ident
<astearns> ack flackr
<bkardell_> q+
<TabAtkins> flackr: given the previous discussion about how lookup is not strictly ancestors, it feels like it would be weird to use container-name just for descendants for CQ, but descendants and siblings for scroll-timeline
<astearns> ack bkardell_
<miriam> q+
<TabAtkins> bkardell_: we seem to be ahving a lot of discussions about names and scopes, not just in CSS.
<TabAtkins> bkardell_: wondering if we should give thought to aligning these
<TabAtkins> bkardell_: don't think we want to have a hundred slightly different answers, maybe just one or two good ones
<astearns> ack miriam
<TabAtkins> miriam: i like the idea of container-name being reusable for other container purposes
<TabAtkins> miriam: i don't think we should necessarily consider these name properties being specific
<TabAtkins> miriam: understand Rob's point about the different scope of the name
<TabAtkins> miriam: don't have a solution for that, but i like the feature idea
<bramus> q+
<TabAtkins> flackr: totally okay with the concept, just think we should use them in contexts where the scope is the same
<TabAtkins> flackr: reuse container name in contexts that are ancestor-only, come up with something else for things with counter scope, etc
<TabAtkins> fantasai: this was more about the scroll() function, which makes an anonymous timeline based on the scroll container
<TabAtkins> miriam: wondering if we could attach the scope to the container name - that's a property of queries
<TabAtkins> fantasai: so the scope is more about what's your lookup function, not the "scope of the name"?
<TabAtkins> astearns: so the lookup scope is determined by where you refer to the name. where you declare it has nothing to do with the lookup scope.
<fantasai> TabAtkins: possibly problematic implementationwise, because changes how you store the name
<TabAtkins> astearns: yeah, so for ipml purposes you'd have to know what kinds of scopes could refer to it and maybe take multiple storage strategies
<TabAtkins> TabAtkins: just invent th eone correct data structure, easy
<astearns> q?
<TabAtkins> bramus: [question]
<TabAtkins> fantasai: so say container-name is a kinda generic naming prop
<TabAtkins> fantasai: various things can be like "I want X element", if a container-name has X you can use it for wahtever
<TabAtkins> fantasai: now for scroll timelines, scroll() can refer to an anonymou scroller, it can take a name to filter
<TabAtkins> fantasai: could define to have it look across, etc
<TabAtkins> fantasai: so it's not the naming something declares the scope, the lookup declares the lookup scope
<astearns> ack bramus
<TabAtkins> q+
<TabAtkins> bramus: maybe introduce a generic naming property?
<TabAtkins> astearns: before we get that generic, maybe need use-cases
<TabAtkins> astearns: here we have two instances of container names
<TabAtkins> fantasai: reason scroll() only looks at ancesstors, not siblings, is becuase fundamentally it only looks for scroller ancestors, "nearest scroll container"
<TabAtkins> fantasai: so the container name there is just filtering the search, not expanding it
<TabAtkins> emilio: how is the scroll() function defined to look at ancestors? CQs do something weird wrt shadow dom
<TabAtkins> TabAtkins: Just using the scroll ancestors
<TabAtkins> emilio: so just the flat tree, different from CQs
<TabAtkins> emilio: it would still be weird if something looking for a container-name returned different results in different contexts
<TabAtkins> fantasai: I don't particular care if we have this container name, it was just to ask if we need this. we can jsut drop the name from scroll()
<astearns> ack TabAtkins
<fantasai> TabAtkins: I'm with emilio, the scope of a name is an important part of the existance of a name
<fantasai> TabAtkins: should be part of the declaration, not the lookup
<fantasai> TabAtkins: I don't have a great problem with us having a proliferation of ways to declare names
<fantasai> TabAtkins: there's often special information associated with the name
<fantasai> TabAtkins: or you might ???
<fantasai> TabAtkins: That's why having only one ID or class is annoying
<fantasai> TabAtkins: I think it's useful to have multiple name properties, I think it reduces confusion
<fantasai> miriam: We do allow multiple names in that one property
<fantasai> TabAtkins: But additional context is useful. container-name might not need more info, but other things might
<fantasai> fantasai: like the view timeline stuff
<TabAtkins> astearns: I'm fine with closing this issue
<fantasai> astearns: I'm perfectly fine with closing this issue, but if we find we have a proliferation of name properties and authors are declarting the same name on multiple properties just because they have to, then we can revisit and see if we can come at solution for that specific authoring problem
<TabAtkins> astearns: I think if we find we do have this proliferation of name properties, and authors are declaring the same name in multiple props bc they have to, then we can reopen the issue and come up with a solution for that specific problem
<TabAtkins> fantasai: this issue can't just be closed - we need to answer if scroll() needs a name or not
<TabAtkins> fantasai: so scroll() is a way of saying 'i want to bind this anmation to this timeline'
<flackr> q+
<TabAtkins> fantasai: you can give it a name, but you can just say scroll() to mean "i want the nearest scroll container"
<TabAtkins> fantasai: so this is a way to declare that
<TabAtkins> fantasai: if your parent or grandparent is ascroller, etc
<TabAtkins> fantasai: for many simple animations you don't need a name, so this is good
<TabAtkins> fantasai: the container name lets you filter this list by name
<TabAtkins> fantasai: so question in this issue is do we want this container name filter or not?
<astearns> ack flackr
<TabAtkins> flackr: i don't think there's any reason th ename has to be a filter
<TabAtkins> flackr: could literally use the nearest ancestor with the given name
<TabAtkins> flackr: scroll-timeline doesn't require it to be a scroller
<TabAtkins> flackr: could be useful for a reading progress
<TabAtkins> fantasai: if your element declaring the scroll timeline isnt' a scroller, you're not getting a timleine out of that, so i'm confused
<TabAtkins> dbaron: I think the example is an abspos whose containing block is outside the scroller, but is positioned inside the scroller
<TabAtkins> TabAtkins: are you suggesting that with and without the name use different lookups?
<TabAtkins> flackr: yes, i think that's fine
<TabAtkins> fantasai: i think if you're doing something more complex than "nearest ancestor scroller", then go name your timelines
<TabAtkins> fantasai: purpose fo scroll() was ot just get "the nearest" or "the document" scroller. don't think it should expand to looking elsewhere.
<TabAtkins> flackr: i'm suggesting that a name makes it use the strict parent chain, not the CB chain
<TabAtkins> fantasai: oh that's okay
<fantasai> “By default, scroll() references the block axis of the nearest ancestor scroll container.”
<TabAtkins> emilio: CQs don't use the flat tree strictly
<dbaron> s/positioned inside the scroller/a descendant of the scroller/
<fantasai> Technically it's already defined the way flackr wants
<TabAtkins> emilio: I'd be more comfortable if we did container lookups consistently using whatever method
<TabAtkins> flackr: i'd be in support of that, using the same method
<TabAtkins> TabAtkins: i'd be okay with revisiting the CQ lookup method, if we're concerned with consistency. want to think about it.
<TabAtkins> fantasai: so q is if we even want the scroller name, since we can provide a timeline name
<fantasai> TabAtkins: if you can provide a timeline name anyway, what additional value do we get from the container name here?
<fantasai> TabAtkins: have scroll() or timeline name, and they both do what you expect
<fantasai> flackr: It would be minor convenience, but I don't think it's necessary
<ydaniv> +1 to defer
<TabAtkins> astearns: so proposed resolution is we don't add this functionality to the draft
<TabAtkins> fantasai: which would be a spec change, yeah
<TabAtkins> RESOLVED: remove the container name argument from the scroll() function