On Friday, September 5, 2014 7:14:25 PM UTC+2, Jens wrote: > > So, if you could make all "domain.TLD/" requests forward to your index >> page, while keeping the URL, then bootstrap some pushState detection logic, >> and then redirect to the othothorpe version (build permutation) if they >> don't support push state, you might be able to swing it. Should be >> possible, but obviously complex and why the othothorpe remains standard. >> > Don't forget that someone could share a link using hash fragments with a > person whose browser supports pushState. Never really used pushState but I > guess in that case you either have to fallback to hash fragments even > though the browser might support pushState or redirect to an URL without > hash fragment (which kind of seems silly to me). >
No need to redirect, just pushState (or replaceState) to the URL without fragment; or just process the fragment like you'd process the path in a no-fragment case, and the next time you need to update the URL, you'll use pushState with a URL without hash fragment. (in other words: "fix" the URL right away, or wait 'til the next time you need to update it; that also means that for browsers that support pushState, you'll support both hash and path – but I suppose not necessarily both onpopstate and onhashchange) AFAICT, this (using replaceState to go from hash to path/query) is what History.js uses: https://github.com/browserstate/history.js/ -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
