🌐 US-Proxy
class="logged-out env-production page-responsive" style="word-wrap: break-word;" >
Skip to content

[css-scroll-snap-1][interop-2026] Clarify how to handle the snap target having the focused element #13673

Open

Description

@hiikezoe

In the section "Selecting between multiple aligned snap areas;

4-1. If list contains the focused box, remove all other boxes from list.

And in the overview;

Snap positions only affect the nearest ancestor scroll container on the element’s containing block chain.

So if these sentences are naively interpreted, a snap target scroll container having the focused element would not be preferred over other targets. But prefer-focused-nested-containers.html is supposed to choose such kind of scroll container having the focused element. I mean, the focused element will never be in the list for an ancestor scroll container.

The test was added to address a review comment in https://chromium-review.googlesource.com/c/chromium/src/+/5255777/14..16/third_party/blink/renderer/core/dom/element.cc#b6383 . The review comment is;

If there are nested snap containers it looks like this will only update the innermost one, is that right? Do we not need to update snap containers higher up?

From the perspective of users, the behavior what prefer-focused-nested-containers.html checks is reasonable, but the spec needs to clarify it.

@theres-waldo suggests to change the 4-1 bullet point to

If list contains a box which is focused or has a focused descendant, remove all other boxes from list.

@Devmila @skobes-chromium @fantasai

Activity

  1. emilio commented on Apr 13, 2026

    @emilio
    Collaborator
  2. css-meeting-bot commented on Jun 17, 2026

    @css-meeting-bot
    Member

    The CSS Working Group just discussed [css-scroll-snap-1][interop-2026] Clarify how to handle the snap target having the focused element, and agreed to the following:

    • RESOLVED: addd the equivelant to the suggested diff
    The full IRC log of that discussion <TabAtkins> agree, seems uncontroversial to me, +1
    <ydaniv> emilio: the selecting between multiple lines snap areas,
    <fantasai> +1
    <flackr> +1
    <smfr> "focused element"
    <JohnJansen> I'm very impressed by your English.
    <ydaniv> ... the spec says remove the focused element, and instead check nested snap areas etc
    <flackr> q+
    <ydaniv> ... the proposal is to change spec to say if it contains a box that's focused or it's decendants
    <Psychpsyo_Cameron> (What is "present+"?)
    <astearns> ack flackr
    <flackr> https://github.com//issues/9917
    <ydaniv> flackr: I completely agree this is the intent, would happy to change, threre's a related issue we agreed on
    <ydaniv> flackr: support of updating the algo to make that the case
    <ydaniv> astearns: concerns?
    <ydaniv> fantasai: I need details, looking at spec there's stuff about focused box and targeted box, we do on both?
    <ydaniv> flackr: yes
    <ydaniv> fantasai: another thing in spec, if we have both, do we have prioritization?
    <ydaniv> TabAtkins: scroll snaps are always siblings, no?
    <ydaniv> fantasai: no
    <ydaniv> emilio: probably by distance
    <TabAtkins> oh right, i'm being silly
    <ydaniv> fantasai: so probably focused or targeted and prioritize on nearest, and clarify that
    <ydaniv> flackr: I think you want nearest the specifies a target
    <ydaniv> fantasai: has to be in the list
    <smfr> q+
    <ydaniv> flackr: yes
    <astearns> ack smfr
    <astearns> ack fantasai
    <Zakim> fantasai, you wanted to ask about target
    <ydaniv> smfr: about the issue flackr listed, is that going to be an issue in interop?
    <ydaniv> flackr: don't know
    <ydaniv> emilio: current issue is covered by interop
    <ydaniv> ... I don't think the other one is scoped by the Interop26 tests, need to check again
    <ydaniv> ... unless it changes probably answer is no
    <ydaniv> astearns: so nees test vetting as well as tests needed
    <ydaniv> astearns: so we'll change tests and ask Interop folks, who can summarize?
    <fantasai> 1. Let |inline| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the inline axis.
    <fantasai> 1. Let |block| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the block axis.
    <fantasai> 1. For each |list| of |block| and |inline|:
    <fantasai> - 1. If |list| contains the focused box, remove all other boxes from |list|.
    <fantasai> - 1. If |list| contains the targeted box, remove all other boxes from |list|.
    <fantasai> + 1. If |list| contains a focused box,
    <fantasai> + remove all other boxes from |list|.
    <fantasai> + Otherwise if it contains a box that contains a focused box,
    <fantasai> + remove all but that which is its closest ancestor.
    <fantasai> + 1. If |list| contains a targetted box,
    <fantasai> + remove all other boxes from |list|.
    <fantasai> + Otherwise if it contains a box that contains a targetted box,
    <fantasai> + remove all but that which is its closest ancestor.
    <fantasai> 1. For each |box| in |list|:
    <fantasai> 1. Remove any box from |list| which is an ancestor of |box|.
    <fantasai> 1. If |inline| and |block| are overlapping sets:
    <fantasai> ...
    <ydaniv> astearns: I think fantasai argued against algos in spec, but looks like an algo
    <ydaniv> fantasai: yes but that's what's currently there, in some cases we need them
    <ydaniv> astearns: more comments?
    <ydaniv> emilio: to we want to prioritize targeted or focused?
    <ydaniv> fantasai: focused
    <ydaniv> PROPOSED: apply the suggested diff
    <ydaniv> emilio: might be simpler to do priority sorting, but otherwise fine
    <ydaniv> astearns: objections?
    <ydaniv> RESOLVED: addd the equivelant to the suggested diff
    <astearns> zakim, end meeting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions