2011/2/10 Björn Söderqvist <[email protected]>: > Actually, Google seems to have a way to translate the hashbang into > something more meaningful. > > "As soon as you use the hashbang in a URL, Google will spot that > you're following their protocol, and interpret your URLs in a special > way - they'll take everything after the hashbang, and pass it to the > site as a URL parameter instead. The name they use for the parameter > is: _escaped_fragment_" > > http://www.seomoz.org/blog/how-to-allow-google-to-crawl-ajax-content
There are still several problems with this, though. It requires the implementer to forego more human-friendly progressive enhancement techniques in favor of a non-standard _escaped_fragment_ query parameter, which currently only benefits the GoogleBot. It breaks referrer URLs. It adds significant latency to the initial request to a bookmarked # URL, since JavaScript (and probably more requests) must execute before content can be displayed. It doesn't work at all if JavaScript is disabled, or if the script fails to load. Hash-based history is perfectly acceptable (and advisable) for minor functionality like keeping track of the active tab in a JavaScript-enhanced tab widget, or which label is currently being viewed in Gmail, or similar things. It's not a good solution as the primary navigation handler of an entire content-focused website. HTML5 pushState is a much better alternative that allows JavaScript apps to change the URL in a way that's backwards compatible (if implemented correctly), so the generated URLs can be used regardless of whether the client supports JavaScript. They don't have the same latency penalty as hash URLs, since content can be generated on the server for the initial request. They will also be indexable by all search crawlers instead of just the GoogleBot. They're correctly passed as referrer URLs. And they look and behave like perfectly normal URLs that users are used to, because that's exactly what they are. The major drawback of pushState, of course, is a lack of broad browser support. No version of IE supports pushState (not even IE9). Some browsers (like Mobile Safari) have buggy support. Since pushState inherently encourages progressive enhancement, it's possible to gracefully degrade to non-JS handling of URLs for those browsers, but it requires careful planning and application design. Hash-based history is better than no history support at all, but it's the laziest solution there is. - Ryan -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
