In reading these comments, I think my article probably argues too hard for this technique as a space-saver (40px or however much), when its potentially more interesting benefit is that it makes a web app feel more like a native app, with less browser chrome in your way. We all know the “fold” is not something we should ever dwell on, especially in the mobile world, and I didn’t mean to draw so much focus to getting your content above it (whatever “it” might be). :)
ART makes a valid point: this behavior is already commonplace in the browser’s default behavior, such as when a hash is present in the URL. It just doesn’t happen every time.
STEPHEN: thanks for answering Mike’s questions.
MIKE: The load event question is a confusing one, I’m not sure why the device prefers that the scroll occurs after the load event’s other-and-default scripting has completed, but I think it’s because load is the earliest the browser can reliably jump to a location in the document on its own (if a hash or previous scroll distance is remembered), since the height of the page is reliable at that point. Anyway, Stephen’s explanation of why the timeout helps there sounds good to me; the timeout of zero defers the scripting to execute asynchronously, which will be as soon as the other current synchronous scripting is finished. At one point, I tried removing the timeout and using event.preventDefault() just for kicks, but it didn’t seem to do anything.
MATT: no problem at all, I understand what you meant now :)
Scott Jehl
Thanks everyone. Great stuff, once again.
In reading these comments, I think my article probably argues too hard for this technique as a space-saver (40px or however much), when its potentially more interesting benefit is that it makes a web app feel more like a native app, with less browser chrome in your way. We all know the “fold” is not something we should ever dwell on, especially in the mobile world, and I didn’t mean to draw so much focus to getting your content above it (whatever “it” might be). :)
ART makes a valid point: this behavior is already commonplace in the browser’s default behavior, such as when a hash is present in the URL. It just doesn’t happen every time.
STEPHEN: thanks for answering Mike’s questions.
MIKE: The load event question is a confusing one, I’m not sure why the device prefers that the scroll occurs after the load event’s other-and-default scripting has completed, but I think it’s because load is the earliest the browser can reliably jump to a location in the document on its own (if a hash or previous scroll distance is remembered), since the height of the page is reliable at that point. Anyway, Stephen’s explanation of why the timeout helps there sounds good to me; the timeout of zero defers the scripting to execute asynchronously, which will be as soon as the other current synchronous scripting is finished. At one point, I tried removing the timeout and using event.preventDefault() just for kicks, but it didn’t seem to do anything.
MATT: no problem at all, I understand what you meant now :)