- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 18 Sep 2014 11:08:25 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Sep 18, 2014 at 4:23 AM, Simon Pieters <simonp@opera.com> wrote: > 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"? We could probably get away with just that, but I'd be afraid of it being fragile to application changes; adding an "overflow:hidden" between the element and its scrolling container would hijack the scroll. We already suffer from this problem with abspos, and I'd rather not repeat it. ~TJ
Received on Thursday, 18 September 2014 18:09:13 UTC