Jump to content

Recommended Posts

Hmm well looking at the support it seems that it is the thing for the future and is supported by most of the latest browsers. Wouldn't you recommend implementing it now rather than later? I mean the only two that don't support it are mobile versions which currently I don't aim to directly support anyway. What are your thoughts on this?

 

And a note, brilliant website there! Never used it before - extremely useful thanks!

If you don't mind programming a fall-back, or simply abandoning support for IE9 users I don't see a problem with implementing pushState. It's really up to you - how much work you want to do and how accessible your site will be.

 

I personally don't bother with coding HTML5-specific behaviour because it's still in draft, and I will generally have to program fall-back functionality anyways. That's my preference though... I don't get paid to be on the bleeding edge of web standards, otherwise I probably would ;)

Chrome is now the most used browser, which updates automatically, so you could assume that the majority of users on the internet now have decent HTML5 support. Personally I would implement state, but hijack links/forms and provide non-JS/HTML5 fall-backs, instead of implementing it as the default action. The hardest part is getting your head around the state API, adding the fall back is easy. Although there's plug-ins and scripts around that make using the state API a doddle!

I think it's a good idea to put in fall backs. By "hijacking", I meant write the site as normal. Normal links, normal forms, etc. Then write some JS to literally hijack every link and form within the page to use your push state handle instead of the default action.

Don't think of it as fallbacks. Just write your site normally, then add some JS that will takeover the links/forms and alter the normal behaviour. Just be sure to detect if their browser supports push state first, so you're not hijacking links and then not updating the URL.

 

You could implement this as a nice, clean object. Call it "Page" for example. It would handle the generic loading of URLs through POST or GET requests (i.e. form submissions or just requesting a URL), and loading into the DOM. You could also add a method that allows you to define "page load behaviours", so as each page is loaded you loop through a set of callbacks that re-apply click binds and such -- this would probably be more efficient than using live() or on(), and would also keep the generic page logic separate from the individual, page specific behaviours.

 

You could implement it really nice, just try and keep away from lumping everything into one file and it all getting chaotic. Try and keep the logic separate, otherwise it will become harder and harder to maintain.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.