
HTML5: Changing the browser-URL without refreshing page - twampss
http://www.spoiledmilk.dk/blog/?p=1922
======
MikeW
What about all the services offering provider.com/~username.

Scrolling status bars used to be all the range in the 90s, I wonder how long
until url hacks allow for scrolling address bars with this.

~~~
johnswamps
Here you go. Copy paste into your url bar. Only tested in Chrome (edit:
apparently also works in safari 5)

javascript:var dashes = ""; var num = 20; while(--num) dashes += "-";
setInterval(function() { window.history.pushState("", "", dashes.slice(0, num
% 20) + "foo" + dashes.slice(num % 20)); num++;}, 500)

~~~
kristofferR
Damn, that is annoying! It totally screws up the back button functionality in
Safari:

<http://imgur.com/41rrV.png>

~~~
sorbus
That's sort of the point, isn't it? As it's continuously changing the URL ...
I could see this used to make it difficult or impossible for people to leave
sites, except by closing the window.

~~~
mrkurt
Haha, indeed! (Don't click this if you care about your history)
<http://kurtly.tumblr.com/sticky-history>

------
colinprince
Can this be abused? Loading a page in a tab, I may not notice the URL changing
from wickedsite.com to mybanksite.com, all without a reload.

~~~
pepijndevos
I don't think you can change the root domain, but I'll have to check that.

~~~
j79
You're correct. Only the path (and not the domain) can be changed.

From the article:

* For security reasons, you can only change the path of the URL, not the domain itself. So you can change anything in the URL after my-domain.com/[change-the-stuff-here.html].

~~~
d4rt
wouldn't this be better if you could only go to the same level or lower, thus
preventing server/~user1 pretending to be server/~user2?

does this break real use cases?

~~~
Groxx
It very well could. Consider that "real use cases" includes _every_ website in
existence. Some of the have utterly horrifying URL schemes.

~~~
wanderr
It's not just horrifying URL schemes, it would make the feature useless for
any "web app" - take Grooveshark for example. A user can go from
/artist/x/1234 to /song/x/1234 which seems pretty reasonable and not very
horrifying.

~~~
mseebach
As long as the script-file lives at / there's no problem..

------
fortes
I'm happy to see this is going to be implemented by the browsers of the
future. I've started a project to port the API to older browsers:

<http://github.com/fortes/history.js>

Patches welcome!

------
korch
This is the greatest html5 feature I've never heard of, and it's really going
to change how everybody make web apps.

Here's my wild prediction: 10 years from now, with the benefit of hindsight,
we will trace the moment where Google's Page Rank empire started to crumble to
the introduction of this html5 feature.

However, discovering this makes me wonder what other incredibly useful but as
yet unknown html5 features are out there in the wild?

~~~
gojomo
How does this feature make much difference to Page Rank (or the many other
ranking factors now as important or moreso for Google)?

~~~
korch
By decoupling urls in the browser from urls in the web app, it's only going to
increase the amount of content in the _Deep Web_ that Google can't index. I
imagine it'll be difficult to make GoogleBot crawl and index "pages" after
large swaths of the web are using this. And once this Javascript feature is in
jQuery, then we can expect a huge number of web developers to start using it
by default.

I don't know how much Javascript the GoogleBot currently parses and/or
executes, but I imagine it would be enormously complex to embed v8 into the
crawler, and then execute all Javascript on every page and determine what to
index on a "page." If we ever get to the point where you can't screen scrape a
web app without also executing its Javascript, then PageRank-like methods
become less effective, and we'll need more semantic approaches to search. It's
a great thing such semantic approaches don't yet exist!

~~~
gojomo
Some Google crawls already execute Javascript; they could easily do so more
extensively if that were the only way to reach valuable content.

Also, Google is already promoting a convention for making the various parts of
an AJAX application reachable via different URL-#fragments more easily
crawlable. See:

[http://www.google.com/support/webmasters/bin/answer.py?hl=en...](http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=174992)

A number of sites including Facebook have adopted this convention; app
developers usually want to be found by search engines.

~~~
korch
Microsoft for one would love to have a big chunk of Internet real estate that
couldn't be found and indexed by Google.

It's funny you mention Facebook. I would say Facebook's chief motive right now
is to stop Google from encroaching upon their territory, so Facebook wants to
put up as many speed-bumps as possible around Google. Basically that means
keeping Google sandboxed—it's okay to let Google index anything they want and
throw that up on an ordered SERP, but no way can we let them grow elaborate
ivy APIs and web-based UIs around our walled-garden of user generated content.
(i.e. Buzz.)

Given Microsoft's ownership and early partnering with Facebook, Microsoft and
Facebook have aligned interests in keeping Google in the sandbox.

