4 ms·

Must-know url hash techniques (2011)

26 points by jfaucett 14y ago

StavrosK 14y ago
With pushState, isn't this now irrelevant (and, as it has always been, ugly)?
- jfaucett 14y ago
  Well, if you do not have to support older browsers, which I think a lot of webdevs still have to do, then I guess its probably irrelevant. But the history API implementations are (of course) different across browsers/platforms, so I'd recommend taking a look at history.js, if you want cross-browser RIA with good hashchange fallbacks.
  - Rygu 14y ago
    Good one, didn't know about history.js! I think the best pushState fallback is just allowing page reloads. Hashtags are probably just annoying and confusing for the user experience. Besides, there are other very effective ways to improve page load time.
    - alexchamberlain 14y ago
      I agree; the correct fallback is to load the webpage the "traditional" way.
    - jfaucett 14y ago
      I've always wished this worked w/out page reload : window.location.pathname = new_path; maybe it would be a total spec hack and kills everything the internet stands for but still it'd make things a lot easier.
wizard_2 14y ago
The author glosses over the fact that encoding of special characters in the hash is broken in firefox. As an application there's no way to know if you're getting the data you want or url encoded data. Base64 encoding (with replacing chars like $ which most im and email clients fail to autodetect as being part of the url) seems to be the only bet at the moment. Putting the data in the get request and ignoring it on the server also seems to work well.
- jacques_chester 14y ago
  Specifically, Base64Url. It's described in RFC4648 and is URL-safe.
jacques_chester 14y ago
This reminds me of the URLs generated by Oracle's Application Express (which is my main source of income at the moment). And you wind up using cookies anyhow to cross-check (ApEx does), because real applications tend to require authorisation as well as application state. So, to recap: 1. Uglier URLs 2. Cookies anyway.
hising 14y ago
I think the best solution for handling older browsers is to allow server rendering via loading the page the traditional way. Solving two problems: Keeping your urls looking like they should and also verify that your site is accessible for software that do not rely on JavaScript such as some search engines and other types of machines / software. I see little reason for messing up urls with hashchange, adds complexity when recreating correct state on bookmarks.

26 points by jfaucett 14y ago

StavrosK 14y ago

With pushState, isn't this now irrelevant (and, as it has always been, ugly)?

jfaucett 14y ago
Well, if you do not have to support older browsers, which I think a lot of webdevs still have to do, then I guess its probably irrelevant. But the history API implementations are (of course) different across browsers/platforms, so I'd recommend taking a look at history.js, if you want cross-browser RIA with good hashchange fallbacks.
- Rygu 14y ago
  Good one, didn't know about history.js! I think the best pushState fallback is just allowing page reloads. Hashtags are probably just annoying and confusing for the user experience. Besides, there are other very effective ways to improve page load time.
  - alexchamberlain 14y ago
    I agree; the correct fallback is to load the webpage the "traditional" way.
  - jfaucett 14y ago
    I've always wished this worked w/out page reload : window.location.pathname = new_path; maybe it would be a total spec hack and kills everything the internet stands for but still it'd make things a lot easier.

wizard_2 14y ago

The author glosses over the fact that encoding of special characters in the hash is broken in firefox. As an application there's no way to know if you're getting the data you want or url encoded data. Base64 encoding (with replacing chars like $ which most im and email clients fail to autodetect as being part of the url) seems to be the only bet at the moment. Putting the data in the get request and ignoring it on the server also seems to work well.

jacques_chester 14y ago
Specifically, Base64Url. It's described in RFC4648 and is URL-safe.

jacques_chester 14y ago

This reminds me of the URLs generated by Oracle's Application Express (which is my main source of income at the moment). And you wind up using cookies anyhow to cross-check (ApEx does), because real applications tend to require authorisation as well as application state. So, to recap: 1. Uglier URLs 2. Cookies anyway.

hising 14y ago

I think the best solution for handling older browsers is to allow server rendering via loading the page the traditional way. Solving two problems: Keeping your urls looking like they should and also verify that your site is accessible for software that do not rely on JavaScript such as some search engines and other types of machines / software. I see little reason for messing up urls with hashchange, adds complexity when recreating correct state on bookmarks.