w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
332 stars 56 forks source link

Spec Review for scroll-start-target #1011

Open DavMila opened 2 days ago

DavMila commented 2 days ago

こんにちは 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:

jyasskin commented 1 day ago

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!