We could use History.js for cross-browser compatibility #3

Closed
balupton opened this Issue Apr 2, 2011 · 23 comments

Comments

Projects
None yet
@balupton

balupton commented Apr 2, 2011

It would be nice if pjax supported History.js to solve those pesky cross-browser compatibility bugs and also optionally support HTML4 browsers.

@defunkt

This comment has been minimized.

Show comment
Hide comment
@defunkt

defunkt Apr 2, 2011

Owner

What bugs? I'm interested but need more information.

We already have HTML4 support: https://github.com/defunkt/jquery-pjax/blob/master/jquery.pjax.js#L175-177

⚡️

Owner

defunkt commented Apr 2, 2011

What bugs? I'm interested but need more information.

We already have HTML4 support: https://github.com/defunkt/jquery-pjax/blob/master/jquery.pjax.js#L175-177

⚡️

@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Apr 2, 2011

No worries. They're listed in the readme of History.js, here is the extract:

  • History.js solves the following browser bugs:
    • HTML5 Browsers
      • Chrome 8 sometimes does not contain the correct state data when traversing back to the initial state
      • Safari 5, Safari iOS 4 and Firefox 3 and 4 do not fire the onhashchange event when the page is loaded with a hash
      • Safari 5 and Safari iOS 4 do not fire the onpopstate event when the hash has changed unlike the other browsers
      • Safari 5 and Safari iOS 4 fail to return to the correct state once a hash is replaced by a replaceState call / bug report
      • Safari 5 and Safari iOS 4 sometimes fail to apply the state change under busy conditions / bug report
      • Google Chrome 8,9,10 and Firefox 4 prior to the RC will always fire onpopstate once the page has loaded / change recommendation
      • Safari iOS 4.0, 4.1, 4.2 have a working HTML5 History API - although the actual back buttons of the browsers do not work, therefore we treat them as HTML4 browsers
      • None of the HTML5 browsers actually utilise the title argument to the pushState and replaceState calls
    • HTML4 Browsers
      • Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event
      • MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
      • Non-Opera HTML4 browsers sometimes do not apply the hash when the hash is not urlencoded
    • All Browsers
      • State data and titles do not persist once the site is left and then returned (includes page refreshes)
      • State titles are never applied to the document.title

:) for the HTML4 support, History.js provides an optional hash fallback which still allows for data and titles (even replaceState) etc. While I agree that hashes aren't ideal, some people do enjoy them - hence why they're optional :)

balupton commented Apr 2, 2011

No worries. They're listed in the readme of History.js, here is the extract:

  • History.js solves the following browser bugs:
    • HTML5 Browsers
      • Chrome 8 sometimes does not contain the correct state data when traversing back to the initial state
      • Safari 5, Safari iOS 4 and Firefox 3 and 4 do not fire the onhashchange event when the page is loaded with a hash
      • Safari 5 and Safari iOS 4 do not fire the onpopstate event when the hash has changed unlike the other browsers
      • Safari 5 and Safari iOS 4 fail to return to the correct state once a hash is replaced by a replaceState call / bug report
      • Safari 5 and Safari iOS 4 sometimes fail to apply the state change under busy conditions / bug report
      • Google Chrome 8,9,10 and Firefox 4 prior to the RC will always fire onpopstate once the page has loaded / change recommendation
      • Safari iOS 4.0, 4.1, 4.2 have a working HTML5 History API - although the actual back buttons of the browsers do not work, therefore we treat them as HTML4 browsers
      • None of the HTML5 browsers actually utilise the title argument to the pushState and replaceState calls
    • HTML4 Browsers
      • Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event
      • MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
      • Non-Opera HTML4 browsers sometimes do not apply the hash when the hash is not urlencoded
    • All Browsers
      • State data and titles do not persist once the site is left and then returned (includes page refreshes)
      • State titles are never applied to the document.title

:) for the HTML4 support, History.js provides an optional hash fallback which still allows for data and titles (even replaceState) etc. While I agree that hashes aren't ideal, some people do enjoy them - hence why they're optional :)

@staabm

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Apr 10, 2011

Contributor

Don't know if History.js is the lib of choice, but a crossbrowser (and non html5) fallback would be great for pjax...

Contributor

staabm commented Apr 10, 2011

Don't know if History.js is the lib of choice, but a crossbrowser (and non html5) fallback would be great for pjax...

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 10, 2011

I'm 👍 on this. I'd much rather see a hash in the url than suffer through the slowish page loads. Of course it means you also have to read the hash content on a page load, which is more work than when you just use pushState.

Seldaek commented Apr 10, 2011

I'm 👍 on this. I'd much rather see a hash in the url than suffer through the slowish page loads. Of course it means you also have to read the hash content on a page load, which is more work than when you just use pushState.

@benjamine

This comment has been minimized.

Show comment
Hide comment
@benjamine

benjamine Apr 11, 2011

hi, I've written in the past something similar to pjax, and face this problem

  • Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event

The best solution I found is a jquery plugin to provide cross-browser hashchange event (in older browsers it uses polling):
http://benalman.com/projects/jquery-hashchange-plugin/

hi, I've written in the past something similar to pjax, and face this problem

  • Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event

The best solution I found is a jquery plugin to provide cross-browser hashchange event (in older browsers it uses polling):
http://benalman.com/projects/jquery-hashchange-plugin/

@defunkt

This comment has been minimized.

Show comment
Hide comment
@defunkt

defunkt Apr 11, 2011

Owner

We're not going to support browsers without pushState, but feel free to fork and roll your own ;)

Owner

defunkt commented Apr 11, 2011

We're not going to support browsers without pushState, but feel free to fork and roll your own ;)

@defunkt defunkt closed this Apr 11, 2011

@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Apr 14, 2011

@defunkt this isn't just about browsers without pushState but browsers with pushState. Using History.js will allow you to support Safari and iOS devices as well. Google Chrome will also fire a onpopstate event at the state, where Firefox 4 and Safari don't. Also the data param never persists if the browser session was closed. These are solved with History.js and you don't need to include the history.html4.js for HTML4 support if you don't want to. But if you do, then it will all work find and good too.

@defunkt this isn't just about browsers without pushState but browsers with pushState. Using History.js will allow you to support Safari and iOS devices as well. Google Chrome will also fire a onpopstate event at the state, where Firefox 4 and Safari don't. Also the data param never persists if the browser session was closed. These are solved with History.js and you don't need to include the history.html4.js for HTML4 support if you don't want to. But if you do, then it will all work find and good too.

@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Jun 11, 2011

@defunkt, counter-argument? Does GitHub not actually care about the bugs between the browsers which actually do support the HTML5 History API? and/or providing the rich experience to HTML4 users too?

@defunkt, counter-argument? Does GitHub not actually care about the bugs between the browsers which actually do support the HTML5 History API? and/or providing the rich experience to HTML4 users too?

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Jun 12, 2011

@balupton, counter-counter-argument: Falling back to URL fragments for HTML4 users breaks the Internet.

They break referrers, they break search engines, they break URL shorteners, they break shared links, and they saddle websites with an enormous amount of technical debt: once you support hash-bang or onhashchange URLs, you have to include a Javascript hash handler on the root page of your domain forever.

Or at least as long as you want all the old links pointing to your site to work.

Which should be forever.

👍 on working around cross-browser issues with HTML5 History API.

👎 on providing any sort of history support for HTML4 browsers.

@balupton, counter-counter-argument: Falling back to URL fragments for HTML4 users breaks the Internet.

They break referrers, they break search engines, they break URL shorteners, they break shared links, and they saddle websites with an enormous amount of technical debt: once you support hash-bang or onhashchange URLs, you have to include a Javascript hash handler on the root page of your domain forever.

Or at least as long as you want all the old links pointing to your site to work.

Which should be forever.

👍 on working around cross-browser issues with HTML5 History API.

👎 on providing any sort of history support for HTML4 browsers.

@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Jun 12, 2011

Thanks, and I agree - that is why the hash fallback in history.js is optional (and discouraged) but some users still want that (mostly the ones building closed to the public apps)

Thanks, and I agree - that is why the hash fallback in history.js is optional (and discouraged) but some users still want that (mostly the ones building closed to the public apps)

@defunkt

This comment has been minimized.

Show comment
Hide comment
Owner

defunkt commented Jun 12, 2011

❤️ @bobthecow

@balupton

This comment has been minimized.

Show comment
Hide comment
@balupton

balupton Jun 12, 2011

okay.... so @defunkt you are for including History.js for working around cross-browser issues with HTML5 History API, and without the HTML4 support?....

okay.... so @defunkt you are for including History.js for working around cross-browser issues with HTML5 History API, and without the HTML4 support?....

@defunkt

This comment has been minimized.

Show comment
Hide comment
@defunkt

defunkt Jun 12, 2011

Owner

pjax, as a design goal, is for browsers that support pushState. That's the p in pjax. I understand that some people want to target browsers which don't support pushState, but those people don't have to use pjax. Mostly I've been recommending History.js to anyone who wants something outside the scope of pjax, and I will continue doing that in the future.

As for browser bugs, pjax already has some fixes for buggy pushState implementations, and I'd be quite happy to merge/add more as they pop up. ⚡️ I know there's one pending pull request (#30) with a fix I haven't yet tested and merged.

Owner

defunkt commented Jun 12, 2011

pjax, as a design goal, is for browsers that support pushState. That's the p in pjax. I understand that some people want to target browsers which don't support pushState, but those people don't have to use pjax. Mostly I've been recommending History.js to anyone who wants something outside the scope of pjax, and I will continue doing that in the future.

As for browser bugs, pjax already has some fixes for buggy pushState implementations, and I'd be quite happy to merge/add more as they pop up. ⚡️ I know there's one pending pull request (#30) with a fix I haven't yet tested and merged.

@ckald

This comment has been minimized.

Show comment
Hide comment
@ckald

ckald Jul 9, 2011

@bobthecow is really right. but i needed hash support, i added it. https://github.com/ckald/jquery-pjax/

ckald commented Jul 9, 2011

@bobthecow is really right. but i needed hash support, i added it. https://github.com/ckald/jquery-pjax/

@DogKnob

This comment has been minimized.

Show comment
Hide comment
@DogKnob

DogKnob Feb 15, 2012

@ckald: when I tried to use your merge of hashchange-event and pjax, I got this error in IE9 saying that .pjax is not a method. When I used the regular version of pjax, I did not get the error.

This is how I'm calling pjax (using jquery 1.7.1): $("a[href^='"+siteURL+"']:not([href_='/wp-admin/']):not([href_='/wp-login.php']):not([href$='/feed/'])").pjax("#primary");

DogKnob commented Feb 15, 2012

@ckald: when I tried to use your merge of hashchange-event and pjax, I got this error in IE9 saying that .pjax is not a method. When I used the regular version of pjax, I did not get the error.

This is how I'm calling pjax (using jquery 1.7.1): $("a[href^='"+siteURL+"']:not([href_='/wp-admin/']):not([href_='/wp-login.php']):not([href$='/feed/'])").pjax("#primary");

@ckald

This comment has been minimized.

Show comment
Hide comment
@ckald

ckald Feb 15, 2012

@DogKnob as I remember, nobody didn't have problems with this. Leave an issue on https://github.com/ckald/jquery-pjax/ with a proof link please to continue discussion

ckald commented Feb 15, 2012

@DogKnob as I remember, nobody didn't have problems with this. Leave an issue on https://github.com/ckald/jquery-pjax/ with a proof link please to continue discussion

@DogKnob

This comment has been minimized.

Show comment
Hide comment
@DogKnob

DogKnob Feb 16, 2012

@ckald: I did manage to get this working somewhat. I no longer get the error, but I'm having IE-specific issues with Wordpress now :(

DogKnob commented Feb 16, 2012

@ckald: I did manage to get this working somewhat. I no longer get the error, but I'm having IE-specific issues with Wordpress now :(

@ckald

This comment has been minimized.

Show comment
Hide comment
@ckald

ckald Feb 16, 2012

@DogKnob Hey, i think defunkt doesn't wants us talking here not about his lib. Personally i won't flood here anymore. https://github.com/ckald/jquery-pjax

ckald commented Feb 16, 2012

@DogKnob Hey, i think defunkt doesn't wants us talking here not about his lib. Personally i won't flood here anymore. https://github.com/ckald/jquery-pjax

@kim3er

This comment has been minimized.

Show comment
Hide comment
@kim3er

kim3er Feb 19, 2013

Contributor

Just as a point of interest. I needed PJAX to work in IE9 specifically, so I simply included this https://github.com/devote/HTML5-History-API in the page. So far seems to be working a treat.

Contributor

kim3er commented Feb 19, 2013

Just as a point of interest. I needed PJAX to work in IE9 specifically, so I simply included this https://github.com/devote/HTML5-History-API in the page. So far seems to be working a treat.

@josh

This comment has been minimized.

Show comment
Hide comment
@josh

josh Feb 19, 2013

Contributor

@kim3er sorry pjax isn't going to target IE9.

Contributor

josh commented Feb 19, 2013

@kim3er sorry pjax isn't going to target IE9.

@kim3er

This comment has been minimized.

Show comment
Hide comment
@kim3er

kim3er Feb 19, 2013

Contributor

No interest in PJAX adding support for IE9, I believe you're entirely correct not to. My last comment was purely informational for people wanting provide backwards compatibility easily. Rich

Contributor

kim3er commented Feb 19, 2013

No interest in PJAX adding support for IE9, I believe you're entirely correct not to. My last comment was purely informational for people wanting provide backwards compatibility easily. Rich

@clime

This comment has been minimized.

Show comment
Hide comment
@clime

clime Aug 5, 2013

kim3er: no pjax customization was needed? oO

clime commented Aug 5, 2013

kim3er: no pjax customization was needed? oO

@kim3er

This comment has been minimized.

Show comment
Hide comment
@kim3er

kim3er Aug 5, 2013

Contributor

No customisation, I just added the script in a conditional statement before PJAX.

<!--[if lte IE 9]>
    <script src="/assets/history/history.iegte8-2ba4e7bd41fb9ab66b39900f904d6e4a.js" type="text/javascript"></script>
<![endif]-->

It's not perfect (neither is PJAX), but it's pretty good.

Contributor

kim3er commented Aug 5, 2013

No customisation, I just added the script in a conditional statement before PJAX.

<!--[if lte IE 9]>
    <script src="/assets/history/history.iegte8-2ba4e7bd41fb9ab66b39900f904d6e4a.js" type="text/javascript"></script>
<![endif]-->

It's not perfect (neither is PJAX), but it's pretty good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment