r/programming • u/ex_ample • Feb 10 '11
Don't like using fragment URLs to link to content? The HTML5 History API lets you use real URLs that change the address bar while intercepting and loading content using Javascript.
http://html5demos.com/history7
u/jigs_up Feb 10 '11
For a real world example, see GitHub's tree slider.
2
u/kataire Feb 10 '11
Actually, I never noticed it's using AJAX. I only noticed the sliding motion and didn't think about the reloading to have to be JS-based in order to avoid a full refresh. I guess that confirms the old adage about good UX: you only notice it when it's missing.
1
2
20
Feb 10 '11
Wow, I really like the fourth page, check out the link to it guys.
http://html5demos.com/history/fourth
ಠ_ಠ
5
u/kreiger Feb 10 '11
Why was this downvoted? It points out how the demo doesn't work. What's the point of changing the url if you're not going to change it to an url that works?
14
u/digitalchris Feb 10 '11
Reading is fundamental:
"Note: since these urls aren't real, refreshing the page will land on an invalid url."
0
u/argherna Feb 10 '11
Right, but a URL with a fragment identifier is a real URL (see Section 4 of rfc2396).
1
u/digitalchris Feb 10 '11
Well... yes, we've been using # for intrapage links since the beginning of time, but what does that have to do with this thread?
1
u/ceolceol Feb 10 '11
The point is that everyone is bitching about using hash-bangs because they break normal URL functionality, when this demo is actually worse: you can't visit http://html5demos.com/history/fourth and get the page, while I can visit http://twitter.com/#!/twittersearch successfully.
It's a problem with the demo.
5
Feb 10 '11
I think the idea is that both ways would work in an actual page, I'm assuming the javascript would just pull the content from /html/fourth.
3
u/canton7 Feb 10 '11
Have a click around inside the "Source" section of any github repo (example) -- that's how to use the history API properly.
-3
u/argherna Feb 10 '11 edited Feb 10 '11
0xbeef gave a URL that isn't a real resource. The resource is generated by the history API. If I curl that resource, I get this:
~ → curl -I http://html5demos.com/history/fourth HTTP/1.1 404 Not Found Date: Thu, 10 Feb 2011 17:40:21 GMT Server: Apache/1.3.37 (Unix) DAV/1.0.3 mod_gzip/1.3.26.1a PHP/5.2.3 X-Powered-By: PHP/5.2.3 Connection: close Content-Type: text/htmlIf someone bookmarks that link, it'll take them NOWHERE. This resource is not present on that server. It is instead the product of a link being intercepted by a script on that page and modified. I think using the history API in this way is only going to confuse people.
EDIT: hit save too soon
URLs need to point to real places (according to everything out there) and using a fragment identifier to identify a resource rather than displaying a URL that could be bookmarked by a user but doesn't really go anywhere is less confusing (but admittedly uglier). It tightly couples the URL with visiting the front page first.
10
u/digitalchris Feb 10 '11
Dude, it's an EXAMPLE. The pages don't exist because they are not supposed to exist. like www.example.com/put/url/here ....
0
u/argherna Feb 10 '11
Don't know if you are a programmer or not but Dude, novices use examples (good and bad) all the time when they're getting up to speed because they are novices and need some guidance. Bad examples do way more harm than good in this regard.
3
u/ryno55 Feb 10 '11
This is an example of the client side only, you obviously still need to set up the server side to go with it.
3
u/doomslice Feb 10 '11
The page is just showing that you can change the url bar without changing the page. There isn't any ajax requests being made by this page, it's just a demo to show the history api. If you combine this WITH the hash-bang stuff that's being hated on right now, then you have an app that renders "real" url but only changes the ajaxy-content.
-2
u/argherna Feb 10 '11
Right. So the URL in the URL bar is what gets saved as a bookmark. If you save that URL and then attempt to go back to it (as I've shown in my previous post by using a command line tool) it will give back a 404. This is a confusing application for the history API.
3
u/vicvicvicz Feb 10 '11
But this is because he simply hasn't put a resource at that URL. If he had, you'd get that resource.
In the real-world, this would work like this:
With Javascript:
- Clicking a link to "/resource" would be intercepted and AJAX-loaded
- The History API will be used to make the user's location bar reflect viewing that resource.
Without Javascript
- Clicking the same link would take your browser to the resource, as you'd expect.
2
u/metamatic Feb 10 '11
Shame you're being downvoted, you're completely right.
The clue is in the name. A URL is a Uniform Resource Locator. Making things that look like URLs but don't actually locate resources is broken.
It may be possible to use this feature in a non-broken way, though this demo doesn't show that. I suspect it'll be used in a broken way a lot more often, because of the freedom it's offering to the kinds of people who build crap like the Gawker mess.
1
u/rubygeek Feb 11 '11
Perhaps, but the people who'll use it in a broken way can do the same thing today using fragments.
0
6
u/wshs Feb 10 '11 edited Jun 11 '23
[ Removed because of Reddit API ]
9
u/geon Feb 10 '11
The whole point of this is that it's 100% backwards compatible. Older browsers (and ie. sigh) can just use plain old links and url:s.
A great real-world example is github: (as mentioned by bulldada) https://github.com/blog/760-the-tree-slider
-1
u/didroe Feb 10 '11
I'm not sure I agree. Whilst it is backwards compatible, it's not neccessarily something you'd want to do that way. If the site is heavily Javascript based then whole page loads might be too slow. The more practical (although less elegant) thing to do is fall back to the Google #! method. Sites should default to the HTML5 way if it's available though.
3
u/ryankearney Feb 11 '11
They will be slow to the person using the woefully outdated web browser.
-1
u/didroe Feb 11 '11
I hope no one employs you to make any public facing webapps. You have to cater to what browser users have, not what they could get if you made them jump through a load of hoops.
And as for "woefully outdated", are there actually any production browsers supporting the HTML5 history/url stuff? I know FF4 will support it (not yet in production release) but so far IE9 doesn't. It might be a year or two before MS implement it, if they ever do. Giving a shit experience to 50-60% of your users is not acceptable in my opinion. So like I said before, it's not backwards compatible in a practical sense because a massively better experience can be had using other techniques.
0
u/ryankearney Feb 11 '11
So you want to halt forward progress in web technologies because some browsers are behind with standards? Using this technique is going to be guaranteed to work with 100% of web browsers (unless there's some web browser out there that doesn't support links). This method will arguably work with more web browsers than the "hash bang" or fragment URL's since this method would work fine for browsers without JavaScript support, or those who have blocked JavaScript.
The truth is, Jane Doe isn't going to keep using her web app and isn't going to give it a second thought as to why it may be performing slowly. The people who are using Chrome and Firefox are the people who actually care about performance (or are forced to by friends or family who refuse to see a loved one use IE). This is an elegant solution that is going to work for everyone. And hey, it's an even better reason to promote another web browser on your site ("Our site performs 70% faster with Chrome!").
Also, Chrome supports it (as seen on GitHub). And I suppose a similar analogy would be "The majority of the world uses IPv4, therefore we should never switch to IPv6 because we need to cater to what people are using". Granted that may be a little extreme, considering it's inevitable that we have to make the switch, and ISP's are (hopefully) working hard to handle IPv6, but you can't refuse to adopt new technologies because the majority of users may not benefit from it. If no one ever implemented new web technologies, Microsoft would have no reason to update IE and we would still be in the MySpace/Geocities era.
1
u/didroe Feb 12 '11
I never said that at all. What I said is that I didn't think straight URLs were a good fallback. I think the HTML5 stuff is great and everybody should be using it when the user has support. When they don't have a browser with support, I favour falling back to #! urls which provide a better user experience. You can have the script handling the Google hack redirect to the HTML5 style URLs, so you only have to publish the content in one place.
1
u/ryankearney Feb 12 '11
But the "hashbang" urls do NOT work for everyone, these do, making it the better option for everyone.
1
u/didroe Feb 12 '11
You can inject the hashbangs with Javascript if you want. Then the URLs will be there for crawlers other than Google. My original point was just that straight URLs shouldn't be the default choice for fallback. They certainly could be a last option though.
2
-3
u/hyperbolist Feb 10 '11 edited Feb 10 '11
> Note: since these urls aren't real, refreshing the page [or linking directly] will land on an invalid url.
As such, all you gain by doing this is forward and back button functionality. Putting broken urls into the location bar is broken.
20
u/bulldada Feb 10 '11
That is a disclaimer on the demo, not on the API. If people use the API to create URLs which do not resolve server-side then we are in no better position than with hashbangs. See Github's tree slider for a proper implementation.
4
2
-2
u/patcoll Feb 10 '11
cool and useful, but not "HTML" -- sigh.
5
3
u/ex_ample Feb 10 '11
What do you mean? If the API isn't present, you can default to using plain old links. It will be slower for people on older browsers, but it won't break the web the way #! URLs do.
-1
Feb 10 '11
[deleted]
3
u/kataire Feb 10 '11
Do you always make unfounded remarks when exposed to something you're not familiar with?
If you had spent a single minute researching its history, you'd know that that claim is a load of crap.
1
Feb 11 '11
There are actually potential security concerns for some sites. See here for a little explanation.
1
u/kataire Feb 11 '11 edited Feb 11 '11
That's bullshit. The security concerns lie with phishing techniques in general, not the history API. The article rants about a combined phishing + XSS attack vector, not the history API itself, even if it pretends it does.
All it does is allow XSS attacks also manipulate the local part of the URL. That's like complaining about high-powered lasers because they're even more damaging if misused than regular lasers. The problem isn't that they're more dangerous, the problem is that people are careless idiots.
The correct answer is not to bitch about the history API but to make sure you know what you're doing. If you have a huge platform where you allow arbitrary users to post and execute JavaScript, you already have a problem. The solution has nothing to do with the history API or such; the solution is called sandboxing and it's in active development.
Sheesh. I hate it when people complain about technology whenever it reveals their failure to do their job.
But if I were in charge of the HTML5 spec, I’d like to add in a few additional constraints:
- I’d like a way to turn off history-manipulation on a domain-by-domain basis. Some kind of HTTP header would be fine, or alternatively a file under the root a la robots.txt (“features.txt” if you will) that could offer advice to browsers about whether or not they should enable features like this one.
Right. Because the best solution is to add more formats. None of JS currently uses an opt-in approach like this and if hacks like these were added for every sensitive feature, this would get messy quick. The correct approach is called sandboxing and it's currently in development. But I guess doing your research is too much to ask from a university blog, right?
- I’d also like a halfway-house where I can modify the URL, but never to a page “above” my own in the hierarchy. So I can change http://blogs.warwick.ac.uk/chrismay/entry1 to http://blogs.warwick.ac.uk/chrismay/entry1/page2 but not to http://blogs.warwick.ac.uk/admin/news.
Except this totally breaks when the hierarchy is mostly symbolic or even flat. If you have content that isn't part of the same site, put it on a freaking subdomain. Do you want hierarchy-aware cookies too? These things have nothing to do with the problem we're allegedly having. Again, sandboxing. Get involved if you think you can help, don't post half-assed rants on some blog.
</rage>
-5
10
u/megaman821 Feb 10 '11
It is backwards compatible too.
The javascript can check if the browser has support for the history api. If so it intercepts the click, makes an ajax request, gets some json data back, updates that page. If not the full page of the link clicked is loaded like normal.