You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
In non-pushstate browsers, jQM manages its history and deep linking behavior through the hash. When the page loads, or when the hash changes, it’s designed to interpret anything in the hash as a reference to an actual document, either local or remote. It’s a great way to make sure the back button and linking works in most any browser, but it’s also a great way of killing a behavior that’s really useful developers and users.
I think it’s important that we build on top of the native way of doing things, rather than introducing a whole new weird way of linking.
If we look to enhance on top of the native syntax, that means links to URLs like “about.html#foo” would have to request about.html via Ajax, then set that page’s end scroll distance to the top offset of an element with an ID of #foo (if it exists in the page). Clicking back to that page would have to have some business rules about whether the URL or a remembered scroll would take precedence. On page load, jQM will have to first check if an element with an ID of “foo” exists in the page, and if it’s not a page element, it should simply scroll to that element’s position. All this will require a change in maybe a few places in the nav handler.
I’m not sure we’ll be able to make this mechanism work for non-pushstate browsers at all, because when we update the hash, we’ll already need to use it for the URL, and we can’t have 2 of hashes. But, we can probably make navigating TO the fragment work in non-pushstate browsers, with the downside that the fragment may not remain in the URL for bookmarking (so you'd lose the scroll distance if you tried.)
For 1.2, it'd be nice to see if we can finally work this out.
The text was updated successfully, but these errors were encountered:
In non-pushstate browsers, jQM manages its history and deep linking behavior through the hash. When the page loads, or when the hash changes, it’s designed to interpret anything in the hash as a reference to an actual document, either local or remote. It’s a great way to make sure the back button and linking works in most any browser, but it’s also a great way of killing a behavior that’s really useful developers and users.
I think it’s important that we build on top of the native way of doing things, rather than introducing a whole new weird way of linking.
If we look to enhance on top of the native syntax, that means links to URLs like “about.html#foo” would have to request about.html via Ajax, then set that page’s end scroll distance to the top offset of an element with an ID of #foo (if it exists in the page). Clicking back to that page would have to have some business rules about whether the URL or a remembered scroll would take precedence. On page load, jQM will have to first check if an element with an ID of “foo” exists in the page, and if it’s not a page element, it should simply scroll to that element’s position. All this will require a change in maybe a few places in the nav handler.
I’m not sure we’ll be able to make this mechanism work for non-pushstate browsers at all, because when we update the hash, we’ll already need to use it for the URL, and we can’t have 2 of hashes. But, we can probably make navigating TO the fragment work in non-pushstate browsers, with the downside that the fragment may not remain in the URL for bookmarking (so you'd lose the scroll distance if you tried.)
For 1.2, it'd be nice to see if we can finally work this out.
The text was updated successfully, but these errors were encountered: