- From: Robert Flack <notifications@github.com>
- Date: Tue, 17 Jun 2025 07:47:12 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 17 June 2025 14:47:16 UTC
flackr left a comment (w3ctag/design-reviews#1105) > The TAG agrees that this solves a clear issue with `scrollIntoView`. The discussion in [w3c/csswg-drafts#9452](https://github.com/w3c/csswg-drafts/issues/9452) looks to have discussed a few potential shapes for the solution, and while the CSSWG ultimately [resolved](https://github.com/w3c/csswg-drafts/issues/9452#issuecomment-2607879021) to use an enum rather than allowing a particular element to be specified, the spec still leaves some uncertainty: [w3c/csswg-drafts#12260](https://github.com/w3c/csswg-drafts/issues/12260). Could you take a look at the questions [@zcorpan](https://github.com/zcorpan) raised there? Thanks, the only exposed change here is the enum values "nearest" or "all". The algorithm as currently specified internally allows specs to pass a container element however this is not something that developers can access. The generalized algorithm is there to allow for use by the overflow-5 spec to ensure that scroll markers do not propagate scrolling beyond their associated scroll container, however this is not part of this feature. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1105#issuecomment-2980678588 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1105/2980678588@github.com>
Received on Tuesday, 17 June 2025 14:47:16 UTC