- From: Jeffrey Yasskin <notifications@github.com>
- Date: Wed, 06 Nov 2024 08:53:51 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1011/2460300421@github.com>
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](https://html.spec.whatwg.org/multipage/browsing-the-web.html#updating-the-document) ...". This sort of [COMEFROM](https://en.wikipedia.org/wiki/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! -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1011#issuecomment-2460300421 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1011/2460300421@github.com>
Received on Wednesday, 6 November 2024 16:53:55 UTC