- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Dec 2022 17:23:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-anchoring-1] Explicit anchoring`. <details><summary>The full IRC log of that discussion</summary> <flackr> SebastianZ: explicit anchoring came up many times. We currently have some overflow anchoring that you can opt out of, but there is no way to choose explicit anchoring or set elements to be preferred explicitly.<br> <flackr> SebastianZ: the idea that came up several times is to add a new keyword to the overflow-anchor property, indicates the element is preferred in the anchoring node selection algorithm step 2<br> <emilio> q+<br> <flackr> SebastianZ: I suggest prefer keyword, name open to bikeshedding<br> <astearns> ack emilio<br> <flackr> emilio: there are 2 interleaved things. Your proposal is about making a note about somehow being preferred. The other thing mentioned is about force enabling anchoring. Right now there's a bunch of heuristics<br> <flackr> emilio: Do we want to restrict this to the former thing or also discuss enforcement<br> <flackr> SebastianZ: Discuss both<br> <flackr> emilio: The prefers stuff may be a bit tricky when you have conflicting elements. Should the preference be a number to help with this, what elements should be excluded?<br> <flackr> emilio: Is an element completely in view preferred?<br> <flackr> astearns: the details of how this property or index value effects the heuristics would have to be precisely specified<br> <flackr> astearns: i'm weary of another index value to fight over priority<br> <smfr> s/weary/wary/<br> <astearns> ack fantasai<br> <flackr> fantasai: if you set prefer on it, maybe you filter the list of candidates to the preferred list, and then fall back to the non-preferred list<br> <flackr> astearns: would anyone argue against allowing authors input to the algorithm<br> <flackr> q+<br> <fantasai> s/weary/wary/<br> <SebastianZ> q+<br> <fantasai> scribe+<br> <fantasai> flackr: I think that we're still fairly naive in the anchoring algorithm, and introducing a preference and having ways that we expect that preference to work now might prevent us from making improvements to the overall anchor selection<br> <fantasai> flackr: so that might be a reason to not have 'prefer' added now<br> <astearns> ack SebastianZ<br> <smfr> q+<br> <astearns> ack flackr<br> <flackr> SebastianZ: just to emphasize. Regarding providing an index, my suggestion was just to give the algorithm a hint to choose the element but not to enforce anchoring explicitly<br> <flackr> SebastianZ: not having indices, just preference for some elements over others<br> <astearns> ack smfr<br> <flackr> smfr: the use case in the first comment, is about making sure content inside the main content of the page is what's preferred. This sounds like something that's set on an ancestor of a node that's important. There's a lot of hierarchy logic that needs to be defined.<br> <flackr> smfr: e.g. is there something in the ancestor chain preferred, this seems pretty complicated<br> <fantasai> smfr++<br> <flackr> astearns: I suggest that we take the discussion back to the issue, not opposed to having a simple preference but we have to work through it and also happy with the idea of trying to improve the algorithm we have without this first and adding it in a later level<br> <fantasai> The idea of being able to e.g. set something on <main> makes a lot of sense to me<br> <flackr> astearns: or at a point where we feel the algorithm is as good as we will make it and we need preference to improve<br> <flackr> astearns: let's take the discussion back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4264#issuecomment-1341312505 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 December 2022 17:23:27 UTC