[css-scroll-anchoring-1] Explicit anchoring #4264
Comments
|
Another use case I suppose what #7745 proposed is adding Anyways, what's the next step to enforce this new overflow-anchoring value? We(I) would like to fix the issue on Facebook as soon as possible. |
|
As it already came up a bunch of times lately, let's discuss that on a call. Sebastian |
|
The CSS Working Group just discussed The full IRC log of that discussion<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.<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 <emilio> q+ <flackr> SebastianZ: I suggest prefer keyword, name open to bikeshedding <astearns> ack emilio <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 <flackr> emilio: Do we want to restrict this to the former thing or also discuss enforcement <flackr> SebastianZ: Discuss both <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? <flackr> emilio: Is an element completely in view preferred? <flackr> astearns: the details of how this property or index value effects the heuristics would have to be precisely specified <flackr> astearns: i'm weary of another index value to fight over priority <smfr> s/weary/wary/ <astearns> ack fantasai <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 <flackr> astearns: would anyone argue against allowing authors input to the algorithm <flackr> q+ <fantasai> s/weary/wary/ <SebastianZ> q+ <fantasai> scribe+ <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 <fantasai> flackr: so that might be a reason to not have 'prefer' added now <astearns> ack SebastianZ <smfr> q+ <astearns> ack flackr <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 <flackr> SebastianZ: not having indices, just preference for some elements over others <astearns> ack smfr <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. <flackr> smfr: e.g. is there something in the ancestor chain preferred, this seems pretty complicated <fantasai> smfr++ <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 <fantasai> The idea of being able to e.g. set something on <main> makes a lot of sense to me <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 <flackr> astearns: let's take the discussion back to the issue |
The Scroll Anchoring module already allows to opt-out elements of the scroll anchoring algorithm via
overflow-anchor: none;. Andautomakes an element potentially eligible for anchoring. Though there is currently no way to enforce anchoring to an element.The idea behind this is to allow the author to tell the user agent explicitly that it should prefer specific elements when running the anchor node selection algorithm. A use case for this are several content pieces, of which one is the main content.
To make this possible, there should be a new value like
preferfor theoverflow-anchorproperty.Elements having this value set should be checked first by influencing the order in which the elements are checked in step 2 of the anchoring node selection algorithm.
It might also influence the candidate examination algorithm by preferring those elements over fully visible elements even when they are just partially visible.
Sebastian
The text was updated successfully, but these errors were encountered: