- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 13:56:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `scope of named timelines`, and agreed to the following: * `RESOLVED: scope of named timelines is across flattened tree` * `RESOLVED: timeline search looks at preceding siblings and ancestors, recursively` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: scope of named timelines<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7047<br> <TabAtkins> fantasai: when you name a timeline with the css properties, what's the name scope; which elements have access?<br> <TabAtkins> fantasai: easiest is to work the same as counter<br> <TabAtkins> fantasai: so which scope should we have for these things - descendants and siblings (like counters) or expand further? and if further, what precedence rules?<br> <TabAtkins> TabAtkins: further question - does this extend into shadows<br> <TabAtkins> fantasai: good question, probably no<br> <TabAtkins> TabAtkins: suspect i agree<br> <TabAtkins> flackr: sounds easy to resolve<br> <fantasai> TabAtkins: Use either the pre-flattened or post-flattened tree<br> <fantasai> emilio: The flattened tree doesn't know about shadows<br> <fantasai> emilio: counters use the flattened tree<br> <fantasai> TabAtkins: It is true that other than selectors, CSS is defined over the flattened tree<br> <fantasai> TabAtkins: what's easier?<br> <fantasai> astearns: Is there a reason for them to descend or not?<br> <fantasai> TabAtkins: would let you to refer to timelines defined outside the shadow<br> <fantasai> miriam: Seems like it could be useful<br> <fantasai> i/TabAtkins: further/scribe+ fantasai<br> <fantasai> TabAtkins: do counters use the flat tree?<br> <fantasai> emilio: in Gecko they use flattened tree for sure<br> <fantasai> dbaron: I thought both HTML list numbering and counters don't use the flattened tree<br> <fantasai> dbaron: pretty sure about HTML list numbering<br> <fantasai> emilio: when Mats worked on list counters, the CSSWG resolved to use the flattened tree<br> <fantasai> emilio: and we fixed it very recently<br> <fantasai> dbaron: So 2 weeks ago I was helping a new engineer working on Blink, and advised it was to not use flattened tree<br> <fantasai> TabAtkins: outside of the display spec and possibly scoping, which define how flattened tree works<br> <fantasai> TabAtkins: the rest of CSS doesn't mention a tree specifically, just uses parent-child relationships<br> <emilio> https://github.com/w3c/csswg-drafts/issues/2679 is the relevant issue IIRC<br> <fantasai> TabAtkins: so don't see how you'd be reading that<br> <fantasai> dbaron: HTML defines it twice, once not using the flattened tree<br> <fantasai> dbaron: and a second time in the rendering section in terms of CSS counters<br> <fantasai> TabAtkins: HTML might do something weird, the way their list counters work is bizarre and based on back-compat<br> <emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1477524 is where we fixed it<br> <fantasai> astearns: Sounds like figuring out how other parts of CSS work as precedent is not a great idea<br> <fantasai> TabAtkins: well maybe not HTML list counters<br> <fantasai> astearns: Only opinion I've heard so far is that so far it would be better to pierce the shadow DOM<br> <fantasai> astearns: we can spec it either way<br> <fantasai> miriam: My sense would be that authors will want their web components to respond to these timelines, so having it available in the shadow DOM seems useful<br> <fantasai> astearns: Anyone wants to argue against having timelines pierce shadow boundaries?<br> <fantasai> flackr: Is it normal to coordinate thing outside shadow DOM and stuff inside it?<br> <fantasai> TabAtkins: depends on your usage<br> <fantasai> TabAtkins: if you're ... or ???; entirely opposite use cases<br> <fantasai> miriam: Shadow can usually see things outside, it's just usually the other way around that we don't do<br> <fantasai> dbaron: It does seem a little awkward to conclude without anyone from WebKit<br> <fantasai> dbaron: they tend to have a unified opinion on shadow DOM<br> <fantasai> astearns: They're not here, so we can conclude without them and they can object if they want<br> <fantasai> astearns: we should try to make progress, can always circle back<br> <fantasai> astearns: proposed resolution is that the scope of named timelines uses the flattened tree<br> <fantasai> TabAtkins: I do think that's the right way to do it now<br> <fantasai> astearns: objections?<br> <fantasai> RESOLVED: scope of named timelines is across flattened tree<br> <bramus> q+<br> <flackr> q+<br> <TabAtkins> fantasai: back to original issue, don't have much of an opinion<br> <TabAtkins> fantasai: current spec says scope is the element itself and its descendants<br> <TabAtkins> fantasai: and its siblings and their descendants<br> <TabAtkins> TabAtkins: identical to counters<br> <TabAtkins> fantasai: so question is if we want this to expand to document-global?<br> <astearns> ack bramus<br> <TabAtkins> bramus: i think there are some use-cases for it<br> <TabAtkins> bramus: like if an element is scrolling and elements elsewhere in the tree are animating along it<br> <TabAtkins> bramus: so like in your body a fixpos element, wanting to look at the scrolling element to reveal itself at one point<br> <astearns> ack flackr<br> <TabAtkins> flackr: there are definitely use-cases for global<br> <TabAtkins> flackr: only concern is these are often used in components, like progress thru a carousel<br> <TabAtkins> flackr: so want to support multiple things with a single name and have animations bind to the right one<br> <TabAtkins> flackr: so i think we need some well-defined way to override names<br> <TabAtkins> flackr: so in the issue i was proposing tree order<br> <TabAtkins> flackr: so the most recenty-defined thing is chosen<br> <TabAtkins> fantasai: so walk backwards thru the tree<br> <TabAtkins> dbaron: so you're saying you'd include something established by the descendant of a previous sibling?<br> <TabAtkins> flackr: yeah,a nd there are use-cases for this<br> <TabAtkins> emilio: that can be a perf hit when doing the lookup<br> <TabAtkins> flackr: in perf, for each name save a list of tree-order indexes<br> <TabAtkins> emilio: we don't have such a list<br> <TabAtkins> flackr: oh i thought browsers had that<br> <TabAtkins> emilio: wouldn't that break with mutations? lots of updates when you insert<br> <TabAtkins> flackr: there are ways to get around that<br> <fantasai> TabAtkins: there is a DOM API for comparing positions, but it's slow<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: i would caution against using counters as a precedent<br> <bkardell_> q+<br> <TabAtkins> dbaron: they were designed with a weird set of requirements that led to their design, and i wouldn't assume that's waht you want to copy unless it's the same requirements<br> <TabAtkins> flackr: use-case is there are things outside the scroller that want to update based on the scroller's position<br> <TabAtkins> flackr: like specific, progress thru a carousel, have dots update to show what pane you're on<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: if we want to make it global thru a page, flattened tree isn't ideal<br> <TabAtkins> fantasai: would want to check siblings first instead of cousins<br> <TabAtkins> fantasai: So i think we want an order where you look up siblings, then parent, etc<br> <TabAtkins> TabAtkins: So never descend the tree, just go up and sideways?<br> <TabAtkins> fantasai: Maybe. if we want more full global could deprioritize going down first<br> <TabAtkins> flackr: I think that would do good enough<br> <astearns> ack bkardell_<br> <TabAtkins> astearns: unsure how we'd prioritize<br> <TabAtkins> flackr: Could punt going down for now<br> <fantasai> TabAtkins: so searching up and sideways... not quite counter scope<br> <fantasai> TabAtkins: so any of your siblings, your ancestors, and their siblings, but not going back down<br> <bramus> q+<br> <TabAtkins> astearns: efficiency concerns?<br> <TabAtkins> TabAtkins: that's an ancestor walk with some sibling walks along the way<br> <TabAtkins> emilio: eh, with big trees can still be annoying<br> <TabAtkins> fantasai: assume there's some caching around<br> <TabAtkins> emilio: yeah<br> <TabAtkins> emilio: depending on impl, might be tricky to invalidate properly<br> <TabAtkins> emilio: if you're building the tree you might not have later sibling info yet<br> <ydaniv> q+<br> <TabAtkins> emilio: the level of trickiness is varying<br> <TabAtkins> flackr: in my opinion the use-cases that need siblings can use previous siblings and then use grid/flex to swap around layout<br> <astearns> ack bramus<br> <TabAtkins> fantasai: don't want to force bad source ordering tho<br> <TabAtkins> bramus: wondering if this still allows for a carousel to reach the end of the carousel and animate something else that's not a sibling or an ancestor?<br> <TabAtkins> fantasai: yes, it searches from the element trying to *find* the timeline<br> <bkardell_> q+<br> <TabAtkins> bramus: so this wouldn't work then?<br> <TabAtkins> fantasai: depends on what you're trying to do<br> <TabAtkins> flackr: think for a carousel it means you can't have ac ontainer on the scrolling element<br> <fantasai> TabAtkins: Have we considered swapping between local and global scope?<br> <fantasai> TabAtkins: so that local things can do the cheap thing<br> <fantasai> TabAtkins: but can expand the scope when needed<br> <TabAtkins> bramus: and last one wins if there's a collision<br> <TabAtkins> emilio: do we have a good story of what happens we you mutate the tree?<br> <TabAtkins> emilio: Is it well-defined when you perform this lookup, and if you need to change stuff when this changes<br> <fantasai> TabAtkins: I think you're asking about batch and flush layout?<br> <fantasai> emilio: not necessarily<br> <flackr> qq+<br> <fantasai> emilio: You choose the same timeline name as you have earlier, do you restart the animation? What do you do? When and how long does your choice of timeline last?<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to bramus<br> <fantasai> flackr: our name lookup is important for this because, if it's global it can happen based on style of any element, but if just preceding siblings and ancestors, we can know which scroll timeline you're looking at<br> <fantasai> flackr: we don't restart timelines, it's defined in Web Animations what to do<br> <bkardell_> q-<br> <bramus> q+<br> <fantasai> flackr: but expectation is that as part of doing style and layout, we can update to the new correct timeline and resolve the timeline according to position in that timeline<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: like robert said, if we start with something simple and get more complex lookups later, maybe using JS api people can make more complex usages<br> <TabAtkins> astearns: not a bad idea. have to consider how we expand this in css, tho - adding keywords to determine the scope rules?<br> <TabAtkins> fantasai: tab suggested a timeline-scope<br> <astearns> ack bramus<br> <TabAtkins> bramus: what if you made the switch automatic? if you have non-named scroll timelines they're local, but named timelines are global?<br> <TabAtkins> flackr: how would you refer to an anonymous timeline for a later timeline?<br> <TabAtkins> bramus: from the scroll() function..?<br> <TabAtkins> fantasai: that doesn't work in view-timeline<br> <TabAtkins> fantasai: I don't think we shoudl switch on name, we want something more ergonomic<br> <flackr> q+<br> <astearns> ack flackr<br> <TabAtkins> fantasai: Could also have the model where an element can declare it's the scope, but the driver for the timeline is later in the tree and binds itself<br> <TabAtkins> flackr: I suggest we use the siblings/ancestors and add a switch later<br> <TabAtkins> flackr: and for impl, when we discover a scroll timeline has changed we schedule another style pass, and we should be able to handle mutations in that pass<br> <TabAtkins> flackr: if a named timeline has changed, we need to restart style and layout with that timeline<br> <TabAtkins> astearns: and this is just earlier siblings, right?<br> <TabAtkins> flackr: Yes, tho i'm open to later siblings<br> <TabAtkins> TabAtkins: Later sibs can force us to rely on waiting for th enetire document to load<br> <TabAtkins> emilio: You have to do that anyway for :nth-clast-child(), etc<br> <TabAtkins> emilio: We have some examples, but could be tricky<br> <TabAtkins> flackr: i think once we have experience we could ahve stronger rationale one way or the other<br> <TabAtkins> astearns: fair. until we have experience i suggest going with earlier siblings only, seems more likely to succeed<br> <TabAtkins> fantasai: one way to avoid having to look at all document is to look at closest sibling, in either direction<br> <TabAtkins> TabAtkins: I'm uncomfortable with a completely novel lookup mechanism without strong justification<br> <TabAtkins> fantasai: justification is the elements are usually near each other<br> <TabAtkins> astearns: That's only different from a simple walk if there are name collisions, tho<br> <TabAtkins> flackr: and there usually shouldn't be<br> <TabAtkins> astearns: so I recommend the scope of timelines is that elements will look for timelines among their previous siblings and ancestors, transitively. can add a switch for more complex behavior in the future.<br> <TabAtkins> astearns: Amendments?<br> <TabAtkins> flackr: I like it. I think elika's earlier concern about not forcing authors to reorder their content - usually scroll timelines are decorative, so content order is less important.<br> <fantasai> TabAtkins: forcing a specific order isn't a problem if it doesn't interfere with semantic ordering<br> <TabAtkins> TabAtkins: We don't like forcing it if unnecessary, but okay if needed<br> <TabAtkins> fantasai: should look into the idea of declaring a named scope and letting a scroller bind to it, think that will solve a lot of issues<br> <TabAtkins> fantasai: I'll explore it in this issue, split out if needed.<br> <TabAtkins> proposed resolution: timeline search looks at ancestors and preceding siblings, recursively<br> <TabAtkins> (and we'll revisit with impl experience as needed)<br> <TabAtkins> RESOLVED: timeline search looks at preceding siblings and ancestors, recursively<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7047#issuecomment-1203984802 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 13:56:10 UTC