On Fri, Jul 3, 2015 at 3:07 AM, Majid Valipour <majidvp@chromium.org> wrote: > I would argue that there should be a way for programmatic scrolling to > evade "snap-points" when necessary. Perhaps evading snap points should be > default for programmatic scrolls with an option to opt in to snap points! > When an application uses a programmatic scrolls to scroll to a specific > offset it actually means to scroll to that offset and snap points should > not interfere with that. (Element.scrollIntoView and focus are the only > exceptions IMO) > > Changing this behavior breaks long-standing developer expectations of > setting scroll offsets and it taking effect (See example below). It also > prevents some legitimate usecase such as animating scroll offsets. > I agree. However, that conflicts with the spec text "If the content changes such that the visual viewport would no longer rest on a snap point (e.g. content is added, moved, deleted, resized), the scroll offset must be modified to maintain this guarantee." It doesn't make sense to allow some DOM APIs to violate that invariant but require other content changes to preserve it. If a script scrolls away from a snappoint, and then there's an insignificant DOM change, what would we do? I suggest we just remove that spec requirement; I think it's hard to implement and is likely to produce undesirable behavior anyway. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Received on Friday, 3 July 2015 06:33:44 UTC