single page apps, URL hash setting, bookmarking, & the back button.

[Peter Michaux]

A couple years ago I remember discussing here the idea of a single
page application setting the URL hash as a means of allowing
bookmarking and the back button to work as "expected". Navigating
through a one page app, the user would see the URL change

http://example.com/#page1
http://example.com/#page2
http://example.com/#page3

JavaScript would change the hash part of the URL so the user could
bookmark any screen and return to it. Setting the hash adds to the
browsers history so the back button also works.

At the time of the discussion I think there were browsers that
refreshed the page when setting the URL hash. I believe Safari 1 or 2
might have been doing this. Perhaps Opera as well. I remember Yahoo!
maps was setting the URL hash and basically didn't work in some
browers. Google maps, on the other hand, had and still does have a
little "link" link that gives the user a permalink they can send to
others to show the same screen (map position, zoom, etc.)

At the time, I remember Richard Cornford pointed out that there is or
was no standard dictating whether or not the browser should refresh
when the hash is changed through JavaScript. The situation seems to
have stabilized and all the major browsers do not refresh when setting
the URL hash through JavaScript. A de facto standard behavior seems to
have emerged.

I now see that Gmail and Facebook are both using URL hash setting as a
means of managing one page applications. Considering these pages both
take long to load, using Ajax to update little bits of the screen
(even the whole middle of the screen) is snappier than a full page
load. (Perhaps good caching could make the snappy same result?)

With important/popular one-page apps using URL hash setting, it seems
like a technique that is probably here to stay.

Has anyone here worked on a big application using URL hash setting for
navigation management? Any gotcha's learned through experience working
on them?

 

[David Mark]

A couple years ago I remember discussing here the idea of a single
page application setting the URL hash as a means of allowing
bookmarking and the back button to work as "expected".

An execrable "Web 2.0" end-around if there ever was one. Do not use
Ajax for navigation.

Navigating

through a one page app, the user would see the URL change

http://example.com/#page1http://example.com/#page2http://example.com/#page3

This is what I'm talking about.

JavaScript would change the hash part of the URL so the user could
bookmark any screen and return to it. Setting the hash adds to the
browsers history so the back button also works.

It may appear to work in some cases, provided you check the current
location every split second and update the content to match.

At the time of the discussion I think there were browsers that
refreshed the page when setting the URL hash. I believe Safari 1 or 2
might have been doing this. Perhaps Opera as well. I remember Yahoo!
maps was setting the URL hash and basically didn't work in some
browers. Google maps, on the other hand, had and still does have a
little "link" link that gives the user a permalink they can send to
others to show the same screen (map position, zoom, etc.)

Much better, but how do I know they botched the implementation.

At the time, I remember Richard Cornford pointed out that there is or
was no standard dictating whether or not the browser should refresh
when the hash is changed through JavaScript. The situation seems to
have stabilized and all the major browsers do not refresh when setting
the URL hash through JavaScript. A de facto standard behavior seems to
have emerged.

Doesn't matter as you don't need it.

I now see that Gmail and Facebook are both using URL hash setting as a

Look at your sources. Nothing says backwards browser scripting
futility like those two sites.

means of managing one page applications. Considering these pages both
take long to load, using Ajax to update little bits of the screen
(even the whole middle of the screen) is snappier than a full page
load. (Perhaps good caching could make the snappy same result?)

There's nothing snappier than fast history navigation, which requires
no scripting at all (just the lack of unload listeners, which is sadly
rare these days.)

With important/popular one-page apps using URL hash setting, it seems
like a technique that is probably here to stay.

Look again. IIRC, both of those sites use jQuery (and that sure as
hell isn't here to stay.)

Has anyone here worked on a big application using URL hash setting for
navigation management? Any gotcha's learned through experience working
on them?

Yeah, I've untangled several such messes. The lesson is to use Ajax
only where it makes sense (excludes anything that would confuse or
break navigation.) In short, overlaid dialogs make sense (in some
cases), replacing the document content does not.

 

[Peter Michaux]

Yeah, I've untangled several such messes. The lesson is to use Ajax
only where it makes sense (excludes anything that would confuse or
break navigation.) In short, overlaid dialogs make sense (in some
cases), replacing the document content does not.

Well none of Facebook, GMail, or Yahoo! Maps falls into your later
option of "replacing the document content." Yes these single page apps
refresh the focal-point HTML of the page but not necessarily large
portions of the total page HTML. So I think these single page apps
fall into the grey-area category along with overlaid dialogs.

I know I definitely like the hash-setting approach for Yahoo! Maps. It
just makes perfect sense there, in my opinion, as the changes are
small and frequent. The changes to the page don't necessarily even
require anything new to be loaded from the server. I don't like the
Google Maps approach of having a permalink link that shows the user
the URL to email to friends. That is putting far too much burden of
knowledge on the user. Just making a bookmark is a pain that way.

I'm undecided whether or not the hash-setting approach is necessary or
beneficial overall in GMail or Facebook. Without changing to a frames-
based approach, using the hash-setting approach does save having to
reload the navigation and other constant HTML around the focal-point
HTML. In that sense, the hash-setting approach is much snappier.

Peter

 

[David Mark]

Well none of Facebook, GMail, or Yahoo! Maps falls into your later
option of "replacing the document content." Yes these single page apps
refresh the focal-point HTML of the page but not necessarily large
portions of the total page HTML. So I think these single page apps
fall into the grey-area category along with overlaid dialogs.

Then they should skip worrying about navigation (e.g. fantasy hashes.)

I know I definitely like the hash-setting approach for Yahoo! Maps. It
just makes perfect sense there, in my opinion, as the changes are
small and frequent. The changes to the page don't necessarily even
require anything new to be loaded from the server. I don't like the
Google Maps approach of having a permalink link that shows the user
the URL to email to friends. That is putting far too much burden of
knowledge on the user. Just making a bookmark is a pain that way.

If you want to be able to mail bookmarks, then you must design your
app appropriately. Sounds like Yahoo did not. For that matter, what
is wrong with a "Send link to a friend" button? Tack a query on the
end of the URI to indicate the state to the script and you are done.

I'm undecided whether or not the hash-setting approach is necessary or
beneficial overall in GMail or Facebook. Without changing to a frames-
based approach, using the hash-setting approach does save having to
reload the navigation and other constant HTML around the focal-point
HTML. In that sense, the hash-setting approach is much snappier.

Guaranteed the whole thing would be snappier if somebody had
scrutinized the design from the beginning.

 

[Peter Michaux]

Then they should skip worrying about navigation (e.g. fantasy hashes.)

I don't see how your conclusion follows. Being able to capture the
entire state of the page in a URL is handy for bookmarking.

If you want to be able to mail bookmarks, then you must design your
app appropriately. Sounds like Yahoo did not.

I don't see how you conclude that. The idea of using a hash-setting
approach makes it possible in all current browsers to email or
bookmark the URL in the browser's address bar and have it work. Yes
when Yahoo! Maps started with hash-setting they were using a feature
that didn't work in all major browsers but now that feature does work.

For that matter, what
is wrong with a "Send link to a friend" button?

Many people will email the URL in their browsers address bar.

Many people will not see the "permalink" link. It is tiny in Google
Maps and they should probably not use any more space to make it
bigger.

Many people who see the "permalink" link, will not know what it is,
how to use it, or will just throw their hands up in frustration that
"this is all too complicated!"

A "permalink" link doesn't work so well or intuitively with the
browser's "bookmark this page" feature. People will try to bookmark
the page and just think "this is broken" as it doesn't save the state
of the page.

Tack a query on the
end of the URI to indicate the state to the script and you are done.

Yes that is how it works to program it. That doesn't mean it works
well from the user's point of view or his understanding of how web
addresses work.

Guaranteed the whole thing would be snappier if somebody had
scrutinized the design from the beginning.

That is very vague. There isn't too much information there to which I
can reply.

In the case of something like Yahoo! Maps, if your only idea is just
to have a "permalink" link because hash-setting is non-standard, then
I think I'd choose hash-setting. The user experience with hash-setting
is far superior. The JavaScript required to implement it, even polling
the URL for changes, is almost negligibly small (< 100 lines) and not
slow. All the browsers are behaving well now. Big applications, which
have "pull" with browser makers depend on good hash-setting behavior
so that behavior now has too much web weight to change it.

We cannot be completely afraid of non-standard behavior. I think it is
fair to say we probably all depend on certain bits of non-standard,
but de facto standard, behavior. I use innerHTML, for example, and
think the ability to write browser scripts would be harmed
dramatically by removing innerHTML.

Peter

 

[David Mark]

I don't see how your conclusion follows. Being able to capture the
entire state of the page in a URL is handy for bookmarking.

But there are lots of ways to do that without breaking navigation.

I don't see how you conclude that. The idea of using a hash-setting
approach makes it possible in all current browsers to email or
bookmark the URL in the browser's address bar and have it work. Yes
when Yahoo! Maps started with hash-setting they were using a feature
that didn't work in all major browsers but now that feature does work.

I know they didn't need to do it at all. Browsers are great at
navigation and there is no need to tack on fantasy hashes to make
bookmarks work. On the contrary, bookmarks and email do just fine on
their own, provided they aren't interfered with by ill-advised
scripting techniques.

Many people will email the URL in their browsers address bar.

So what? The receiver will see whatever they see. Guaranteed it
would correspond exactly to what the sender saw if the site's
designers had thought about such issues from day one. What do you
think they are trying to avoid? I'd say the primary issue is that
their documents are weighted down by lots of large scripts.

Many people will not see the "permalink" link. It is tiny in Google
Maps and they should probably not use any more space to make it
bigger.

That's a generalization. Who knows what many people will see or not?
If Google made theirs tiny, that is their problem.

Many people who see the "permalink" link, will not know what it is,
how to use it, or will just throw their hands up in frustration that
"this is all too complicated!"

That's silly. For one, don't call it "permalink" (of all things.)
And there's plenty of people who couldn't copy the text of a URI or
understand why such an operation would be needed. You can't provide
users with something better than that?

A "permalink" link doesn't work so well or intuitively with the
browser's "bookmark this page" feature. People will try to bookmark
the page and just think "this is broken" as it doesn't save the state
of the page.

Not hardly. Bookmarks are for documents and it is very hard to break
that feature. The average user knows nothing about what "state"
should be saved with a bookmark.

Yes that is how it works to program it. That doesn't mean it works
well from the user's point of view or his understanding of how web
addresses work.

I know one thing, a button that says "Send to a Friend" should not
require the user to know anything about Web addresses. OTOH, copying
a URI from the address bar requires some basic knowledge in that area
(else how would they know what to copy?)

That is very vague. There isn't too much information there to which I
can reply.

Well, we can't go back in a time machine. I bet if I looked at either
of those sites, I could tell you exactly how I would rewrite them.
I'm a little busy with rewriting other things at the moment though.

In the case of something like Yahoo! Maps, if your only idea is just
to have a "permalink" link because hash-setting is non-standard, then

Forget the word "permalink" in this context. Virtually nobody in the
intended audience knows what it means.

I think I'd choose hash-setting. The user experience with hash-setting

Even a "permalink" button would be better than that, but of course,
there are more than two choices available. As mentioned, I wouldn't
do either one.

is far superior. The JavaScript required to implement it, even polling
the URL for changes, is almost negligibly small (< 100 lines) and not
slow. All the browsers are behaving well now. Big applications, which

"All the browsers?" Come on.

have "pull" with browser makers depend on good hash-setting behavior
so that behavior now has too much web weight to change it.

It's still a ridiculous thing to do.

We cannot be completely afraid of non-standard behavior. I think it is

It has nothing to do with standards. It's good design vs. bad. If
you find yourself cramming an entire application that looks like
multiple documents into one document, realize that bookmarking
functionality is going to be lost (barring bizarre workarounds.) Then
realize what a silly decision that was and make a different one.

fair to say we probably all depend on certain bits of non-standard,
but de facto standard, behavior. I use innerHTML, for example, and
think the ability to write browser scripts would be harmed
dramatically by removing innerHTML.

That's another story.

 

[Peter Michaux]

It has nothing to do with standards. It's good design vs. bad. If
you find yourself cramming an entire application that looks like
multiple documents into one document,

For example, Yahoo! Maps does not look like multiple documents in one
document. Yahoo! Maps looks like an application in a web browser. That
is not a problem in the design of Yahoo! Maps. It is a strength of the
Yahoo! Maps design.

The web is not just a collection of documents anymore. It is now a
collection of documents and applications. Some of the applications
would be terrible had they been implemented with the mindset of a
collection of documents.

realize that bookmarking functionality is going to be
lost (barring bizarre workarounds.)

I really cannot see what is bizarre about using the URL hash as a way
to indicate the state of a single-page web app.

The bookmarking functionality doesn't have to be lost. Using hash-
setting it can kept just fine in current versions of all the major
browser.

Peter

 

[David Mark]

Aha! So, the user should not expect bookmarking a single document to
preserve the state. Case closed.

[snip]

 

[Peter Michaux]

Aha!  So, the user should not expect bookmarking a single document to
preserve the state.

But I think the user *does* expect bookmarking to work. I'm a user. I
expect it to work.

Peter

 

[David Mark]

But I think the user *does* expect bookmarking to work. I'm a user. I
expect it to work.

They expect it to bookmark the page, not preserve *state*. Nobody
would. Not in the whole history of Web browsers has that ever
worked. It's just "Web2.0" script kiddie nonsense that does that and
it's never been prevalent enough to supplant previous expectations
about bookmark behavior.

 

[Thomas 'PointedEars' Lahn]

They expect it to bookmark the page, not preserve *state*. Nobody
would. Not in the whole history of Web browsers has that ever
worked. It's just "Web2.0" script kiddie nonsense that does that and
it's never been prevalent enough to supplant previous expectations
about bookmark behavior.

Apparently it's past time for a reality check:

<http://validator.w3.org/#validate_by_input>


PointedEars

 

[David Mark]

Apparently it's past time for a reality check:

<http://validator.w3.org/#validate_by_input>

Broken by design (try using the back button) and that site is a crock
anyway (what sort of reality check is that?)

 

[David Mark]

Apparently it's past time for a reality check:

<http://validator.w3.org/#validate_by_input>

Not to mention that they could have easily done that right as those
fragments are not fantasies. Do you understand how they screwed it
up?

Reality check indeed (for you.)

 

[Hamish Campbell]

Not to mention that they could have easily done that right as those
fragments are not fantasies.  Do you understand how they screwed it
up?

Reality check indeed (for you.)

I actually think this is a worthwhile discussion. Despite Davids
protestations, GMail and Facebook have demonstrated that the technical
hurdles can be overcome to use hash-linking with Ajax behaviors to
build highly interactive and usable websites.

For example:

Bookmarks are for documents and it is very hard
to break that feature. The average user knows
nothing about what "state" should be saved with a bookmark"
And..

They expect it to bookmark the page, not preserve *state*.
Nobody would. Not in the whole history of Web browsers
has that ever worked.

I disagree. If the state of the page has changed significantly then
users absolutely expect the bookmark to carry the state. Remember, not
a lot of users are even conscious of the URL or what it means.

Before DOM manipulation came along and made things complicated, the
intent of the URL was to return you to the same resource every time.
Nothing has really changed except that developers have started adding
lots of state changes within a single document. Providing equivalent
browser-friendly navigation manipulation has been slow to catch up,
but the point of this discussion is to talk about how, not to say
"just don't do".

But those arguments are not even a discussion for this group. There
are plenty of other groups who are much more attuned to the needs of
[non-expert] users then a JavaScript language group. The point is not
whether this is good usability or not (that decision will be made
elsewhere), but whether it can be implemented.

Btw, it seems odd that small players like Gmail and Facebook
successfully use it, and you (David) won't even entertain a discussion
on implementation. I suggest that they know more on the subject of how
people use their sites than you do.

 

[David Mark]

I actually think this is a worthwhile discussion. Despite Davids
protestations, GMail and Facebook have demonstrated that the technical
hurdles can be overcome to use hash-linking with Ajax behaviors to
build highly interactive and usable websites.

That sounds like a commercial. Guaranteed you don't have to change
the location for make a usable slideshow.

Did you see the best example Thomas could come up with? Do you
understand how it illustrates how few people know enough to accomplish
this particular enhancement (without breaking the browser?) And that
was a much simpler example as they didn't even use script to change
the location (just to switch the tabs.) That should pretty much close
the book on this.

For example:


I disagree. If the state of the page has changed significantly then
users absolutely expect the bookmark to carry the state.

LOL. Then there are a lot of disappointed users out there as
bookmarks do no such thing. Never have. Thomas' (bad) example is
just three document fragments that have been rearranged with script to
look like a tabbed dialog. That's not state.

And state is (and always has been) persisted with cookies (and
sometimes SQL these days), not made-up hashes.

Remember, not
a lot of users are even conscious of the URL or what it means.

Again, that's my point. So why are you worrying about creating an
illusion for users with no expectations to begin with. If you think
about it, you are creating an illusion for other Web developers (the
illusion that you are "cool" enough to do tricks like this.) As
illustrated, even with a simplified example, the crack W3C developers
blew it.

Before DOM manipulation came along and made things complicated, the
intent of the URL was to return you to the same resource every time.

That has no meaning.

Nothing has really changed except that developers have started adding
lots of state changes within a single document.

That's not new. It started with IE4. BTW, I was there.

Providing equivalent
browser-friendly navigation manipulation has been slow to catch up,

Wrong. Navigation is as it has always been. Just as with popup
windows, there are lots of incompetent developers out there trying to
muck it up.

but the point of this discussion is to talk about how, not to say
"just don't do".

Wrong. This is a fundamental design error. Do not do it under any
circumstances. If you can't understand why at this point, you really
need to think about what you are doing.

But those arguments are not even a discussion for this group.

They aren't really arguments at all.

There
are plenty of other groups who are much more attuned to the needs of
[non-expert] users then a JavaScript language group. The point is not
whether this is good usability or not (that decision will be made
elsewhere), but whether it can be implemented.

It's just stupid. Usability is often compromised, but that is just a
side effect.

Btw, it seems odd that small players like Gmail and Facebook
successfully use it, and you (David) won't even entertain a discussion
on implementation. I suggest that they know more on the subject of how
people use their sites than you do.

You couldn't be more wrong (on all counts.) How many Web developers
on the planet know the first thing about progressive enhancement? And
who wrote the proverbial book on it?

I suggest that Google's JS developers are completely clueless, even
about basic accessibility issues. Go to their "My Account" page and
see how their menu reads without images. Then click "Adsense" and
notice that the back button breaks. Doesn't get any more basic than
that (and that's just the tip of the iceberg.)

And Facebook is no better. I can't believe I'm hearing this argument
about names again. See how Thomas got burned by assuming the W3C
developers had a clue? Now you want to use Facebook as an example?
And do you really think that they asked their users if they wanted a #$
%@! slide show to disrupt their browsing history? Most of the users
would have said: huh?

I'll tell you this, if I navigated to one of their documents with a
slide show, flipped through a dozen slides and had to hit back 13
times to get back where I was in the first place, I'd delete all
bookmarks to the site immediately. I have little doubt that most
users would feel the same way, but were not asked to articulate their
position to Facebook's incompetent Web designers.

Again, if you see lots of Web designers/developers doing something
(especially on large sites); it's probably the wrong thing. It's not
a new theory and seems to hold true every time. Is it news that most
Web developers are completely incompetent, even without scripting?
What chance do they have to make a correct decision *with* scripting?

 

[Hamish Campbell]

Again, that's my point. So why are you worrying about creating an
illusion for users with no expectations to begin with. If you think
about it, you are creating an illusion for other Web developers (the
illusion that you are "cool" enough to do tricks like this.) As
illustrated, even with a simplified example, the crack W3C developers
blew it.

I see where you're coming from, but I wonder - I got an email today
for a conference that included a maps link that took be straight to
the right location with popup (Google Maps). That was very useful.

Would it be fair to say then, that it has a place for specific uses
(such as non-discrete data like map locations)?

That's not new. It started with IE4. BTW, I was there.

You know what I mean - every man and his dog using XHR to load page
content - for example.

Wrong. Navigation is as it has always been. Just as with popup
windows, there are lots of incompetent developers out there trying to
muck it up.

Popup windows where blocked by vendors because people hated them, not
because they were incompetendly implemented or broke browser
functionality. There is not going to be a [conscious] user backlash
against hash-links. People might stop using websites that use hash-
links because they [unconsciously] find the website hard to use, but I
don't see that happening.

My point is this: the way in which many websites work has changed, for
good or for bad. The way the browser handles navigation has not
changed fundamentally, so it seems like good practice to allow the
browser to continue to behave the way it was intended and is expected,
*given* that the website is making a lot of state changes to
individual pages.

It seems like there is a case for them, and if there is a set of
guidelines for doing it 'right', maybe that is what we should be
talking about, rather than the myriad ways to screw it up (of which, I
accept, there are many!).

I suggest that Google's JS developers are completely clueless, even
about basic accessibility issues. Go to their "My Account" page and
see how their menu reads without images. Then click "Adsense" and
notice that the back button breaks. Doesn't get any more basic than
that (and that's just the tip of the iceberg.)

Heh, my biggest complaint about Gmail is there insistence on moving
the cursor to next input element on page load - except that I'm
already half-way through typing my username by that point so I get
shunted to the password field.

You are right that they're not exactly shining lights in that regard,
but still, they've raised the expectation of what is possible.

 

[David Mark]

[snip]

Btw, it seems odd that small players like Gmail and Facebook
successfully use it, and you (David) won't even entertain a discussion
on implementation. I suggest that they know more on the subject of how
people use their sites than you do.

Well, we already know about Google's dilapidated properties. How
about Facebook?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

I'm sure they know people use their sites with IE, so why use XHTML.
No rurprise that it is not really XHTML:

http://validator.w3.org/check?uri=h...(detect+automatically)&doctype=Inline&group=0

Errors found while checking this document as XHTML 1.0 Strict!
Result: 68 Errors, 6 warning(s)

So it really isn't "strict" anything. Just tag soup. So why would
these user-conscious developers use a dead language (or rather pretend
to use a dead language?) They probably copied and pasted it and
didn't ask their users at all.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
id="facebook">

What a waste.

<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

I knew it.

<meta http-equiv="Content-language" content="en" />
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Pfft.

<script type="text/javascript">
//<![CDATA[

Gobbledygook.

[snip a bunch of useless BS]

//]]>
</script><noscript> <meta http-equiv=refresh content="0; URL=http://
www.facebook.com/?_fb_noscript=1" /> </noscript>

Aha! There's the most basic degradation question: what does it do
without scripting? Not that.

Still want to learn from these guys? It should be obvious after five
minutes and a few dozen lines of markup (excluding bloated inline
scripts) that these particular developers don't know anything.

 

[Andrew Poulos]

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

I knew it.

??? What's "wrong" with the line?

Andrew Poulos

 

[David Mark]

I see where you're coming from, but I wonder - I got an email today
for a conference that included a maps link that took be straight to
the right location with popup (Google Maps). That was very useful.

Of course. That's done with a query, which is normally processed
server side (thought not necessarily.) It's only done with a hash
when there is actually a fragment by that name (or ID.)

Would it be fair to say then, that it has a place for specific uses
(such as non-discrete data like map locations)?

We aren't talking about the same thing.

You know what I mean - every man and his dog using XHR to load page
content - for example.



Popup windows where blocked by vendors because people hated them, not
because they were incompetendly implemented or broke browser
functionality.

Incompetence and broken browser behavior were definite factors (with
particular emphasis on the former.)

There is not going to be a [conscious] user backlash
against hash-links. People might stop using websites that use hash-
links because they [unconsciously] find the website hard to use, but I
don't see that happening.

If the bar is only to avoid a world-wide backlash, then virtually
every design is successful.

My point is this: the way in which many websites work has changed, for
good or for bad.

You aren't really saying anything related to the design decision.
Seems this whole thread has been one generalized statement after
another. It's like everybody is sure this is their new toy and can't
see the potential choking hazard. I'm telling you it's there.

The way the browser handles navigation has not
changed fundamentally, so it seems like good practice to allow the
browser to continue to behave the way it was intended and is expected,
*given* that the website is making a lot of state changes to
individual pages.

You aren't making any sense at all here. The point is to let the
browser handle the navigation. That's what it has always done. State
changes have nothing to do with navigation. They never have. If you
want to persist state, use a cookie.

It seems like there is a case for them, and if there is a set of
guidelines for doing it 'right', maybe that is what we should be
talking about, rather than the myriad ways to screw it up (of which, I
accept, there are many!).

I already told you. Leave the location alone. Are you implying there
is some really cool Website idea that cannot be implemented without
resorting to faux navigation? Somehow it would confuse the users
otherwise? I'm telling you there isn't. Additionally, the number of
ways you can screw it up should be your first indication that I am
right to recommend complete avoidance.

Heh, my biggest complaint about Gmail is there insistence on moving
the cursor to next input element on page load - except that I'm
already half-way through typing my username by that point so I get
shunted to the password field.

Woohoo! I just signed up for a completely accessible, usable Web mail
service hosted by a huge company that can surely afford droves of
competent Web developers.

It's called GMail. DOH! Thr abject failure of all three examples
cited in this thread (W3C, Google and Facebook--see other post on
them) is your second indication.

You are right that they're not exactly shining lights in that regard,
but still, they've raised the expectation of what is possible.

They've shown some very bad things are possible. Bad things that
occasionally resemble good ideas to people who either aren't thinking
clearly or have no idea what they are looking at. I put it to you
that their Ajax-Web2.0 nonsense would have looked like old hat to me
in 1998. The Web has caught up to what is possible, but virtually
everything is being done wrong.

 

[David Mark]

??? What's "wrong" with the line?

It is certainly out of place in an XHTML document.