- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 18 Sep 2014 13:23:06 +0200
- To: "www-style list" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Wed, 23 Jul 2014 03:00:48 +0200, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Right now, when you call el.scrollIntoView(), it scrolls *all* scroll > containers in the element's ancestor chain, ensuring that the element > is *definitely* in view when it's done. > > This isn't always what you want. For example, say you have a 3d view > of all the albums in your iTunes library flying around, with each > album showing a cover image and then a list of tracks. If you're > currently playing a track, you want that track to be visible in the > album's list. If you try to accomplish this by calling > trackEl.scrollIntoView(), it'll move the entire page such that the > track is at the top of the screen, which probably messes up your > application view. It would be nice to have a way to just scroll > something into view in its nearest scroll container, as you currently > have to instead measure the element's offsetTop and set scrollTop on > the correct ancestor. > > I propose we add a "within" attribute to the ScrollOptions dict, > taking the values "screen" (the default), "container" (indicating > nearest scroll container ancestor) or an Element. The "scroll an > element into view" algo would then walk the ancestor chain until it > found the specified element, scrolling the element into view in each > scroll container as it passes over them. If the passed Element isn't > a scroll container, it doesn't scroll at all; if the Element isn't an > ancestor, it throws an error. (Or maybe it throws on both or fails > silently on both, dunno.) scrollIntoView scrolls both elements and frames. So it's a bit more complicated. Do we need to support more than "scroll everything" and "only scroll the nearest scrollable thing"? -- Simon Pieters Opera Software
Received on Thursday, 18 September 2014 11:23:37 UTC