- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Apr 2023 14:08:21 +0000
- To: public-css-archive@w3.org
> @flackr @bramus Wrt multiple scroll containers attempting to attach to the same name: should we be erroring this case to nothing, or taking the last one in tree order? CSS tends to use the "take the last one" principle to resolve conflicts in most places... I can imagine situations where authors would want the last inserted element to take over. For example, take a scroller where new elements are added are time (e.g. a chat interface), which all want to set the view-timeline. Here, I would expect the last inserted element to take over – irrelevant of its visual position within the scroller or its sequence in the tree. Demo: https://codepen.io/bramus/pen/wvYvqQm/a56191f447a889bd2640d0b81d7f9a70 – Click to add more boxes. The last added box *(the one with the golden border)* is the one that determines the `view-timeline` for all other `.subject` elements. The demo fakes `scroll-timeline-attachment` by a) inserting the new node _before_ all the other nodes and b) leveraging the fact that Chrome can _(for the time being)_ still look up preceding siblings their timelines. With the suggested changes from this issue – and preceding sibling lookup on its way out anyway – it should not matter where in the tree the new `.subject` is added, as the whole attachment thing should take care of it. You could of course say the author needs to more narrowly scope the element they want to target by leveraging `:nth-last-child(1)` or the like, so that only 1 element is matched in the first place. However, could also be that 2 separate selectors target 2 _different_ elements, by which you’d end up in a similar situation and the cascade can offer no further help. So I guess I’m suggesting: _“last added element wins, **no questions asked**.”_ On load that would be the tree order (I suppose?), after that it’s dynamically. I think this would match with the expectations authors have. Would that be possible implementation-wise, @andruud? If I’m doing a dumb suggestion here, then I’m definitely OK with erroring out in this particular case. -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7759#issuecomment-1499123934 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 April 2023 14:08:23 UTC