[whatwg] scrollIntoView()
Ian has suggested several times so far that I take over editing of the scrollIntoView() method and define it in the CSSOM View Module: http://dev.w3.org/csswg/cssom-view/ I agree that is a more appropriate place. I played around with it a little and it seems that in browsers other than Opera invoking the method affects the scrolling position of ancestor documents. I.e. if you have a document in an iframe where scrollIntoView() is invoked on an element not only will that document scroll, but the document the iframe is in will scroll as well. In addition this will dispatch events to each document object of which the document is scrolled, and any elements that are scrolled in the process (the order is innermost-outermost, and sync in Webkit, async in Gecko, afaict). I was wondering whether this should happen cross-origin as well. That seems like a minor leak of some sorts. And if that should happen, should the sandbox= attribute disable it? Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] scrollIntoView()
On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay o...@pettay.fi wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] scrollIntoView()
On Tue, Aug 17, 2010 at 11:56 PM, Anne van Kesteren ann...@opera.comwrote: On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay o...@pettay.fi wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. Async events are also generally safer to implement and use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
[whatwg] scrollIntoView feedback
(The e-mails included in this reply were all cc'ed to whatwg, but some were also cc'ed to other mailing lists. To reduce cross-posting, I've only included [EMAIL PROTECTED] on this reply, since that was the only list that was included on all the e-mails. If you reply, feel free to respond on any mailing list, but please avoid cross-posting, and include me on the cc list if it's not the whatwg or public-html lists. Thanks!) On Wed, 30 Apr 2008, David Bolter wrote: I have a concern about 3.5.3 Scrolling elements into view: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrollintoview In addition to concerns expressed by Brad Fults (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012655.html), I want to raise a concern about the behaviour of scrollIntoView. Specifically I would ask that: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) My concern is that with the movement towards rich interactive web interfaces, we are going to be seeing complex widgets that will need to call such functions fairly often, which may lead to a jarring experience if the function always butts the element to the edge of the viewport. It would be a shame to jar users when unnecessary. I realize there is a (hairy) way to do this but it would be nice to have the convenience. As the spec is currently written, user agents are allowed to experiment with different ways to scroll the content into view. I'll happily change the spec to be more in line with what browsers do, if they change. Aside: we would like to recommend authors call such a method when using ARIA's activedescendant (draft spec). Wouldn't that be more appropriate in the ARIA spec? On Wed, 30 Apr 2008, Peter Kasting wrote: I make no formal proposal, but the behavior I would typically want for some kind of a call (perhaps in addition to those above, I don't know) would be: - If the element in question cannot be scrolled so as to make more of it appear in the viewport, do nothing. (For when the element is completely visible, or is larger than the viewport and already taking up the whole viewport). - Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). - Otherwise, scroll the element such that the top of the element is aligned with the top of the viewport. *Perhaps centered is the wrong choice. Another suggestion would be to scroll to a point 1/3 of the way from the top or bottom of the viewport, nearer to whichever edge the element scrolled in from. Also, perhaps the UA's behavior should not be specified in this kind of detail? As far as I can tell, as defined, browsers would be allowed to do all this for scrollIntoView(). On Fri, 2 May 2008, David Bolter wrote: I'm not sure of the intended use cases of scrollIntoView, so for now I still agree with Brad Fults, that horizontal scrolling shouldn't be forgotten here. And if we want scollIntoView to butt the element to the edge no matter what, that's fine, but we shouldn't expect that to be received as the ideal/desired behavior by all. Couldn't we make it optional? It is effectively optional now. Horizontal scrolling is also required. On Wed, 30 Apr 2008, L. David Baron wrote: It seems like authors might actually want different options here for different uses. Aligning things with an edge of the viewport, or with the edge of some other scrollable container, might be useful in some cases, and just ensuring that it is visible might be useful in others. Mozilla has an internal function used to implement a number of different scrolling APIs (including scrolling to named anchors) that has a bunch of options: * scroll into view (no matter where) * scroll to align with a particular edge of the page * scroll only if it's not visible at all I think in many cases these scrolling APIs are about making things that authors can already do (using scrollTop, offsetTop, offsetHeight, offsetParent, and similar properties) easier to do. So I think the main questions to consider for these APIs are: * what capabilities do they provide that can't already be done? * what are the common uses of the existing features for scrolling things into view (perhaps adjusted by how hard it is to do the different possibilities)? (It's also worth thinking about how all of these deal with nested scrollable containers, and about how they deal with the interaction of vertical and horizontal scrolling. The
Re: [whatwg] scrollIntoView feedback
On Thu, Jul 31, 2008 at 2:31 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 30 Apr 2008, Peter Kasting wrote: - Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). As far as I can tell, as defined, browsers would be allowed to do all this for scrollIntoView(). I don't read the spec that way. The phrase with the bottom of the element aligned with the bottom of the viewport seems to rule out the possibility of other alignments such as suggested above. If you wish browser vendors to have the freedom to experiment here, perhaps a vague sentence such as the user agent should scroll the element as necessary such that as much of it as possible is visible in the viewport would suffice. My impression was that Firefox 3 changed scrollIntoView behavior precisely to comply with the detailed description currently in the spec. It is effectively optional now. Horizontal scrolling is also required. Now I'm wondering whether I'm looking at the wrong version of the spec, since I don't see any of that. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#scrollintoviewstill seems to read a lot like I remember it... PK
[whatwg] scrollIntoView jarring?
I have a concern about 3.5.3 Scrolling elements into view: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrollintoview In addition to concerns expressed by Brad Fults (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012655.html), I want to raise a concern about the behaviour of scrollIntoView. Specifically I would ask that: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) My concern is that with the movement towards rich interactive web interfaces, we are going to be seeing complex widgets that will need to call such functions fairly often, which may lead to a jarring experience if the function always butts the element to the edge of the viewport. It would be a shame to jar users when unnecessary. I realize there is a (hairy) way to do this but it would be nice to have the convenience. Aside: we would like to recommend authors call such a method when using ARIA's activedescendant (draft spec). cheers, David
Re: [whatwg] scrollIntoView jarring?
On Wed, Apr 30, 2008 at 10:58 AM, David Bolter [EMAIL PROTECTED] wrote: Specifically I would ask that: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman ( http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) I agree that this is a use case which scrollIntoView does not seem to solve well. I am not sure Daniel's proposal for ensureElementIsVisible is perfect either, though it is clearly better. I make no formal proposal, but the behavior I would typically want for some kind of a call (perhaps in addition to those above, I don't know) would be: - If the element in question cannot be scrolled so as to make more of it appear in the viewport, do nothing. (For when the element is completely visible, or is larger than the viewport and already taking up the whole viewport). - Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). - Otherwise, scroll the element such that the top of the element is aligned with the top of the viewport. *Perhaps centered is the wrong choice. Another suggestion would be to scroll to a point 1/3 of the way from the top or bottom of the viewport, nearer to whichever edge the element scrolled in from. Also, perhaps the UA's behavior should not be specified in this kind of detail? PK
Re: [whatwg] scrollIntoView jarring?
Peter Kasting wrote: On Wed, Apr 30, 2008 at 10:58 AM, David Bolter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Specifically I would ask that: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) I agree that this is a use case which scrollIntoView does not seem to solve well. I am not sure Daniel's proposal for ensureElementIsVisible is perfect either, though it is clearly better. I make no formal proposal, but the behavior I would typically want for some kind of a call (perhaps in addition to those above, I don't know) would be: * If the element in question cannot be scrolled so as to make more of it appear in the viewport, do nothing. (For when the element is completely visible, or is larger than the viewport and already taking up the whole viewport). * Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). * Otherwise, scroll the element such that the top of the element is aligned with the top of the viewport. *Perhaps centered is the wrong choice. Another suggestion would be to scroll to a point 1/3 of the way from the top or bottom of the viewport, nearer to whichever edge the element scrolled in from. Also, perhaps the UA's behavior should not be specified in this kind of detail? Peter, Nice. I agree on all points, except maybe if larger than the viewport we might want to butt an element corner to a viewport corner (perhaps top-left for left-to-right languages), but I also wonder if that is too much detail. cheers, David
Re: [whatwg] scrollIntoView jarring?
On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) It seems like authors might actually want different options here for different uses. Aligning things with an edge of the viewport, or with the edge of some other scrollable container, might be useful in some cases, and just ensuring that it is visible might be useful in others. Mozilla has an internal function used to implement a number of different scrolling APIs (including scrolling to named anchors) that has a bunch of options: * scroll into view (no matter where) * scroll to align with a particular edge of the page * scroll only if it's not visible at all I think in many cases these scrolling APIs are about making things that authors can already do (using scrollTop, offsetTop, offsetHeight, offsetParent, and similar properties) easier to do. So I think the main questions to consider for these APIs are: * what capabilities do they provide that can't already be done? * what are the common uses of the existing features for scrolling things into view (perhaps adjusted by how hard it is to do the different possibilities)? (It's also worth thinking about how all of these deal with nested scrollable containers, and about how they deal with the interaction of vertical and horizontal scrolling. The existing text in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrolling doesn't seem to account for either. But browsers actually do need to handle these, and the spec should describe how.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] scrollIntoView jarring?
L. David Baron wrote: On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) It seems like authors might actually want different options here for different uses. Aligning things with an edge of the viewport, or with the edge of some other scrollable container, might be useful in some cases, and just ensuring that it is visible might be useful in others. Mozilla has an internal function used to implement a number of different scrolling APIs (including scrolling to named anchors) that has a bunch of options: * scroll into view (no matter where) * scroll to align with a particular edge of the page * scroll only if it's not visible at all I think in many cases these scrolling APIs are about making things that authors can already do (using scrollTop, offsetTop, offsetHeight, offsetParent, and similar properties) easier to do. So I think the main questions to consider for these APIs are: * what capabilities do they provide that can't already be done? * what are the common uses of the existing features for scrolling things into view (perhaps adjusted by how hard it is to do the different possibilities)? Another question is if the scrolling should be instant, or if smooth scrolling is allowed/desired. / Jonas
Re: [whatwg] scrollIntoView jarring?
Firefox seems to have an internal check for isElementInView, because calling scrollIntoView(false) after scrollIntoView(true) does nothing. e.g. scroll only if it's not visible at all Firefox 2 uses: scrollIntoView(true) scroll the element and its containers vertically such that the element is aligned along the top edge scrollIntoView(false) scroll the element and its containers vertically such that the element is fully visible, if possible. If it is already fully visible, don't scroll at all. This is like an ensureElementIsVisible type function. Horizontally, the ensureElementIsVisible behaviour is always used. Firefox 3 changed the vertical behaviour to be compatible with IE, although I personally think the Firefox 2 behaviour is more useful.
