Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec Review for scroll-start-target #1011

Closed
1 task done
DavMila opened this issue Nov 5, 2024 · 4 comments
Closed
1 task done

Spec Review for scroll-start-target #1011

DavMila opened this issue Nov 5, 2024 · 4 comments
Assignees
Labels
Focus: API design (pending) Progress: review complete Resolution: satisfied with concerns The TAG is satisfied with this work overall but requires changes Topic: CSS Topic: DOM About or relating to the Document Object Model Venue: CSS WG

Comments

@DavMila
Copy link

DavMila commented Nov 5, 2024

こんにちは TAG-さん!

I'm requesting a TAG review of scroll-start-target

This is a proposal to introduce a CSS property which authors can use to control which element(s) a scroll container will be initially scrolled to, i.e. when it first appears on a page. It is intended to provide a reliable way for developers to give their scroll containers a non-(0,0) default starting scroll position without using JavaScript or other tricks involving animations and scroll-snapping.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines:
  • The group where the work on this specification is currently being done: CSS Working Group
  • The group where standardization of this work is intended to be done (if different from the current group):
  • Major unresolved issues with or opposition to this specification: None
@jyasskin
Copy link
Contributor

jyasskin commented Nov 6, 2024

A couple questions here:

  1. Is scroll-start-target: auto a developer-friendly way to say "please scroll to me"? I'd expect auto to mean "do what the UA thinks is right", which is not the behavior it's currently specified to have. I could imagine on-first-appearance being a clearer way to describe what it's asking for. This sort of naming question is firmly within the CSSWG's area of expertise, so there's probably a long discussion thread about it, and I would just benefit from a link to it.
  2. https://drafts.csswg.org/css-scroll-snap-2/#scroll-start-target-fragment-navigation says "While the document is being updated ...". This sort of COMEFROM statement is out of favor in modern specifications. Can y'all work to add an appropriate hook in HTML?
  3. If a page is slow to load and has multiple scroll-start-target elements, it seems like the current definition might cause multiple scrolls, if the UA decides to partially render after getting the initial target. Developers might not see this if they test only on a fast connection, but users on slower devices could wind up with a bad experience. Does something in the definition subtly prevent this? Has the WG discussed how to prevent it?

Thanks!

@jyasskin jyasskin added Topic: CSS Venue: CSS WG Progress: pending editor update TAG is waiting for a spec/explainer update Topic: DOM About or relating to the Document Object Model Focus: API design (pending) labels Nov 6, 2024
@DavMila
Copy link
Author

DavMila commented Nov 8, 2024

  1. Is scroll-start-target: auto a developer-friendly way to say "please scroll to me"? I'd expect auto to mean "do what the UA thinks is right", which is not the behavior it's currently specified to have. I could imagine on-first-appearance being a clearer way to describe what it's asking for. This sort of naming question is firmly within the CSSWG's area of expertise, so there's probably a long discussion thread about it, and I would just benefit from a link to it.

Great point but unfortunately, I'm afraid there isn't a discussion thread I can point to.
I think you are right that this would be a bit of a departure from what auto in CSS means. A better keyword might be in order, something like: on-first-appearance or align or active or visible. I'll file an issue with the working group.

  1. https://drafts.csswg.org/css-scroll-snap-2/#scroll-start-target-fragment-navigation says "While the document is being updated ...". This sort of COMEFROM statement is out of favor in modern specifications. Can y'all work to add an appropriate hook in HTML?

That seems like a good idea, thanks. I’ll write a PR to add a hook to the HTML spec.

  1. If a page is slow to load and has multiple scroll-start-target elements, it seems like the current definition might cause multiple scrolls, if the UA decides to partially render after getting the initial target. Developers might not see this if they test only on a fast connection, but users on slower devices could wind up with a bad experience. Does something in the definition subtly prevent this? Has the WG discussed how to prevent it?

The spec prioritizes selecting the scroll-start-target element which is first in DOM order.
For the UA to select and scroll to a different target, the UA would have to have inserted the late-arriving target into the DOM in a position that is before the position of the already-selected target in DOM order. We think that it isn’t very common for pages to load elements out-of-order and so having multiple scroll-start-target elements is not likely to lead to unfriendly jumps.

@jyasskin
Copy link
Contributor

jyasskin commented Nov 9, 2024

  1. Thanks!
  2. Thanks!
  3. Ah, ok. After re-reading the spec, I agree that it says to always use the first candidate element, and nothing in the explainer contradicts that. I was thinking that the page could add a scroll-start-target element in response to user interaction, and the UA was supposed to scroll to the new one even if there were old ones earlier in tree order, but that's not correct.

I don't see any other issues, and I'll see if we can close this this week.

@jyasskin jyasskin added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus and removed Progress: untriaged Progress: pending editor update TAG is waiting for a spec/explainer update labels Nov 9, 2024
@jyasskin jyasskin self-assigned this Nov 9, 2024
@jyasskin jyasskin added this to the 2024-11-11-week milestone Nov 9, 2024
@jyasskin
Copy link
Contributor

jyasskin commented Nov 12, 2024

Thanks for bringing us this review. In addition to the comments above, we think "start" in the property name may be confused with the start vs end edges of a box. Could the CSSWG look into another term there?

Aside from that, we think this feature can't be considered ready until the WG has discussed using a property value other than auto, but once those two discussions have happened, it looks like a good feature, and we expect to be happy to switch this review to Resolution: satisfied if you ping us.

@jyasskin jyasskin added Progress: review complete Resolution: satisfied with concerns The TAG is satisfied with this work overall but requires changes and removed Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Focus: API design (pending) Progress: review complete Resolution: satisfied with concerns The TAG is satisfied with this work overall but requires changes Topic: CSS Topic: DOM About or relating to the Document Object Model Venue: CSS WG
Projects
None yet
Development

No branches or pull requests

2 participants