Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

199 views
Skip to first unread message

Peter Michaux

unread,
Jun 25, 2009, 10:57:25 PM6/25/09
to
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?

Message has been deleted

David Mark

unread,
Jun 28, 2009, 2:46:12 AM6/28/09
to
On Jun 25, 10:57 pm, Peter Michaux <petermich...@gmail.com> wrote:
> 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.

kangax

unread,
Jul 3, 2009, 11:52:55 PM7/3/09
to
Peter Michaux wrote:
> 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
>
> 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!

I see that Safari 2.0.4 (last one in 2.x series) refreshes the page (or
rather goes into some kind of an infinite loading state). 3 series
(3.0.4) already doesn't have such "problem". There are still users with
Safari 2.x out there, of course, but I suppose much fewer than two years
ago.

If Safari 2.x refreshes the page, doesn't it mean that users get page
refresh but still end up with a proper hash in an address bar and so can
bookmark it?

It also appears that Opera 8.54 refreshes the page, but 9.5 already
doesn't (on Mac OSX). I couldn't test any other ones in between.

[...]

--
kangax

Peter Michaux

unread,
Jul 4, 2009, 12:36:19 AM7/4/09
to

Thanks for looking into those versions! I now remember that infinite
loading business with Safari and Yahoo! Maps.

Yes refreshing means the page still ends up having the hash but the
general goal of speediness due to not refreshing the page is lost. If
all browsers refreshed when setting the hash, I would guess no one
would use the approach I described.

Peter

Peter Michaux

unread,
Jul 4, 2009, 11:48:32 AM7/4/09
to

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

unread,
Jul 5, 2009, 8:10:52 PM7/5/09
to
On Jul 4, 11:48 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jun 27, 11:46 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jun 25, 10:57 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > 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.
>
> 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

unread,
Jul 5, 2009, 10:40:15 PM7/5/09
to
On Jul 5, 5:10 pm, David Mark wrote:
> On Jul 4, 11:48 am, Peter Michaux wrote:
> > On Jun 27, 11:46 pm, David Mark wrote:

> > > On Jun 25, 10:57 pm, Peter Michaux wrote:

> > 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 don't see how your conclusion follows. Being able to capture the
entire state of the page in a URL is handy for bookmarking.


> > 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.

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.


> > 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.

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

unread,
Jul 5, 2009, 11:11:57 PM7/5/09
to
On Jul 5, 10:40 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 5, 5:10 pm, David Mark wrote:
>
> > On Jul 4, 11:48 am, Peter Michaux wrote:
> > > On Jun 27, 11:46 pm, David Mark wrote:
> > > > On Jun 25, 10:57 pm, Peter Michaux wrote:
> > > 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 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 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.
>
> 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.

>
> > 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.

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.

>
> > 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.

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?)

>
> > > 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.
>
> 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

unread,
Jul 5, 2009, 11:56:05 PM7/5/09
to
On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:

> 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

unread,
Jul 6, 2009, 2:49:48 AM7/6/09
to
On Jul 5, 11:56 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > 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,

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

[snip]

Garrett Smith

unread,
Jul 6, 2009, 3:57:25 AM7/6/09
to
Peter Michaux wrote:
> 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.

It also causes the browser to scroll the element into view. This can be
implicated in a degradation strategy.

I've been using that RESTful technique for about eight years.

--
comp.lang.javascript FAQ: http://jibbering.com/faq/

David Mark

unread,
Jul 6, 2009, 4:02:24 AM7/6/09
to

Haven't we all. But it is hardly appropriate here. There's no
element to scroll to (and these apps don't work without scripting.)

The main lesson here is that the user who expects *page* bookmarks to
persist the current state of the page exists only in the minds of
developers (perhaps they are thinking of themselves.)

Peter Michaux

unread,
Jul 6, 2009, 12:11:47 PM7/6/09
to

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

Peter

Peter Michaux

unread,
Jul 6, 2009, 12:26:34 PM7/6/09
to
On Jul 6, 1:02 am, David Mark <dmark.cins...@gmail.com> wrote:

> The main lesson here is that the user who expects *page* bookmarks to

You are still thinking of the web is a collection of pages. I don't
think the situation is that simple anymore.

Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
I doubt you do. They are applications. In many applications when you
reopen them they return to the state they were last in. Wouldn't it be
great to be able to bookmark a few different states and then open
directly to those states? My text editor does this in a way with
"projects" and I like it a lot.

As applications are deployed on the web as single-page apps, for lack
of a better term, we want to have more advanced navigation suitable to
an app.

I was just using Facebook to look at some photos from a friend. I was
clicking "next" repeatedly and the application was replacing only the
image and the URL hash. It was very snappy and I didn't have to scroll
down or see a jarring jump scroll down with each page load.

> persist the current state of the page exists only in the minds of
> developers (perhaps they are thinking of themselves.)

I don't think so. While looking at the photos, it looks like the page
is changing because the focal part of the page is changing. Because it
seems like the page is changing, I and I think any user who is
accustom to page changes expect the URL to always be representative of
the page being viewed. To get the smooth and snappy forward navigation
of "Ajax updates", that means keeping the URL in sync with the content
using URL hash-setting.

Peter

David Mark

unread,
Jul 6, 2009, 12:31:11 PM7/6/09
to

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.

David Mark

unread,
Jul 6, 2009, 12:51:17 PM7/6/09
to
On Jul 6, 12:26 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 6, 1:02 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > The main lesson here is that the user who expects *page* bookmarks to
>
> You are still thinking of the web is a collection of pages. I don't
> think the situation is that simple anymore.

I'm thinking of what bookmarks do. Obviously I know some pages can be
interactive.

>
> Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?

What does that mean?

> I doubt you do. They are applications. In many applications when you
> reopen them they return to the state they were last in.

So? Lots of documents do that to, typically with cookies. Who cares?

> Wouldn't it be
> great to be able to bookmark a few different states and then open
> directly to those states?

It's not that great and not new.

> My text editor does this in a way with
> "projects" and I like it a lot.

Why are you telling me this? Unless it is on a Mac, I probably wrote
your text editor. If it actually restores its size and state
properly, that's mine. If it comes up maximized then "restores" to
the same size or comes up minimized, etc.; that's somebody else. But
seriously, can we cut to the chase?

>
> As applications are deployed on the web as single-page apps, for lack
> of a better term, we want to have more advanced navigation suitable to
> an app.

Who is we? And we don't always get what we want. Browsers are
browsers, not operating systems. Do you see how they will never be
the latter? Web3.0 (whatever it may be) will not involve scripted
navigation hacks. Why waste time trying and testing (and discussing!)
such nonsense?

>
> I was just using Facebook to look at some photos from a friend. > I was
> clicking "next" repeatedly and the application was replacing only the
> image and the URL hash. It was very snappy and I didn't have to scroll
> down or see a jarring jump scroll down with each page load.

A slide show? Is this whole series of questions a joke?

>
> > persist the current state of the page exists only in the minds of
> > developers (perhaps they are thinking of themselves.)
>
> I don't think so. While looking at the photos, it looks like the page
> is changing because the focal part of the page is changing.

Fooling yourself. Slide shows don't imply navigation. It looks to
you like you are navigating because some script is navigating for you
in an ill-advised attempt to make one document look like several. If
it didn't create that illusion of navigation, it wouldn't raise
expectations about bookmarks.

> Because it
> seems like the page is changing, I and I think any user who is
> accustom to page changes expect the URL to always be representative of
> the page being viewed. To get the smooth and snappy forward navigation
> of "Ajax updates", that means keeping the URL in sync with the content
> using URL hash-setting.

Smooth and snappy? I think I'm going to vomit. You are used to pages
with unload listeners.

David Mark

unread,
Jul 6, 2009, 9:38:43 PM7/6/09
to
On Jul 6, 12:26 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 6, 1:02 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > The main lesson here is that the user who expects *page* bookmarks to
>
> You are still thinking of the web is a collection of pages. I don't
> think the situation is that simple anymore.
>
> Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
> I doubt you do. They are applications. In many applications when you
> reopen them they return to the state they were last in. Wouldn't it be
> great to be able to bookmark a few different states and then open
> directly to those states? My text editor does this in a way with
> "projects" and I like it a lot.
>
> As applications are deployed on the web as single-page apps, for lack
> of a better term, we want to have more advanced navigation suitable to
> an app.
>
> I was just using Facebook to look at some photos from a friend. I was
> clicking "next" repeatedly and the application was replacing only the
> image and the URL hash. It was very snappy and I didn't have to scroll
> down or see a jarring jump scroll down with each page load.
>
> > persist the current state of the page exists only in the minds of
> > developers (perhaps they are thinking of themselves.)
>
> I don't think so. While looking at the photos, it looks like the page
> is changing because the focal part of the page is changing.

Also, swapping images on a document does not indicate navigation to
any group I can think of. Slide shows typically have their own
forward and back buttons as well.

You mentioned above that the page doesn't scroll. I assume then that
this slide show is not at the top of the document either. The fact
that it does *not* scroll is a dead giveaway to any user savvy enough
to pay attention that the browser did *not* navigate, so there's no
need to twiddle with the history to avert potential confusion (there
is no confusion.)

I'd be surprised as hell if a slide show broke my browser's back and
forward buttons (and more than a little put off by such a silly design
decision.) In other words, if I want to navigate back to the document
before the one with the slide show, I better not see the slide show
swap an image as a response to that action (else it is goodbye to that
site.)

> Because it
> seems like the page is changing, I and I think any user who is
> accustom to page changes expect the URL to always be representative of
> the page being viewed. To get the smooth and snappy forward navigation
> of "Ajax updates", that means keeping the URL in sync with the content
> using URL hash-setting.

Having written about a hundred slide shows and re-vamping dozens more,
I've never seen such a thing, nor can I imagine how it would make
swapping images any more smooth or snappy.

Peter Michaux

unread,
Jul 6, 2009, 11:34:02 PM7/6/09
to
On Jul 6, 6:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 6, 12:26 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > On Jul 6, 1:02 am, David Mark <dmark.cins...@gmail.com> wrote:

> You mentioned above that the page doesn't scroll.  I assume then that
> this slide show is not at the top of the document either.  The fact
> that it does *not* scroll is a dead giveaway to any user savvy enough
> to pay attention that the browser did *not* navigate, so there's no
> need to twiddle with the history to avert potential confusion (there
> is no confusion.)

I think the user group you are describing is *extremely* small. The
people on c.l.js may be some of the only members of such a group. Many
people don't know what a "browser" is.

http://pleaseenjoy.com/project.php?cat=4&subcat=&pid=131&navpoint=2

If I use the word "browser" to non-programmers, people frequently
scrunch up their face until I say "Internet Explorer", "Firefox", or
"Safari". If I choose to say the name of a browser they don't use they
get even more confused.

If they don't know what a browser is they are not likely going to
notice or understand the subtitles of scrolling on page load.

> I'd be surprised as hell if a slide show broke my browser's back and
> forward buttons (and more than a little put off by such a silly design
> decision.)  In other words, if I want to navigate back to the document
> before the one with the slide show, I better not see the slide show
> swap an image as a response to that action (else it is goodbye to that
> site.)

I like the opposite behavior you do. In fact, that means I like the
traditional, non-JavaScript, history behavior where each picture in
the slide show has its own complete HTML page.

> > Because it
> > seems like the page is changing, I and I think any user who is
> > accustom to page changes expect the URL to always be representative of
> > the page being viewed. To get the smooth and snappy forward navigation
> > of "Ajax updates", that means keeping the URL in sync with the content
> > using URL hash-setting.
>
> Having written about a hundred slide shows and re-vamping dozens more,
> I've never seen such a thing, nor can I imagine how it would make
> swapping images any more smooth or snappy.

Setting the URL hash when changing the image in a slide show does not
make it snappier. It does increase intuitive usability for bookmarking
and emailing the current image's link since it is always up-to-date in
the browser's address bar. Whether or not the URL for each image is
added to the history is an independent issue but I think adding it for
a slide show is a good idea. Adding it for Yahoo! Maps may not be a
good idea as the user may be making many temporary changes along the
way.

Peter

Thomas 'PointedEars' Lahn

unread,
Jul 7, 2009, 3:52:44 PM7/7/09
to

Apparently it's past time for a reality check:

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


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

David Mark

unread,
Jul 7, 2009, 5:36:35 PM7/7/09
to

Then write it like that and make sure the slide show is the focal
point of the document (unlike what you described before.) You don't
need to try to simulate navigation. Browsers know how to do it and do
it very well.

>
> > > Because it
> > > seems like the page is changing, I and I think any user who is
> > > accustom to page changes expect the URL to always be representative of
> > > the page being viewed. To get the smooth and snappy forward navigation
> > > of "Ajax updates", that means keeping the URL in sync with the content
> > > using URL hash-setting.
>
> > Having written about a hundred slide shows and re-vamping dozens more,
> > I've never seen such a thing, nor can I imagine how it would make
> > swapping images any more smooth or snappy.
>
> Setting the URL hash when changing the image in a slide show does not
> make it snappier. It does increase intuitive usability for bookmarking
> and emailing the current image's link since it is always up-to-date in
> the browser's address bar. Whether or not the URL for each image is
> added to the history is an independent issue but I think adding it for
> a slide show is a good idea. Adding it for Yahoo! Maps may not be a
> good idea as the user may be making many temporary changes along the
> way.

Making an image swapper twiddle the location to simulate navigation is
a *terrible* idea. Think about it.

David Mark

unread,
Jul 7, 2009, 5:38:32 PM7/7/09
to
On Jul 6, 11:34 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 6, 6:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 6, 12:26 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > On Jul 6, 1:02 am, David Mark <dmark.cins...@gmail.com> wrote:
> > You mentioned above that the page doesn't scroll.  I assume then that
> > this slide show is not at the top of the document either.  The fact
> > that it does *not* scroll is a dead giveaway to any user savvy enough
> > to pay attention that the browser did *not* navigate, so there's no
> > need to twiddle with the history to avert potential confusion (there
> > is no confusion.)
>
> I think the user group you are describing is *extremely* small. The
> people on c.l.js may be some of the only members of such a group. Many
> people don't know what a "browser" is.

You are making my point for me, so I assume you didn't understand.
There is no need to simulate navigation if there is no confusion (and
there can't be any confusion for people who aren't paying attention or
don't know what they are looking at in the first place.) You are
programming for that small group of people who know the difference and
they don't want you to mess with their navigation history.

[snip]

David Mark

unread,
Jul 7, 2009, 5:39:59 PM7/7/09
to
On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> David Mark wrote:
> > On Jul 6, 12:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >> On Jul 5, 11:49 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>> On Jul 5, 11:56 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >>>> On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>> 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,
> >>> 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.
>
> > 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>

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

David Mark

unread,
Jul 7, 2009, 5:43:50 PM7/7/09
to
On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> David Mark wrote:
> > On Jul 6, 12:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >> On Jul 5, 11:49 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>> On Jul 5, 11:56 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >>>> On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>> 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,
> >>> 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.
>
> > 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>
>

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

unread,
Jul 7, 2009, 7:26:09 PM7/7/09
to

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

unread,
Jul 7, 2009, 7:55:12 PM7/7/09
to

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:
>
> > 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.

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

unread,
Jul 7, 2009, 8:25:41 PM7/7/09
to
On Jul 8, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:

> > 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.

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)?

> > 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. ;)

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

> > 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.

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

unread,
Jul 7, 2009, 8:35:50 PM7/7/09
to
On Jul 7, 7:26 pm, Hamish Campbell <HN.Campb...@gmail.com> wrote:

[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=http%3A%2F%2Fwww.facebook.com&charset=(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.

David Mark

unread,
Jul 7, 2009, 8:54:18 PM7/7/09
to
On Jul 7, 8:25 pm, Hamish Campbell <HN.Campb...@gmail.com> wrote:
> On Jul 8, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > 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.
>
> 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.

>
> > > 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.  ;)
>
> You know what I mean - every man and his dog using XHR to load page
> content - for example.
>
> > > 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.
>
> 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.

>
> > 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.

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.

Andrew Poulos

unread,
Jul 7, 2009, 8:52:34 PM7/7/09
to
David Mark wrote:

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

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

Andrew Poulos

David Mark

unread,
Jul 7, 2009, 9:01:08 PM7/7/09
to

It is certainly out of place in an XHTML document.

David Mark

unread,
Jul 7, 2009, 9:05:16 PM7/7/09
to
On Jul 7, 8:52 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:

And more to the point, it confirmed my "suspicion" that it was not an
XHTML document )at least not served as one.) Quotes indicate that IE
doesn't support such documents, so it was a foregone conclusion.

Peter Michaux

unread,
Jul 8, 2009, 2:15:29 AM7/8/09
to

I don't think that closes anything. You are simply replying to and
agreeing with yourself.

Peter

Peter Michaux

unread,
Jul 8, 2009, 2:26:38 AM7/8/09
to
On Jul 6, 9:31 am, David Mark:

> They expect it to bookmark the page, not preserve *state*.

When a user creates a bookmark, they expect it to bookmark the page.
In an page that is heavily updated dynamically using JavaScript the
user doesn't necessarily recognized when the full page transitions
occur. If a large portion or the focal portion of the page changes,
the user may equate that with a full page change. So in that case, the
user would expect the bookmark to preserve the state of the single
page web app.

> Nobody would.

That statement is not based on observable data. Clearly people do
expect the bookmark to preserve state. At the very least the
developers of pages using URL hash-setting expect a bookmark to
preserve the state.

> Not in the whole history of Web browsers has that ever
> worked.

Again a statement not based on fact. With script, it works now in many
browsers.

> It's just "Web2.0" script kiddie nonsense

I think the name calling detracts from any technical points you are
trying to make.

> that does that and
> it's never been prevalent enough to supplant previous expectations
> about bookmark behavior.

In my opinion, you are way overestimating the user's understanding of
a strict definition of what a page change is and how to recognize one.

With large sites like GMail and Facebook using URL hash-setting
navigation, user expectations are likely to change.

Peter

Peter Michaux

unread,
Jul 8, 2009, 2:31:16 AM7/8/09
to
On Jul 7, 2:39 pm, David Mark:

> On Jul 7, 3:52 pm, PointedEars wrote:

> > <http://validator.w3.org/#validate_by_input>
>
> Broken by design (try using the back button)

It is not broken by design and you proclaiming it is does not make it
so.

You could argue that the implementation is broken as the back button
does not work properly. That, however, can be fixed.

> and that site is a crock anyway

You have only stated you think that site "is a crock" without any real
reason. Judgements without reason don't change my opinion about how
useful that site is to me.

Peter

Peter Michaux

unread,
Jul 8, 2009, 2:32:20 AM7/8/09
to
On Jul 7, 2:43 pm, David Mark wrote:
> On Jul 7, 3:52 pm, PointedEars wrote:

> > <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?

How would you have implemented that page?

Peter

David Mark

unread,
Jul 8, 2009, 2:32:36 AM7/8/09
to

BS. You can see that it was a bad snip. I replied to:

"For example, Yahoo! Maps does not look like multiple documents in one
document."

And are you still arguing these points after all of this? Seems
beyond belief. You wrote some of the best articles on progressive
enhancement using (as acknowledged) several of my ideas and
suggestions. Two years later you want to synthesize navigation
history entries for slide shows and won't listen when I tell you it is
a ludicrous design?

And Google and Facebook are your examples? I wouldn't rush to blog
about this one. It's a dog.

Peter Michaux

unread,
Jul 8, 2009, 2:42:58 AM7/8/09
to
On Jul 7, 4:26 pm, Hamish Campbell <HN.Campb...@gmail.com> wrote:

> 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

For a site that is concerned only with a set of relatively new browser
version, the hurdles are not that great.

If you are writing a page for the general web then the technique may
not be advisable. It may never be advisable on the general web.


> 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.

Many of us design user interfaces also so I believe discussing the
user experience merits of a JavaScript-enabled technique are on topic
for this group.


> The point is not
> whether this is good usability or not (that decision will be made
> elsewhere),

It can be made here too.


> but whether it can be implemented.

It appears to be implementable at least in relatively new versions of
the major browsers.


> Btw, it seems odd that small players like Gmail and Facebook

"small"?


> 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.

I would imagine they (especially Google) have usability testing groups
that look over the shoulders of users to see how they interact with
pages. I also imagine they have many support emails about what users
like or do not like.

Peter

David Mark

unread,
Jul 8, 2009, 2:51:44 AM7/8/09
to
On Jul 8, 2:26 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 6, 9:31 am, David Mark:
>
> > They expect it to bookmark the page, not preserve *state*.
>
> When a user creates a bookmark, they expect it to bookmark the page.
> In an page that is heavily updated dynamically using JavaScript the
> user doesn't necessarily recognized when the full page transitions
> occur. If a large portion or the focal portion of the page changes,
> the user may equate that with a full page change. So in that case, the
> user would expect the bookmark to preserve the state of the single
> page web app.
>
> > Nobody would.
>
> That statement is not based on observable data. Clearly people do
> expect the bookmark to preserve state.

What people? They must be very disappointed that bookmarks never did
that. As mentioned, cookies did. Not the average user knows what
either is. They can sometimes detect when somebody has broken their
browser though they likely won't know who to blame. I do.

> At the very least the
> developers of pages using URL hash-setting expect a bookmark to
> preserve the state.

Isn't that what I said several times in this thread? Only the goofy
developers notice it and they are showing off for their similarly
sense-impaired colleagues. They may rationalize that they are
providing a more "intuitive" user experience, but that's classic
cognitive dissonance.

>
> > Not in the whole history of Web browsers has that ever
> > worked.
>
> Again a statement not based on fact. With script, it works now in many
> browsers.

No, you seemingly misunderstand again (which seems impossible.)
Bookmarks have never preserved state. Period. You are looking at an
illusion you created and buying into it. Made up hashes are not
states. You are creating a new URI, which has only one state. That's
why you have to mess with window.location, which is an outrageously
ill-advised scheme given that cookies (and even SQL) are available to
preserve states, without creating any of the problems associated with
faux history entries.

>
> > It's just "Web2.0" script kiddie nonsense
>
> I think the name calling detracts from any technical points you are
> trying to make.

Who am I calling names? Everyone will have figure out for themselves
if that shoe fits. None of this is new, BTW. The idea has been
floated, sunk and branded as "script kiddie" (or simply "backwards"
might be more to the point.) Don't join *that* club.


>
> > that does that and
> > it's never been prevalent enough to supplant previous expectations
> > about bookmark behavior.
>
> In my opinion, you are way overestimating the user's understanding of
> a strict definition of what a page change is and how to recognize one.

How many times are you going to make my point for me? My primary
argument is that the users have no idea what to expect. Why create an
illusion for people without expectations? I know any semi-Web-
literate user will not expect an image swap (e.g. slide show) to
create a new history entry.

>
> With large sites like GMail and Facebook using URL hash-setting
> navigation, user expectations are likely to change.

Change from nothing concrete to something else you can't pin down?
I'm telling you they don't know what they are looking at (and don't
care.)

And I'm still waiting for a real example. Obviously slide shows were
a bad choice. Thomas went with a botched tabbed dialog (ironic given
your article on creating a similar enhancement.) What is your idea
that demands messing with *my* browser history? I bet it will turn
out to need no such thing. There's just no way that an argument of
"users expect bookmarks to work" is ever going to fly (I sure as hell
wouldn't design something that breaks bookmarks and most users
wouldn't notice if I did.)

Peter Michaux

unread,
Jul 8, 2009, 3:06:27 AM7/8/09
to
On Jul 7, 4:55 pm, David Mark wrote:

> On Jul 7, 7:26 pm, Hamish Campbell wrote:

> > 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.

"usable" is not a boolean property of a slideshow or a single-page web
app.


> Did you see the best example Thomas could come up with?

You don't know it is the best example he could find.


> Do you
> understand how it illustrates how few people know enough to accomplish
> this particular enhancement (without breaking the browser?)

I don't see any benefit in discussing what other people are not able
to implement. We already know there are many bad scripts on the web.


> 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.

You still haven't stated what is wrong with the design of the page
behavior. Sure they haven't fixed the back button behavior but they
could. That is not a problem with the design.


> > 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.
>
> LOL. Then there are a lot of disappointed users out there as
> bookmarks do no such thing. Never have.

I've presented several examples of sites where bookmarks do preserve
state. See Yahoo! Maps, for example.


> Thomas' (bad) example is
> just three document fragments that have been rearranged with script to
> look like a tabbed dialog. That's not state.

Which tab is selected is definitely page state.


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

In my opinion, page state should never be preserved with cookies. That
adds weight to the HTTP requests, the preservation of state is
volatile, and cookies cannot be bookmarked or emailed.


> > 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.

That is not what he wrote. They do have expectations. They expect that
a bookmark preserves whatever their impression is of "current page".
If the page is changing dramatically as they interact then they may
interpret those changes as page changes.


> 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.)

I think it improves usability for non-savvy users and also adds easier
navigation control for those who understand what is happening.


> As
> illustrated, even with a simplified example, the crack W3C developers
> blew it.

That is not a black mark on the technique itself. It is not very
difficult to implement properly when it is known that browsers
supporting the necessary features are in use.


> 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.

I don't think that you've made a compelling case. All I've read is
quite a lot of "don't do it because I'm an expert and I say so" and
name calling. Neither of those approaches are moving.


> I suggest that Google's JS developers are completely clueless,

I'm a user and I enjoy using several of their web applications daily.


> 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,

Before Facebook used URL hash-setting for their slideshow navigation,
they used full page refreshes. That means that it would be 13 clicks
on the back button to get where you were before the slide show. "Most
users" did not stop using Facebook. In fact, Facebook has a quickly
growing user base. People seemed to like the Facebook user experience.


> but were not asked to articulate their
> position to Facebook's incompetent Web designers.

I don't know how you can claim the web *designers* or even the web
*programmers* at Facebook are incompetent. I use Facebook regularly
and don't have any troubles with it.


> 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?

Why are you worried about other people's abilities to implement a
technique?

Peter

David Mark

unread,
Jul 8, 2009, 3:09:00 AM7/8/09
to

Are you kidding? Didn't we once discuss tabs here for a month (and
then you wrote an article on the subject?) My ideas on the subject
are largely unchanged (and are no longer free in most cases.) ;)

I'll ask again. Can anyone not see how these ostensibly competent
developers botched this comparatively simple enhancement?

Peter Michaux

unread,
Jul 8, 2009, 3:12:33 AM7/8/09
to
On Jul 7, 5:25 pm, Hamish Campbell wrote:

> 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!).

This is a well put point and I think this is exactly why hash-links
have appeared. People want the benefits of DHTML to modify the page
quickly and significantly but the navigation to work the way it did/
does without JavaScript around. In fact, handling the URL issues is
completing the illusion of a full page change DHTML is mostly
providing without the latency of a real full page change.

Peter

Peter Michaux

unread,
Jul 8, 2009, 3:20:52 AM7/8/09
to
On Jul 7, 5:54 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 7, 8:25 pm, Hamish Campbell <HN.Campb...@gmail.com> wrote:
>
> > On Jul 8, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > 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.
>
> > 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.)

Perhaps it was only done "when there is actually a fragment by that
name" in the past but clearly that is not the case now as single page
apps are using the hash for other purposes.


> > 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.

Sure danger is there. The first character of script adds danger to the
page.

If you don't like the generalizations then focus on an example. Of all
the examples mentioned, I think Yahoo! Maps is the strongest example
of using hash-setting well. I think the "permalink" link in Google
Maps is a very poor user experience in comparison to the Yahoo! Maps
hash-setting.


> The Web has caught up to what is possible, but virtually
> everything is being done wrong.

And yet the web is still a huge success.

Peter

David Mark

unread,
Jul 8, 2009, 3:26:44 AM7/8/09
to
On Jul 8, 3:12 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 7, 5:25 pm, Hamish Campbell wrote:
>
> > 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!).
>
> This is a well put point and I think this is exactly why hash-links

No, it isn't. I've already answered the question from every
conceivable angle. Cookies top the list and they don't break
bookmarks. On the contrary, they work together like magic. Want to
highlight sending state-tinged links to friends? Can you not compete
with the browser's file menu? You know the technical details (tack on
a query, not a hash.)

> have appeared. People want the benefits of DHTML to modify the page
> quickly and significantly but the navigation to work the way it did/
> does without JavaScript around.

I don't know who these people are and only vaguely followed that
anyway. How does the presence of JS affect navigation? Oh, when
incompetent programmers pollute the history, break the back button,
etc. Yeah, I want it to work like it dis without Javascript around.
No question.

> In fact, handling the URL issues is
> completing the illusion of a full page change DHTML is mostly
> providing without the latency of a real full page change.

If there was no full page change, there was no navigation. You don't
need to create illusions for users with no expectations. Those with
expectations are likely savvy enough to figure out your "send a link"
interface (and that using the browser's file menu instead does not
send along the state of the document.) They'll figure out that
navigation works as it did before the Ajax suicide squads became
prevalent. Do keep in mind that this "technique" has been used for
years, despite it being known to cause major problems (in major
browsers no less.) That's the mindset. Now you say "all browsers"
work? It's like this whole thread is a bizarre put-on.

David Mark

unread,
Jul 8, 2009, 3:33:10 AM7/8/09
to
On Jul 8, 3:20 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 7, 5:54 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Jul 7, 8:25 pm, Hamish Campbell <HN.Campb...@gmail.com> wrote:
>
> > > On Jul 8, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > > 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.
>
> > > 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.)
>
> Perhaps it was only done "when there is actually a fragment by that
> name" in the past but clearly that is not the case now as single page
> apps are using the hash for other purposes.

Only done by people who know what they are doing. We both know that
excludes most Web developers (particularly when scripting is
involved.)

>
> > > 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.
>
> Sure danger is there. The first character of script adds danger to the
> page.

That's a silly thing to say. Big trip from "hello world" to "goodbye
usability."

>
> If you don't like the generalizations then focus on an example.

I've focused on every one presented, asked for more, as well as any
questions. Nothing so far.

> Of all
> the examples mentioned, I think Yahoo! Maps is the strongest example
> of using hash-setting well. I think the "permalink" link in Google
> Maps is a very poor user experience in comparison to the Yahoo! Maps
> hash-setting.

This is that one exception that proves the rule. Google got it
"right." Quotes indicate I haven't looked at it, am sure the
implementation is weak and the word "permalink" should not be involved
(in any public site for that matter as few people other than Web
developers know what it means.)

>
> > The Web has caught up to what is possible, but virtually
> > everything is being done wrong.
>
> And yet the web is still a huge success.

Now I am going to throw up. Seriously, were you kidnapped by aliens?

Everything is relative. And I put it to you that the Web is a huge
mess and a dismal failure in many cases. If you've got to pigeonhole
it, I think most users would vote for the "huge mess" classification.

Peter Michaux

unread,
Jul 8, 2009, 3:37:54 AM7/8/09
to
On Jul 7, 11:51 pm, David Mark wrote:
> On Jul 8, 2:26 am, Peter Michaux wrote:

> > On Jul 6, 9:31 am, David Mark wrote:
>
> > > They expect it to bookmark the page, not preserve *state*.
>
> > When a user creates a bookmark, they expect it to bookmark the page.
> > In an page that is heavily updated dynamically using JavaScript the
> > user doesn't necessarily recognized when the full page transitions
> > occur. If a large portion or the focal portion of the page changes,
> > the user may equate that with a full page change. So in that case, the
> > user would expect the bookmark to preserve the state of the single
> > page web app.
>
> > > Nobody would.
>
> > That statement is not based on observable data. Clearly people do
> > expect the bookmark to preserve state.
>
> What people? They must be very disappointed that bookmarks never did
> that. As mentioned, cookies did. Not the average user knows what
> either is. They can sometimes detect when somebody has broken their
> browser though they likely won't know who to blame. I do.
>
> > At the very least the
> > developers of pages using URL hash-setting expect a bookmark to
> > preserve the state.
>
> Isn't that what I said several times in this thread? Only the goofy
> developers notice it and they are showing off for their similarly
> sense-impaired colleagues. They may rationalize that they are
> providing a more "intuitive" user experience, but that's classic
> cognitive dissonance.

You wrote "nobody would" and I easily provided an counter-example of
people that would.


> > > Not in the whole history of Web browsers has that ever
> > > worked.
>
> > Again a statement not based on fact. With script, it works now in many
> > browsers.
>
> No, you seemingly misunderstand again (which seems impossible.)
> Bookmarks have never preserved state. Period.

Without question, bookmarks have always preserved state. At the very
least they preserve the state of the browser: which page the browser
is showing.

Bookmarks have even preserved page state. Suppose I bookmark a page
with http://example.com/asdf.html#one. When that page is loaded it
will be scrolled into position. That is a restoration of the scroll
state of the page.


> You are looking at an
> illusion you created and buying into it. Made up hashes are not
> states. You are creating a new URI, which has only one state. That's
> why you have to mess with window.location, which is an outrageously
> ill-advised scheme given that cookies (and even SQL) are available to
> preserve states, without creating any of the problems associated with
> faux history entries.

Hash-setting does not necessarily imply pushing new entries on the
browser's history.


> > > It's just "Web2.0" script kiddie nonsense
>
> > I think the name calling detracts from any technical points you are
> > trying to make.
>
> Who am I calling names? Everyone will have figure out for themselves
> if that shoe fits. None of this is new, BTW. The idea has been
> floated, sunk and branded as "script kiddie" (or simply "backwards"
> might be more to the point.) Don't join *that* club.

You haven't made any technical points about why hash-setting is a bad
idea. You've done little more than say you just don't like it.


> > > that does that and
> > > it's never been prevalent enough to supplant previous expectations
> > > about bookmark behavior.
>
> > In my opinion, you are way overestimating the user's understanding of
> > a strict definition of what a page change is and how to recognize one.
>
> How many times are you going to make my point for me? My primary
> argument is that the users have no idea what to expect.

The user has expectations based on intuition and past experience
(perhaps with non-script slide shows, for example.)


> Why create an
> illusion for people without expectations?

On the contrary, it is creating an illusion that matches people's
exceptions.


> I know any semi-Web-
> literate user will not expect an image swap (e.g. slide show) to
> create a new history entry.

They don't know it is implemented as an image swap. All they know is
what they see has changed. In a slide show without script that would
mean a page refresh. In a slide show with script making the image swap
the user may still interpret the change as a page change.

I don't find the slide show example as compelling as the Yahoo! Maps
example.


> > With large sites like GMail and Facebook using URL hash-setting
> > navigation, user expectations are likely to change.
>
> Change from nothing concrete to something else you can't pin down?
> I'm telling you they don't know what they are looking at (and don't
> care.)

They care that what they are looking at (for whatever their assessment
of "what they are looking at" means) can be restored with a bookmark.


> And I'm still waiting for a real example. Obviously slide shows were
> a bad choice. Thomas went with a botched tabbed dialog (ironic given
> your article on creating a similar enhancement.) What is your idea
> that demands messing with *my* browser history?

Hash-setting does not imply adjusting the browser history.


> I bet it will turn
> out to need no such thing. There's just no way that an argument of
> "users expect bookmarks to work" is ever going to fly (I sure as hell
> wouldn't design something that breaks bookmarks and most users
> wouldn't notice if I did.)

Yahoo! Maps is a fine example of using hash-setting to the benefit of
the user.

Peter

Peter Michaux

unread,
Jul 8, 2009, 3:43:20 AM7/8/09
to
On Jul 7, 11:32 pm, David Mark wrote:

> And are you still arguing these points after all of this?  Seems
> beyond belief.  You wrote some of the best articles on progressive
> enhancement using (as acknowledged) several of my ideas and
> suggestions.

The use of hash-setting is not counter to the idea of progressive
enhancements.


> Two years later you want to synthesize navigation
> history entries for slide shows

Yahoo Maps!


> and won't listen when I tell you it is
> a ludicrous design?

You are not saying why it is a ludicrous design. Just saying so has no
influence on me.


> And Google and Facebook are your examples?

I mentioned Yahoo! Maps much earlier in this thread as the example I
found most compelling. I've been on the fence about GMail and
Facebook. Facebook strikes me as the weakest of the three use cases.

Peter

Peter Michaux

unread,
Jul 8, 2009, 3:58:38 AM7/8/09
to
On Jul 8, 12:33 am, David Mark wrote:
> On Jul 8, 3:20 am, Peter Michaux wrote:

> > On Jul 7, 5:54 pm, David Mark wrote:

> > > The Web has caught up to what is possible, but virtually
> > > everything is being done wrong.
>
> > And yet the web is still a huge success.
>
> Now I am going to throw up. Seriously, were you kidnapped by aliens?
>
> Everything is relative. And I put it to you that the Web is a huge
> mess and a dismal failure in many cases. If you've got to pigeonhole
> it, I think most users would vote for the "huge mess" classification.

Wow. If you think the web has not been a huge success...I don't know
what to make of that. The web is one of the greatest successes in the
history of computing. The web has enabled massive information sharing
like no other time in the history of man. It has enhanced freedom of
speech to a point where it would be virtually impossible to censor
anyone. The fact that the web is so tolerant to poorly written source
files is amazing technical feat. The fact that web is so completely
intertwined many people's every day and work lives is testament to its
utility and popularity. The list goes on and on.

I'm confident most people would judge the web a huge success. They
would also judge Google and Facebook as successes. You seem to judge
none of these things as successes which seems impossible to
reconcile.

Peter

Peter Michaux

unread,
Jul 8, 2009, 4:02:45 AM7/8/09
to
On Jul 8, 12:26 am, David Mark <dmark.cins...@gmail.com> wrote:
> Now you say "all browsers" work?

I have slipped up with the typing at least once in this thread.
Without question, all browsers don't work well with hash-setting. As I
mentioned and kangax confirmed, old version of Safari, for example,
don't work well with hash-setting.

Wherever I have written "all browsers work" without qualification, I
have meant "all recent versions of the major browsers."

Peter

David Mark

unread,
Jul 8, 2009, 4:14:02 AM7/8/09
to

Which we both know carries no weight at all. I thought this case was
closed years ago. Odd end-around gimmick, something you don't need,
known to cause problems, frequently mixed with browser sniffing, etc.
Why are we discussing this again?

David Mark

unread,
Jul 8, 2009, 4:28:36 AM7/8/09
to

Just so happens it was irrelevant unless you were trying to prove my
point.

>
> > > > Not in the whole history of Web browsers has that ever
> > > > worked.
>
> > > Again a statement not based on fact. With script, it works now in many
> > > browsers.
>
> > No, you seemingly misunderstand again (which seems impossible.)
> > Bookmarks have never preserved state.  Period.
>
> Without question, bookmarks have always preserved state. At the very
> least they preserve the state of the browser: which page the browser
> is showing.

OMFG. I'll pretend you didn't write that.

>
> Bookmarks have even preserved page state. Suppose I bookmark a page

> withhttp://example.com/asdf.html#one. When that page is loaded it


> will be scrolled into position. That is a restoration of the scroll
> state of the page.

Again, that's a *fragment*, which is what hashes are for. I've
mentioned this six times already. The containing document would have
state preserved as cookies as the hash is obviously *taken*.

>
> > You are looking at an
> > illusion you created and buying into it.  Made up hashes are not
> > states.  You are creating a new URI, which has only one state.  That's
> > why you have to mess with window.location, which is an outrageously
> > ill-advised scheme given that cookies (and even SQL) are available to
> > preserve states, without creating any of the problems associated with
> > faux history entries.
>
> Hash-setting does not necessarily imply pushing new entries on the
> browser's history.

But that's the case we've been discussing all along. Do you now want
to replace the current entry instead? What possible good would that
do? It could certainly do some bad (i.e. reload the whole document),
but I can't think of anything to be gained from such an operation.
Cookies are what you want here. There's even SQL now in WebKit-based
browsers. Leave the hash alone.

>
> > > > It's just "Web2.0" script kiddie nonsense
>
> > > I think the name calling detracts from any technical points you are
> > > trying to make.
>
> > Who am I calling names?  Everyone will have figure out for themselves
> > if that shoe fits.  None of this is new, BTW.  The idea has been
> > floated, sunk and branded as "script kiddie" (or simply "backwards"
> > might be more to the point.)  Don't join *that* club.
>
> You haven't made any technical points about why hash-setting is a bad
> idea. You've done little more than say you just don't like it.

That's completely untrue. I've described in detail how the design is
flawed, why it isn't needed and demonstrated that every example design
posted thus far is flawed and/or broken. If you missed that, I
suggest you start over from the beginning.

>
> > > > that does that and
> > > > it's never been prevalent enough to supplant previous expectations
> > > > about bookmark behavior.
>
> > > In my opinion, you are way overestimating the user's understanding of
> > > a strict definition of what a page change is and how to recognize one.
>
> > How many times are you going to make my point for me?  My primary
> > argument is that the users have no idea what to expect.
>
> The user has expectations based on intuition and past experience
> (perhaps with non-script slide shows, for example.)

"Non-script" slide shows are typically a document with n static
images.

>
> > Why create an
> > illusion for people without expectations?
>
> On the contrary, it is creating an illusion that matches people's
> exceptions.
>
> > I know any semi-Web-
> > literate user will not expect an image swap (e.g. slide show) to
> > create a new history entry.
>
> They don't know it is implemented as an image swap. All they know is
> what they see has changed. In a slide show without script that would
> mean a page refresh. In a slide show with script making the image swap
> the user may still interpret the change as a page change.

You seem to want to argue this forever. I don't share that desire.
Do what you want, but realize you are rationalizing at best. God
knows, you haven't even tried to make any technical points here. The
whole thread is an embarrassment IMO.

>
> I don't find the slide show example as compelling as the Yahoo! Maps
> example.

I find neither compelling (or worthy of discussion at this time.)

>
> > > With large sites like GMail and Facebook using URL hash-setting
> > > navigation, user expectations are likely to change.
>
> > Change from nothing concrete to something else you can't pin down?
> > I'm telling you they don't know what they are looking at (and don't
> > care.)
>
> They care that what they are looking at (for whatever their assessment
> of "what they are looking at" means) can be restored with a bookmark.

I can't make heads or tails of that.

>
> > And I'm still waiting for a real example.  Obviously slide shows were
> > a bad choice.  Thomas went with a botched tabbed dialog (ironic given
> > your article on creating a similar enhancement.)  What is your idea
> > that demands messing with *my* browser history?
>
> Hash-setting does not imply adjusting the browser history.

See above.

>
> > I bet it will turn
> > out to need no such thing.  There's just no way that an argument of
> > "users expect bookmarks to work" is ever going to fly (I sure as hell
> > wouldn't design something that breaks bookmarks and most users
> > wouldn't notice if I did.)
>
> Yahoo! Maps is a fine example of using hash-setting to the benefit of
> the user.

Sounds like a commercial. No technical merit at all.

David Mark

unread,
Jul 8, 2009, 4:34:20 AM7/8/09
to
On Jul 8, 3:43 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 7, 11:32 pm, David Mark wrote:
>
> > And are you still arguing these points after all of this?  Seems
> > beyond belief.  You wrote some of the best articles on progressive
> > enhancement using (as acknowledged) several of my ideas and
> > suggestions.
>
> The use of hash-setting is not counter to the idea of progressive
> enhancements.

You are definitely at the other end of the spectrum. Simply put, good
ideas vs. lousy ones.

>
> > Two years later you want to synthesize navigation
> > history entries for slide shows
>
> Yahoo Maps!

Yes, I take it you like that site.

>
> > and won't listen when I tell you it is
> > a ludicrous design?
>
> You are not saying why it is a ludicrous design. Just saying so has no
> influence on me.

You need to read more carefully. Perhaps somebody else will now
explain it further. I think I've put enough time into this for one
lifetime. And you should know by now that I know what I am talking
about in this area. You should put more effort into understanding
what I said.

>
> > And Google and Facebook are your examples?
>
> I mentioned Yahoo! Maps much earlier in this thread as the example I
> found most compelling. I've been on the fence about GMail and
> Facebook. Facebook strikes me as the weakest of the three use cases.

This may come as a surprise, but I'm no fan of Yahoo! Maps (or any of
those other miserable map sites.) They are the worst. Scroll bars
everywhere, scripted balloon tips that scroll the destination off
screen. Doesn't surprise me they use faux hashes. I hadn't even
noticed (see what I mean.)

David Mark

unread,
Jul 8, 2009, 4:36:12 AM7/8/09
to
On Jul 8, 3:58 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 12:33 am, David Mark wrote:
>
> > On Jul 8, 3:20 am, Peter Michaux wrote:
> > > On Jul 7, 5:54 pm, David Mark wrote:
> > > > The Web has caught up to what is possible, but virtually
> > > > everything is being done wrong.
>
> > > And yet the web is still a huge success.
>
> > Now I am going to throw up.  Seriously, were you kidnapped by aliens?
>
> > Everything is relative.  And I put it to you that the Web is a huge
> > mess and a dismal failure in many cases.  If you've got to pigeonhole
> > it, I think most users would vote for the "huge mess" classification.
>
> Wow.

You know I hate that.

[snip irrelevance]

And you know exactly what I meant. If not, read it again.

Thomas 'PointedEars' Lahn

unread,
Jul 8, 2009, 5:47:52 AM7/8/09
to
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> On Jul 6, 12:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
>>>> On Jul 5, 11:49 pm, David Mark <dmark.cins...@gmail.com> wrote:

>>>>> On Jul 5, 11:56 pm, Peter Michaux <petermich...@gmail.com> wrote:
>>>>>> On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>> 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,
>>>>> 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.
>>> 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>
>
> Broken by design (try using the back button)

OK, the Back button doesn't work as supposed. That's a shame, indeed.

> and that site is a crock anyway

I beg your pardon?

> (what sort of reality check is that?)

Apparently I picked a bad example. However, it is possible to make the
Back/Forward feature work with this, and there are sites that do that.
Given that changing and preserving a document's state can work more
seamlessly if client-side scripting and DOM features are supported,
I cannot find anything wrong with this approach.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Peter Michaux

unread,
Jul 8, 2009, 12:07:47 PM7/8/09
to
Thomas 'PointedEars' Lahn wrote:
> > Thomas 'PointedEars' Lahn wrote:

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

> Apparently I picked a bad example. However, it is possible to make the
> Back/Forward feature work with this, and there are sites that do that.

The only way I know to do this is to poll the window.location property
for changes. This polling is easy to do but it is unfortunate there is
not a native window.onlocationchange event. I think that event will
appear eventually.

What other ways do you see?

> Given that changing and preserving a document's state can work more
> seamlessly if client-side scripting and DOM features are supported,
> I cannot find anything wrong with this approach.

For use on the general web, feature testing is required. I remember
that feature testing for the Safari infinite loading state bug when
setting the location.hash property was at least not obvious to me.
Safari was really breaking a long standing feature of browsers.

Peter

Peter Michaux

unread,
Jul 8, 2009, 12:16:43 PM7/8/09
to
On Jul 8, 1:14 am, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 4:02 am, Peter Michaux <petermich...@gmail.com> wrote:
> > On Jul 8, 12:26 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Now you say "all browsers" work?
>
> > I have slipped up with the typing at least once in this thread.
> > Without question, all browsers don't work well with hash-setting. As I
> > mentioned and kangax confirmed, old version of Safari, for example,
> > don't work well with hash-setting.
>
> > Wherever I have written "all browsers work" without qualification, I
> > have meant "all recent versions of the major browsers."
>
> Which we both know carries no weight at all.

No. I've always thought it carries a lot of weight. What works for
"most" of the web is an important property of any technique. If
feature testing can be layered on top then the technique can work well
for a slightly higher group of people.

It is almost assured that no script of even modest size, regardless of
feature testing, will work in all browsers. It will work in the
browsers where that script has been tested. It is unknown if it will
work elsewhere as browser bugs come in a wide variety of strange
flavors...some even you have never tasted.

> I thought this case was
> closed years ago.  Odd end-around gimmick, something you don't need,
> known to cause problems, frequently mixed with browser sniffing, etc.
> Why are we discussing this again?

Because URL hash-setting navigation appears to add value to the user
experience. As a user it has improved my user experience at least on
Yahoo! Maps.

Because if a technically sound approach exists to implement URL hash-
setting then that is at least interesting.

Peter

Peter Michaux

unread,
Jul 8, 2009, 12:32:38 PM7/8/09
to
On Jul 8, 1:28 am, David Mark wrote:

You write "nobody would", I give you a counterexample of people who
would, and you blow my example off as irrelevant. You could
alternately acknowledge the counterexample and refine your statement.


> > > > > Not in the whole history of Web browsers has that ever
> > > > > worked.
>
> > > > Again a statement not based on fact. With script, it works now in many
> > > > browsers.
>
> > > No, you seemingly misunderstand again (which seems impossible.)
> > > Bookmarks have never preserved state. Period.
>
> > Without question, bookmarks have always preserved state. At the very
> > least they preserve the state of the browser: which page the browser
> > is showing.
>
> OMFG. I'll pretend you didn't write that.

Why pretend I didn't write that? Because I'm right and it is contrary
to your previous statement?


> > Bookmarks have even preserved page state. Suppose I bookmark a page
> > withhttp://example.com/asdf.html#one. When that page is loaded it
> > will be scrolled into position. That is a restoration of the scroll
> > state of the page.
>
> Again, that's a *fragment*, which is what hashes are for.

I don't understand why you are so worried that hashes were originally
used for anchors. Many advances on the web have been made by using
features for purposes that were not the original intent. Often this
turns out to be bad but sometimes it turns out to be a great advance.


> I've
> mentioned this six times already. The containing document would have
> state preserved as cookies as the hash is obviously *taken*.

I think a cookie is a really awful way to preserve UI state. I've
already mentioned why: can't bookmark or email it, can loose it by
clearing or loosing cookies, loose it by changing browsers, etc.


> > > You are looking at an
> > > illusion you created and buying into it. Made up hashes are not
> > > states. You are creating a new URI, which has only one state. That's
> > > why you have to mess with window.location, which is an outrageously
> > > ill-advised scheme given that cookies (and even SQL) are available to
> > > preserve states, without creating any of the problems associated with
> > > faux history entries.
>
> > Hash-setting does not necessarily imply pushing new entries on the
> > browser's history.
>
> But that's the case we've been discussing all along.

No. Primarily we've been discussing setting the URL hash as the state
of the page changes.


> Do you now want
> to replace the current entry instead? What possible good would that
> do? It could certainly do some bad (i.e. reload the whole document),
> but I can't think of anything to be gained from such an operation.
> Cookies are what you want here. There's even SQL now in WebKit-based
> browsers. Leave the hash alone.

Is your objection to hash-setting simply the history issues? They are
not connected. Setting the URL hash does not imply adding to the
history.


> > > > > It's just "Web2.0" script kiddie nonsense
>
> > > > I think the name calling detracts from any technical points you are
> > > > trying to make.
>
> > > Who am I calling names? Everyone will have figure out for themselves
> > > if that shoe fits. None of this is new, BTW. The idea has been
> > > floated, sunk and branded as "script kiddie" (or simply "backwards"
> > > might be more to the point.) Don't join *that* club.
>
> > You haven't made any technical points about why hash-setting is a bad
> > idea. You've done little more than say you just don't like it.
>
> That's completely untrue. I've described in detail how the design is
> flawed, why it isn't needed and demonstrated that every example design
> posted thus far is flawed and/or broken.

You haven't made any demonstration of why the Yahoo Maps! design (not
implementation) is broken. You've said it is not necessary which is
true but not why it is broken.

Peter

Peter Michaux

unread,
Jul 8, 2009, 12:38:33 PM7/8/09
to
On Jul 8, 1:34 am, David Mark <dmark.cins...@gmail.com> wrote:

> And you should know by now that I know what I am talking
> about in this area.

I know you have some technical knowledge about browser scripting.
Because you have some knowledge, I am certainly interested in any
technical experience you have; however, just because you know and have
shared some things you've learned about browser scripting, it doesn't
mean I'll take your unjustified declarations of what is bad as truth.
That would be unreasonable on my part.

Peter

kangax

unread,
Jul 8, 2009, 12:47:10 PM7/8/09
to
Peter Michaux wrote:
> Thomas 'PointedEars' Lahn wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>
>>>> <http://validator.w3.org/#validate_by_input>
>
>> Apparently I picked a bad example. However, it is possible to make the
>> Back/Forward feature work with this, and there are sites that do that.
>
> The only way I know to do this is to poll the window.location property
> for changes. This polling is easy to do but it is unfortunate there is
> not a native window.onlocationchange event. I think that event will
> appear eventually.

There clearly is a demand for such thing. Fortunately, HTML5 defines
`hashchange` event on body and window:

<http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onhashchange>

>
> What other ways do you see?
>
>> Given that changing and preserving a document's state can work more
>> seamlessly if client-side scripting and DOM features are supported,
>> I cannot find anything wrong with this approach.
>
> For use on the general web, feature testing is required. I remember
> that feature testing for the Safari infinite loading state bug when
> setting the location.hash property was at least not obvious to me.
> Safari was really breaking a long standing feature of browsers.

Wouldn't it be possible to use hidden iframe to test hash setter
reloading a document? I'm not very happy with such solution, of course,
but it would most definitely be more reliable than sniffing (and might
detect similarly faulty browsers).

On the other hand, one shouldn't really need to detect this behavior, as
the faulty browser would simply degrade gracefully.

--
kangax

Matt Kruse

unread,
Jul 8, 2009, 1:50:40 PM7/8/09
to
On Jul 6, 11:26 am, Peter Michaux <petermich...@gmail.com> wrote:
> Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
> I doubt you do. They are applications. In many applications when you
> reopen them they return to the state they were last in. Wouldn't it be
> great to be able to bookmark a few different states and then open
> directly to those states?

Just a side note to this long and mostly fruitless discussion...

The "state" of a page is very open to interpretation. I think what you
are arguing for is for some intelligence on the part of the web site/
app in making sure that the url shown in the address bar will return
the user to a reasonable location to view what they are currently
viewing.

For example, if I compose an email in GMail and bookmark it halfway
through writing, I don't expect that bookmark to always take me back
to a half-written email. If I'm partially scrolled down through a long
document, I don't expect the url to take me back to the exact scroll
point.

If I'm looking through an interactive slideshow of pictures, I
wouldn't expect the url to return me to the exact picture I'm looking
at, but rather the beginning of the slideshow itself. You may think it
should go directly to the picture. The "right" way to handle it
depends on the users, the site/app, and context. It's those sites that
do it well and give users what they reasonably expect that become
popular.

Despite David's baseless objections, I think that intelligent use of
hashes to form a reusable/shareable url is a great thing. It's not
perfect, and it will probably be replaced in the future with a better
alternative, but for right now it works. And it's very handy. Use it,
but be sure to consider what your users expect to return to when they
are viewing any particular url.

I think that objections like "that's not what it's meant for" or "it
breaks my fast navigation" or "there are better ways to do it" are
irrelevant sometimes. Just like life, technical solutions evolve. They
are not designed from the top down to be strictly correct and logical.
What we work with in web design is a combination of thousands of
layers of technological innovations piled on top of each other over
decades of hacking and trying out new ideas. Not perfect, but good
enough. It is the imaginative use of old ideas for new purposes that
is the source of these innovations. Those who object to this
advancement because they don't fit within their strict, stale model of
how things "ought to be" will left behind to whine to people about the
"good ol days" like some old man, while the people who embrace it will
benefit from it and see greater ideas emerge. IMO.

Matt Kruse

Peter Michaux

unread,
Jul 8, 2009, 3:09:08 PM7/8/09
to
On Jul 8, 10:50 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jul 6, 11:26 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
> > I doubt you do. They are applications. In many applications when you
> > reopen them they return to the state they were last in. Wouldn't it be
> > great to be able to bookmark a few different states and then open
> > directly to those states?
>
> Just a side note to this long and mostly fruitless discussion...
>
> The "state" of a page is very open to interpretation. I think what you
> are arguing for is for some intelligence on the part of the web site/
> app in making sure that the url shown in the address bar will return
> the user to a reasonable location to view what they are currently
> viewing.

Yes that is what I'm suggesting.


> For example, if I compose an email in GMail and bookmark it halfway
> through writing, I don't expect that bookmark to always take me back
> to a half-written email.

Perhaps you don't expect that but...

Why are you bookmarking your half-written email? Are you bookmarking
it because you want to have GMail, in general, bookmarked? Do you
think the number of users who bookmark half way through writing an
email want to bookmark GMail in general or is it so infrequently used
that the ability to bookmark could be given a different goal?

What if that bookmark did return you to your half-written email? Would
that be bad? Perhaps you'd like it even though it wasn't what you
expected?


> If I'm partially scrolled down through a long
> document, I don't expect the url to take me back to the exact scroll
> point.

When I read long page like the HTML specifications, the ability to
bookmark a particular part of the page and return to it immediately is
a benefit to me. At least for an unchanging page, that is very close
to the concept of restoring the amount of page scroll. I can also post
a link here to the middle of a page:

http://www.w3.org/TR/html401/struct/lists.html#h-10.3.1


> If I'm looking through an interactive slideshow of pictures, I
> wouldn't expect the url to return me to the exact picture I'm looking
> at, but rather the beginning of the slideshow itself. You may think it
> should go directly to the picture. The "right" way to handle it
> depends on the users, the site/app, and context. It's those sites that
> do it well and give users what they reasonably expect that become
> popular.

Yes, in the end natural selection rules.


> Despite David's baseless objections, I think that intelligent use of
> hashes to form a reusable/shareable url is a great thing. It's not
> perfect, and it will probably be replaced in the future with a better
> alternative, but for right now it works.

Thanks to kangax's response in this thread, I now know that HTML 5 is
improving the use the hash for this purpose for the near future:

http://groups.google.com/group/comp.lang.javascript/msg/b6da13ee3dcf1fd3


> And it's very handy. Use it,
> but be sure to consider what your users expect to return to when they
> are viewing any particular url.
>
> I think that objections like "that's not what it's meant for" or "it
> breaks my fast navigation" or "there are better ways to do it" are
> irrelevant sometimes. Just like life, technical solutions evolve. They
> are not designed from the top down to be strictly correct and logical.
> What we work with in web design is a combination of thousands of
> layers of technological innovations piled on top of each other over
> decades of hacking and trying out new ideas. Not perfect, but good
> enough. It is the imaginative use of old ideas for new purposes that
> is the source of these innovations. Those who object to this
> advancement because they don't fit within their strict, stale model of
> how things "ought to be" will left behind to whine to people about the
> "good ol days" like some old man, while the people who embrace it will
> benefit from it and see greater ideas emerge. IMO.

I agree.

Not all new ideas are good ones or last even short tests of time. Some
ideas do. The reason I started this thread is it seems that URL hash-
setting has been perceived as useful by quite a few people and is
implementable in a large percentage of currently used browsers.

Peter

Peter Michaux

unread,
Jul 8, 2009, 3:11:50 PM7/8/09
to
kangax wrote:
> Peter Michaux wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
>
> >>>> <http://validator.w3.org/#validate_by_input>
>
> >> Apparently I picked a bad example. However, it is possible to make the
> >> Back/Forward feature work with this, and there are sites that do that.
>
> > The only way I know to do this is to poll the window.location property
> > for changes. This polling is easy to do but it is unfortunate there is
> > not a native window.onlocationchange event. I think that event will
> > appear eventually.
>
> There clearly is a demand for such thing. Fortunately, HTML5 defines
> `hashchange` event on body and window:
>
> <http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onhashchange>

Well there you go! Thanks for posting that link.

Peter

David Mark

unread,
Jul 8, 2009, 4:53:54 PM7/8/09
to
On Jul 8, 5:47 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >>> On Jul 6, 12:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >>>> On Jul 5, 11:49 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>> On Jul 5, 11:56 pm, Peter Michaux <petermich...@gmail.com> wrote:
> >>>>>> On Jul 5, 8:11 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>>>> 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,
> >>>>> 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.
> >>> 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>
>
> > Broken by design (try using the back button)
>
> OK, the Back button doesn't work as supposed.  That's a shame, indeed.

Yeah, a real shame. Been like that forever. I considered using it as
a (bad) example here, but it really doesn't apply, does it? It has
actual fragments, so rearranging them into a tabbed dialog is trivial
(and certainly shouldn't break the back button!)

>
> > and that site is a crock anyway
>
> I beg your pardon?

As in, a crock of shit. Have a look at the source. It's cutting edge
for 1999.

>
> > (what sort of reality check is that?)
>
> Apparently I picked a bad example.  However, it is possible to make the
> Back/Forward feature work with this, and there are sites that do that.

Of course there are. That is hardly an innovative design. We've
discussed such issues here many times (seems I'm the only one that
remembers the discussions.)

> Given that changing and preserving a document's state can work more
> seamlessly if client-side scripting and DOM features are supported,
> I cannot find anything wrong with this approach.

Except that it has nothing to do with this discussion and they blew it
anyway. Find a more appropriate example (and make sure it works.)

David Mark

unread,
Jul 8, 2009, 4:59:49 PM7/8/09
to
On Jul 8, 12:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
> Thomas 'PointedEars' Lahn wrote:
> > > Thomas 'PointedEars' Lahn wrote:
> > > > <http://validator.w3.org/#validate_by_input>
> > Apparently I picked a bad example.  However, it is possible to make the
> > Back/Forward feature work with this, and there are sites that do that.
>
> The only way I know to do this is to poll the window.location property
> for changes. This polling is easy to do but it is unfortunate there is
> not a native window.onlocationchange event. I think that event will
> appear eventually.

If you are talking about that W3C tabbed dialog, you aren't thinking
at all. Look closer. It's not like the other "innovations" discussed
in this thread. It's much closer to the tabs discussed in one of your
blog posts.

It's obvious what they did wrong. It's not that they set the location
(they are clearly averse to doing that.) It's that they didn't
prevent the default action (navigating to the fragment.) Of course,
you have to do some feature testing before doing that, else you will
break the document in cases where the tabs won't fly (or don't make
sense.) I didn't look at their script, but I doubt they did that
either.

>
> What other ways do you see?

The same way such enhancements have been done (and discussed here) for
years. Tabs for fragments isn't a new concept.

>
> > Given that changing and preserving a document's state can work more
> > seamlessly if client-side scripting and DOM features are supported,
> > I cannot find anything wrong with this approach.
>
> For use on the general web, feature testing is required. I remember
> that feature testing for the Safari infinite loading state bug when
> setting the location.hash property was at least not obvious to me.
> Safari was really breaking a long standing feature of browsers.
>

Why are you stuck on *setting* the location. Never needed that
before. Certainly don't need it here.

Peter Michaux

unread,
Jul 8, 2009, 5:07:16 PM7/8/09
to
On Jul 8, 1:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 12:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> > > > Thomas 'PointedEars' Lahn wrote:
> > > > > <http://validator.w3.org/#validate_by_input>
> > > Apparently I picked a bad example. However, it is possible to make the
> > > Back/Forward feature work with this, and there are sites that do that.
>
> > The only way I know to do this is to poll the window.location property
> > for changes. This polling is easy to do but it is unfortunate there is
> > not a native window.onlocationchange event. I think that event will
> > appear eventually.
>
> If you are talking about that W3C tabbed dialog,

I wasn't.


> Why are you stuck on *setting* the location.

I'm not stuck on it. I'm exploring it as an option to enhance the user
experience.

> Never needed that
> before. Certainly don't need it here.

No you don't need to set the location hash. (You don't need JavaScript
to do most things on the web.) The ability to set the location has is
there and it seems that for some applications, like Yahoo! Maps, doing
so enhances the user experience.

Peter

David Mark

unread,
Jul 8, 2009, 5:07:24 PM7/8/09
to
On Jul 8, 12:16 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 1:14 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 8, 4:02 am, Peter Michaux <petermich...@gmail.com> wrote:
> > > On Jul 8, 12:26 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > Now you say "all browsers" work?
>
> > > I have slipped up with the typing at least once in this thread.
> > > Without question, all browsers don't work well with hash-setting. As I
> > > mentioned and kangax confirmed, old version of Safari, for example,
> > > don't work well with hash-setting.
>
> > > Wherever I have written "all browsers work" without qualification, I
> > > have meant "all recent versions of the major browsers."
>
> > Which we both know carries no weight at all.
>
> No. I've always thought it carries a lot of weight. What works for
> "most" of the web is an important property of any technique. If
> feature testing can be layered on top then the technique can work well
> for a slightly higher group of people.

Of course, but this "technique" cannot be feature tested and there are
no tests for bad design decisions.

>
> It is almost assured that no script of even modest size, regardless of
> feature testing, will work in all browsers. It will work in the
> browsers where that script has been tested. It is unknown if it will
> work elsewhere as browser bugs come in a wide variety of strange
> flavors...some even you have never tasted.

That's ridiculous. I write mammoth scripts for a living (and
occasionally for the public) and am constantly and pleasantly
surprised when these beasts move cleanly from one agent (or
configuration) to the next (year after year.) That's what cross-
browser scripting is about. "It will work in the browsers where that
script has been tested" is a loser's mantra, more appropriate for the
old-style multi-browser scripts. And for even modest sized scripts?
When did you become such a defeatist?

>
> > I thought this case was
> > closed years ago.  Odd end-around gimmick, something you don't need,
> > known to cause problems, frequently mixed with browser sniffing, etc.
> > Why are we discussing this again?
>
> Because URL hash-setting navigation appears to add value to the user
> experience. As a user it has improved my user experience at least on
> Yahoo! Maps.

There are lots of other ways they could have improved your experience
in this area and remained competent. They chose not to and that is
their problem. Don't copy their blunder.

>
> Because if a technically sound approach exists to implement URL hash-
> setting then that is at least interesting.

How much can you analyze setting a property? And the end result is a
bad idea anyway.

David Mark

unread,
Jul 8, 2009, 5:13:55 PM7/8/09
to

No, because your example of Web developers writing to please
themselves is silly and I'm tired of going around in circles regarding
such nonsense.

>
> > > > > > Not in the whole history of Web browsers has that ever
> > > > > > worked.
>
> > > > > Again a statement not based on fact. With script, it works now in many
> > > > > browsers.
>
> > > > No, you seemingly misunderstand again (which seems impossible.)
> > > > Bookmarks have never preserved state.  Period.
>
> > > Without question, bookmarks have always preserved state. At the very
> > > least they preserve the state of the browser: which page the browser
> > > is showing.
>
> > OMFG.  I'll pretend you didn't write that.
>
> Why pretend I didn't write that? Because I'm right and it is contrary
> to your previous statement?

You sound like a child. The previous "argument" was also silly and
childish nonsense.

>
> > > Bookmarks have even preserved page state. Suppose I bookmark a page
> > > withhttp://example.com/asdf.html#one. When that page is loaded it
> > > will be scrolled into position. That is a restoration of the scroll
> > > state of the page.
>
> > Again, that's a *fragment*, which is what hashes are for.
>
> I don't understand why you are so worried that hashes were originally
> used for anchors. Many advances on the web have been made by using
> features for purposes that were not the original intent. Often this
> turns out to be bad but sometimes it turns out to be a great advance.

I'm not worried about a damned thing.

You've said that three times. Still carries no weight as I mentioned
that replacing the history entry doesn't help you simulate navigation,
which is apparently one of your main design goals. If you are
strictly trying to stash a string in the hash, use a #$%! cookie (for
the last time.)

>
>
>
> > > > > > It's just "Web2.0" script kiddie nonsense
>
> > > > > I think the name calling detracts from any technical points you are
> > > > > trying to make.
>
> > > > Who am I calling names?  Everyone will have figure out for themselves
> > > > if that shoe fits.  None of this is new, BTW.  The idea has been
> > > > floated, sunk and branded as "script kiddie" (or simply "backwards"
> > > > might be more to the point.)  Don't join *that* club.
>
> > > You haven't made any technical points about why hash-setting is a bad
> > > idea. You've done little more than say you just don't like it.
>
> > That's completely untrue.  I've described in detail how the design is
> > flawed, why it isn't needed and demonstrated that every example design
> > posted thus far is flawed and/or broken.
>
> You haven't made any demonstration of why the Yahoo Maps! design (not
> implementation) is broken. You've said it is not necessary which is
> true but not why it is broken.

They are the odd man out there, aren't they? Finally a point. I
haven't looked at it, but off the top of my head:

1. Breaks older (but not ancient) browsers
2. Users YUI, so your loser anthem applies (works only in browsers
where it has been tested.)

BTW, how many of the billion or so configurations of IE do you test?
What about the others? Where do you find the time?

David Mark

unread,
Jul 8, 2009, 5:17:15 PM7/8/09
to
On Jul 8, 12:38 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 1:34 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > And you should know by now that I know what I am talking
> > about in this area.
>
> I know you have some technical knowledge about browser scripting.

I think that goes without saying.

> Because you have some knowledge, I am certainly interested in any
> technical experience you have; however, just because you know and have
> shared some things you've learned about browser scripting, it doesn't
> mean I'll take your unjustified declarations of what is bad as truth.
> That would be unreasonable on my part.

Whatever. You said much the same thing during previous discussions
and eventually realized you were wrong. I don't have time to write a
book about this one issue. You've got enough to go on at this point.

David Mark

unread,
Jul 8, 2009, 5:18:36 PM7/8/09
to
On Jul 8, 12:47 pm, kangax <kan...@gmail.com> wrote:
> Peter Michaux wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
>
> >>>> <http://validator.w3.org/#validate_by_input>
>
> >> Apparently I picked a bad example.  However, it is possible to make the
> >> Back/Forward feature work with this, and there are sites that do that.
>
> > The only way I know to do this is to poll the window.location property
> > for changes. This polling is easy to do but it is unfortunate there is
> > not a native window.onlocationchange event. I think that event will
> > appear eventually.
>
> There clearly is a demand for such thing. Fortunately, HTML5 defines
> `hashchange` event on body and window:
>
> <http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onh...>

>
>
>
> > What other ways do you see?
>
> >> Given that changing and preserving a document's state can work more
> >> seamlessly if client-side scripting and DOM features are supported,
> >> I cannot find anything wrong with this approach.
>
> > For use on the general web, feature testing is required. I remember
> > that feature testing for the Safari infinite loading state bug when
> > setting the location.hash property was at least not obvious to me.
> > Safari was really breaking a long standing feature of browsers.
>
> Wouldn't it be possible to use hidden iframe to test hash setter
> reloading a document? I'm not very happy with such solution, of course,
> but it would most definitely be more reliable than sniffing (and might
> detect similarly faulty browsers).

Creative, but the design isn't worth it.

>
> On the other hand, one shouldn't really need to detect this behavior, as
>   the faulty browser would simply degrade gracefully.

Not exactly.

Peter Michaux

unread,
Jul 8, 2009, 5:19:52 PM7/8/09
to
On Jul 8, 2:07 pm, David Mark <dmark.cins...@gmail.com> wrote:

> I write mammoth scripts

How large is a "mammoth script"?


> for a living (and
> occasionally for the public) and am constantly and pleasantly
> surprised when these beasts move cleanly from one agent (or
> configuration) to the next (year after year.)

You never encounter any problems? *Never*?


> That's what cross-
> browser scripting is about. "It will work in the browsers where that
> script has been tested" is a loser's mantra,

No. It is true.

If I test a script in a browser and see that it works there then I am
sure that script works in that browser. That is pretty clear.

If I don't test script in a particular browser then I don't know that
it works there. The *only* way to know for sure is to test it.


> more appropriate for the
> old-style multi-browser scripts. And for even modest sized scripts?
> When did you become such a defeatist?
>
> > > I thought this case was
> > > closed years ago. Odd end-around gimmick, something you don't need,
> > > known to cause problems, frequently mixed with browser sniffing, etc.
> > > Why are we discussing this again?
>
> > Because URL hash-setting navigation appears to add value to the user
> > experience. As a user it has improved my user experience at least on
> > Yahoo! Maps.
>
> There are lots of other ways they could have improved your experience
> in this area and remained competent. They chose not to and that is
> their problem. Don't copy their blunder.

You have avoided stating what is wrong with the *design* of the Yahoo!
Maps page with regard to setting the URL hash.


> > Because if a technically sound approach exists to implement URL hash-
> > setting then that is at least interesting.
>
> How much can you analyze setting a property?

Are you implying the feature testing is completely possible? When did
you become such a defeatist? ;-)

Also all scripts are not destined for the general web. Some scripts
are used only on intranets and so feature testing is not necessarily
required or even desired.


> And the end result is a
> bad idea anyway.

Why do you find it offensive that the URL hash is changing as you
manipulate the state of a single page web-app? (I'm not asking about
modifying the history stack.)

Peter

David Mark

unread,
Jul 8, 2009, 5:31:45 PM7/8/09
to
On Jul 8, 1:50 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jul 6, 11:26 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
> > I doubt you do. They are applications. In many applications when you
> > reopen them they return to the state they were last in. Wouldn't it be
> > great to be able to bookmark a few different states and then open
> > directly to those states?
>
> Just a side note to this long and mostly fruitless discussion...

And what sort of fruit have you brought to the table?

>
> The "state" of a page is very open to interpretation. I think what you
> are arguing for is for some intelligence on the part of the web site/
> app in making sure that the url shown in the address bar will return
> the user to a reasonable location to view what they are currently
> viewing.

Rotten.

>
> For example, if I compose an email in GMail and bookmark it halfway
> through writing, I don't expect that bookmark to always take me back
> to a half-written email. If I'm partially scrolled down through a long
> document, I don't expect the url to take me back to the exact scroll
> point.

Not exactly fresh insights, but lucid at least.

>
> If I'm looking through an interactive slideshow of pictures, I
> wouldn't expect the url to return me to the exact picture I'm looking
> at, but rather the beginning of the slideshow itself. You may think it
> should go directly to the picture. The "right" way to handle it
> depends on the users, the site/app, and context. It's those sites that
> do it well and give users what they reasonably expect that become
> popular.

LOL. Getting popular is about advertising, not ridiculous JS
shenanigans.

>
> Despite David's baseless objections, I think that intelligent use of

As usual, you can't read to save your life. I guess my "baseless"
objections are like my "unwarranted" criticism of jQuery (which you
requested in the first place.)

> hashes to form a reusable/shareable url is a great thing.

It's a great thing! Read your posts aloud before sending.

> It's not
> perfect, and it will probably be replaced in the future with a better
> alternative, but for right now it works. And it's very handy.

It works! See above (or virtually any other post on this subject.)
It's very handy! Like hell. Use cookies, genius.

> Use it,
> but be sure to consider what your users expect to return to when they
> are viewing any particular url.

Oh sure, recommend something completely unneeded that is known to be
broken in recent browsers (with something better on the horizon
anyway.) What sort of an automatic rebuttal are you? Everything I
say, you come along and offer a contradiction, no matter how much of a
stretch. You sound like an idiot every time.

>
> I think that objections like "that's not what it's meant for" or "it
> breaks my fast navigation" or "there are better ways to do it" are
> irrelevant sometimes.

I think that your posts are irrelevant sometimes. Be fair, virtually
all of the time.

> Just like life, technical solutions evolve. They

Yeah, that's life. Again, invest in a tape recorder. See how you
sound spouting this BS.

> are not designed from the top down to be strictly correct and logical.

You have the phony intellectual act down pat.

> What we work with in web design is a combination of thousands of
> layers of technological innovations piled on top of each other over
> decades of hacking and trying out new ideas. Not perfect, but good
> enough. It is the imaginative use of old ideas for new purposes that
> is the source of these innovations.

You are welcome. Whose innovations are replacing all of your old bad
ideas (e.g. browser sniffing?)

> Those who object to this
> advancement because they don't fit within their strict, stale model of
> how things "ought to be" will left behind to whine to people about the
> "good ol days" like some old man, while the people who embrace it will
> benefit from it and see greater ideas emerge. IMO.

How out of touch are you? This hash-setting BS isn't even close to
new. It's from around 2006. It was BS then and it is BS now. End of
story.

And what the hell have you innovated in the last few years? Your
"toolbox" looks pretty stale and last I heard you were using jQuery
1.2 w/ browser sniffing. Go back to your carp pool.

Peter Michaux

unread,
Jul 8, 2009, 5:31:48 PM7/8/09
to
On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:

> No, because your example of Web developers writing to please
> themselves is silly and I'm tired of going around in circles regarding
> such nonsense.

It is common advice from successful companies of developers to write
applications that you would like to use yourself.


> > You haven't made any demonstration of why the Yahoo Maps! design (not
> > implementation) is broken. You've said it is not necessary which is
> > true but not why it is broken.
>
> They are the odd man out there, aren't they? Finally a point. I
> haven't looked at it, but off the top of my head:
>
> 1. Breaks older (but not ancient) browsers

Have you ever thought that by using new features that break a page in
older browsers, the number of user's might actually increase? I think
that is definitely the case.


> 2. Users YUI, so your loser anthem applies (works only in browsers
> where it has been tested.)

The use of YUI in the implementation has nothing to do the quality of
the design.


> BTW, how many of the billion or so configurations of IE do you test?
> What about the others? Where do you find the time?

I'm not sure if these are rhetorical questions or not. I don't test
many configurations. I test in some configurations.

In another message you were implying your scripts work in browsers
where you do not test the scripts. These questions imply other scripts
cannot be known to work in a give browser without testing in the given
browser.

Peter

David Mark

unread,
Jul 8, 2009, 5:35:18 PM7/8/09
to
> > <http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onh...>

>
> Well there you go! Thanks for posting that link.

They are doing it for the same reason as QSA (which wasn't a good idea
either.) If enough people do something stupid, other people will
eventually feel the urge to accommodate them (often to make money, but
not always.)

David Mark

unread,
Jul 8, 2009, 6:03:11 PM7/8/09
to
On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 1:28 am, David Mark wrote:
>

[snip]


>
> > I've
> > mentioned this six times already.  The containing document would have
> > state preserved as cookies as the hash is obviously *taken*.
>
> I think a cookie is a really awful way to preserve UI state.

Works great (and always has.)

> I've
> already mentioned why: can't bookmark or email it, can loose it by
> clearing or loosing cookies, loose it by changing browsers, etc.

"Lose" I assume. And it is irrelevant that the user is allowed to
clear the states of some or all visited documents. Don't be a control
freak. Also irrelevant regarding email. I told you how to do that.
The only competition for your "send a link to this very thing" is the
file menu, which most users couldn't find with a map.

[snip]

David Mark

unread,
Jul 8, 2009, 6:07:52 PM7/8/09
to
On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > No, because your example of Web developers writing to please
> > themselves is silly and I'm tired of going around in circles regarding
> > such nonsense.
>
> It is common advice from successful companies of developers to write
> applications that you would like to use yourself.
>
> > > You haven't made any demonstration of why the Yahoo Maps! design (not
> > > implementation) is broken. You've said it is not necessary which is
> > > true but not why it is broken.
>
> > They are the odd man out there, aren't they?  Finally a point.  I
> > haven't looked at it, but off the top of my head:
>
> > 1. Breaks older (but not ancient) browsers
>
> Have you ever thought that by using new features that break a page in
> older browsers, the number of user's might actually increase? I think
> that is definitely the case.

As you well know, I do that all the time. It's called progressive
enhancement. That's what feature testing is for (and it's not
warranted here, even if a practical test could be found.)

>
> > 2. Users YUI, so your loser anthem applies (works only in browsers
> > where it has been tested.)
>
> The use of YUI in the implementation has nothing to do the quality of
> the design.

It demonstrates that the design is strictly multi-browser, which is
yesterday's news now (thank God.)

>
> > BTW, how many of the billion or so configurations of IE do you test?
> > What about the others?  Where do you find the time?
>
> I'm not sure if these are rhetorical questions or not. I don't test
> many configurations. I test in some configurations.

That doesn't jibe with your theory about scripts working only where
they've been tested. How do you sleep at night?

>
> In another message you were implying your scripts work in browsers
> where you do not test the scripts.

It's an easily demonstrable fact.

> These questions imply other scripts
> cannot be known to work in a give browser without testing in the given
> browser.

That was *your* implication (and I've heard it before from others,
usually advocates of browser sniffing.)

David Mark

unread,
Jul 8, 2009, 6:16:05 PM7/8/09
to
On Jul 8, 5:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 2:07 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I write mammoth scripts
>
> How large is a "mammoth script"?

Typically tens of thousands of lines.

>
> > for a living (and
> > occasionally for the public) and am constantly and pleasantly
> > surprised when these beasts move cleanly from one agent (or
> > configuration) to the next (year after year.)
>
> You never encounter any problems? *Never*?

Obviously that's not the case. My track record is pretty uncanny in
this area though.

>
> > That's what cross-
> > browser scripting is about.  "It will work in the browsers where that
> > script has been tested" is a loser's mantra,
>
> No. It is true.

But the implication is defeatist.

>
> If I test a script in a browser and see that it works there then I am
> sure that script works in that browser. That is pretty clear.

Nope. You'd have to test a lot of configurations (too many for one
lifetime.)

>
> If I don't test script in a particular browser then I don't know that
> it works there. The *only* way to know for sure is to test it.

But that's not what you said.

>
>
>
> > more appropriate for the
> > old-style multi-browser scripts.  And for even modest sized scripts?
> > When did you become such a defeatist?
>
> > > > I thought this case was
> > > > closed years ago.  Odd end-around gimmick, something you don't need,
> > > > known to cause problems, frequently mixed with browser sniffing, etc.
> > > > Why are we discussing this again?
>
> > > Because URL hash-setting navigation appears to add value to the user
> > > experience. As a user it has improved my user experience at least on
> > > Yahoo! Maps.
>
> > There are lots of other ways they could have improved your experience
> > in this area and remained competent.  They chose not to and that is
> > their problem.  Don't copy their blunder.
>
> You have avoided stating what is wrong with the *design* of the Yahoo!
> Maps page with regard to setting the URL hash.

On the contrary, I've told you at least a dozen times. The whole
thing should be discarded as it is known to break recent browsers (and
there is no test.) Never mind that you don't need it for anything
anyway. Don't drink the hemlock.

>
> > > Because if a technically sound approach exists to implement URL hash-
> > > setting then that is at least interesting.
>
> > How much can you analyze setting a property?
>
> Are you implying the feature testing is completely possible? When did
> you become such a defeatist? ;-)

You have lost coherence at this point.

>
> Also all scripts are not destined for the general web.

Still gone.

> Some scripts
> are used only on intranets and so feature testing is not necessarily
> required or even desired.

Nope.

>
> > And the end result is a
> > bad idea anyway.
>
> Why do you find it offensive that the URL hash is changing as you
> manipulate the state of a single page web-app? (I'm not asking about
> modifying the history stack.)

Because I know it reloads the page (or worse) in some (even recent)
browsers and is completely unnecessary. What more reason do you need
to avoid it?

Peter Michaux

unread,
Jul 8, 2009, 6:35:24 PM7/8/09
to

Now we are getting to something meaty! Which browsers do you know that
reload the page (or worse) when setting the location.hash property?

Peter

Roger

unread,
Jul 8, 2009, 6:38:29 PM7/8/09
to
On Jul 8, 5:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 1:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 8, 12:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > Thomas 'PointedEars' Lahn wrote:
> > > > > Thomas 'PointedEars' Lahn wrote:
> > > > > > <http://validator.w3.org/#validate_by_input>
> > > > Apparently I picked a bad example.  However, it is possible to make the
> > > > Back/Forward feature work with this, and there are sites that do that.
>
> > > The only way I know to do this is to poll the window.location property
> > > for changes. This polling is easy to do but it is unfortunate there is
> > > not a native window.onlocationchange event. I think that event will
> > > appear eventually.
>
> > If you are talking about that W3C tabbed dialog,
>
> I wasn't.

Odd as you replied directly to Thomas' statement about that dialog.

[snip]

David Mark

unread,
Jul 8, 2009, 6:42:20 PM7/8/09
to

Yes, I noticed that too. The rebuttal seems automated and born of
frustration. :)

David Mark

unread,
Jul 8, 2009, 6:50:04 PM7/8/09
to

I'd classify it as nutty. Did you not read the thread (or the umpteen
similar that preceded it?)

For example:

http://groups.google.com/group/comp.lang.javascript/msg/1a118ade7b4800f2

Getting tiresome.

Peter Michaux

unread,
Jul 8, 2009, 6:50:49 PM7/8/09
to

I was replying about the concept of URL hash-setting. Not the
particular example PointedEars posted.

Peter

Roger

unread,
Jul 8, 2009, 6:55:32 PM7/8/09
to

Well, you did not make it clear. Getting a little tired of this
thread, especially since Google Groups is now complaining about my
"posting limit."

Peter Michaux

unread,
Jul 8, 2009, 7:06:00 PM7/8/09
to

Of course I knew about those older versions of Safari and Opera. I was
the one who brought them up in the first place. Kangax was very
helpful in reporting the version numbers.

Safari 2 and Opera 8.5 are not exactly recent or popular browsers on
the web. For the case of Safari 2, from what I was told by the Webkit
developers, Safari 2 has been auto-updated to Safari 3 on Mac OS 10.4.
Someone would need a very old operating system or refuse updates to
still have Safari 2 running. Anyone on OS 10.3 would have only Safari
1.x and so is probably using Firefox by now.

Don't interpret that as meaning I think those browsers don't matter at
all. I didn't write that. For some sites they might matter. For some
sites, an extremely conservative approach must be taken and even
script should be avoided all together.

On the other hand, for the target group of other sites, Safari 2 and
Opera 8.5 are ancient browsers and restricting certain script
possibilities would be more detrimental than beneficial.

It depends on the site.

Peter

Roger

unread,
Jul 8, 2009, 7:21:58 PM7/8/09
to
On Jul 8, 7:06 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Jul 8, 6:35 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Jul 8, 3:16 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Jul 8, 5:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > > Why do you find it offensive that the URL hash is changing as you
> > > > > manipulate the state of a single page web-app? (I'm not asking about
> > > > > modifying the history stack.)
>
> > > > Because I know it reloads the page (or worse) in some (even recent)
> > > > browsers and is completely unnecessary. What more reason do you need
> > > > to avoid it?
>
> > > Now we are getting to something meaty! Which browsers do you know that
> > > reload the page (or worse) when setting the location.hash property?
>
> > I'd classify it as nutty. Did you not read the thread (or the umpteen
> > similar that preceded it?)
>
> > For example:
>
> >http://groups.google.com/group/comp.lang.javascript/msg/1a118ade7b4800f2
>
> Of course I knew about those older versions of Safari and Opera. I was
> the one who brought them up in the first place. Kangax was very
> helpful in reporting the version numbers.

Then why did you ask? This is the silliest thread I've ever been in.

>
> Safari 2 and Opera 8.5 are not exactly recent or popular browsers on
> the web.

Well, Opera 8.5 is not exactly ancient. And it doesn't matter
anyway. There are plenty of these browsers out there. And you don't
need to do what breaks them anyway.

> For the case of Safari 2, from what I was told by the Webkit
> developers, Safari 2 has been auto-updated to Safari 3 on Mac OS 10.4.

So?

> Someone would need a very old operating system or refuse updates to
> still have Safari 2 running.

You do realize that a lot of Mac (as well as PC) users don't know what
an OS is? It's particularly true of Mac users as Macs don't foul up
as often, so the OS remains in the background (where it belongs.)
Picture the Little Old Lady from Pasadena. She wants to buy from your
site, but your idiot Web designers just sent her browser into an
infinite load or crashed it or whatever. You want to keep this stuff
as simple and predictable as possible. That's how you make scripts
fly (or gracefully bail out) in virtually any environment.

> Anyone on OS 10.3 would have only Safari
> 1.x and so is probably using Firefox by now.

What does that mean? I'm sorry, but I'm not buying into your psychic
abilities with regard to users of old Macs. That Little Old Lady has
never heard of Firefox.

>
> Don't interpret that as meaning I think those browsers don't matter at
> all. I didn't write that. For some sites they might matter. For some
> sites, an extremely conservative approach must be taken and even
> script should be avoided all together.

If you know what you are doing, you can have it both ways.

>
> On the other hand, for the target group of other sites, Safari 2 and
> Opera 8.5 are ancient browsers and restricting certain script
> possibilities would be more detrimental than beneficial.

You have to weigh the benefits. In this case, you've got nothing to
weigh against potential disaster and user frustration/confusion. For
the last time, leave the window location alone.

>
> It depends on the site.

That's an appropriately ambiguous note to close on (crossing my
fingers.)

Peter Michaux

unread,
Jul 8, 2009, 7:38:12 PM7/8/09
to
On Jul 8, 4:21 pm, Roger <roger.gilre...@gmail.com> wrote:
> On Jul 8, 7:06 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > On Jul 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > On Jul 8, 6:35 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > On Jul 8, 3:16 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > > On Jul 8, 5:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > > > Why do you find it offensive that the URL hash is changing as you
> > > > > > manipulate the state of a single page web-app? (I'm not asking about
> > > > > > modifying the history stack.)
>
> > > > > Because I know it reloads the page (or worse) in some (even recent)
> > > > > browsers and is completely unnecessary. What more reason do you need
> > > > > to avoid it?
>
> > > > Now we are getting to something meaty! Which browsers do you know that
> > > > reload the page (or worse) when setting the location.hash property?
>
> > > I'd classify it as nutty. Did you not read the thread (or the umpteen
> > > similar that preceded it?)
>
> > > For example:
>
> > >http://groups.google.com/group/comp.lang.javascript/msg/1a118ade7b4800f2
>
> > Of course I knew about those older versions of Safari and Opera. I was
> > the one who brought them up in the first place. Kangax was very
> > helpful in reporting the version numbers.
>
> Then why did you ask? This is the silliest thread I've ever been in.

To find out if David knew of any new versions that have problems.


> > Safari 2 and Opera 8.5 are not exactly recent or popular browsers on
> > the web.
>
> Well, Opera 8.5 is not exactly ancient. And it doesn't matter
> anyway. There are plenty of these browsers out there. And you don't
> need to do what breaks them anyway.
>
> > For the case of Safari 2, from what I was told by the Webkit
> > developers, Safari 2 has been auto-updated to Safari 3 on Mac OS 10.4.
>
> So?

Since OS 10.3 users are stuck on Safari 1.x and OS 10.4 users have
been auto updated to Safari 3, that means only those with auto update
disabled would have Safari 2.

Safari 1.x was not a very good browser so there is a good chance those
users have moved on to other browsers.

The market share of Safari 1.x and 2.x is miniscule.


> > Someone would need a very old operating system or refuse updates to
> > still have Safari 2 running.
>
> You do realize that a lot of Mac (as well as PC) users don't know what
> an OS is? It's particularly true of Mac users as Macs don't foul up
> as often, so the OS remains in the background (where it belongs.)
> Picture the Little Old Lady from Pasadena. She wants to buy from your
> site, but your idiot Web designers just sent her browser into an
> infinite load or crashed it or whatever. You want to keep this stuff
> as simple and predictable as possible. That's how you make scripts
> fly (or gracefully bail out) in virtually any environment.
>
> > Anyone on OS 10.3 would have only Safari
> > 1.x and so is probably using Firefox by now.
>
> What does that mean? I'm sorry, but I'm not buying into your psychic
> abilities with regard to users of old Macs. That Little Old Lady has
> never heard of Firefox.

Well there is no way to bring up browser statistics in c.l.js.


> > Don't interpret that as meaning I think those browsers don't matter at
> > all. I didn't write that. For some sites they might matter. For some
> > sites, an extremely conservative approach must be taken and even
> > script should be avoided all together.
>
> If you know what you are doing, you can have it both ways.

Sometimes. Sometimes you cannot have it both ways due technical
problems (e.g. lack of feature tests) or to limited development
dollars. The server-side developers cannot always develop both a
traditional HTML template-based site, and a JSON data API. It is often
one or the other and the successful boss will pick the JSON data API
if that means more customers will be happy with the final product.


> > On the other hand, for the target group of other sites, Safari 2 and
> > Opera 8.5 are ancient browsers and restricting certain script
> > possibilities would be more detrimental than beneficial.
>
> You have to weigh the benefits. In this case, you've got nothing to
> weigh against potential disaster and user frustration/confusion.

Yes there is something positive: enhancing the user experience by
keeping the state of the page up-to-date in the URL so it can be
bookmarked or emailed at any time. That is a compelling advantage.

Peter

Peter Michaux

unread,
Jul 8, 2009, 7:48:35 PM7/8/09
to
On Jul 8, 3:07 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > No, because your example of Web developers writing to please
> > > themselves is silly and I'm tired of going around in circles regarding
> > > such nonsense.
>
> > It is common advice from successful companies of developers to write
> > applications that you would like to use yourself.
>
> > > > You haven't made any demonstration of why the Yahoo Maps! design (not
> > > > implementation) is broken. You've said it is not necessary which is
> > > > true but not why it is broken.
>
> > > They are the odd man out there, aren't they? Finally a point. I
> > > haven't looked at it, but off the top of my head:
>
> > > 1. Breaks older (but not ancient) browsers
>
> > Have you ever thought that by using new features that break a page in
> > older browsers, the number of user's might actually increase? I think
> > that is definitely the case.
>
> As you well know, I do that all the time. It's called progressive
> enhancement. That's what feature testing is for (and it's not
> warranted here, even if a practical test could be found.)

The intention of feature detection and progressive enhancement is to
add JavaScript to the page without breaking the page. I wrote that
adding JavaScript that *breaks* the page in older browsers is fine if
the net number of users actually increases. Totally different.


> > > 2. Users YUI, so your loser anthem applies (works only in browsers
> > > where it has been tested.)
>
> > The use of YUI in the implementation has nothing to do the quality of
> > the design.
>
> It demonstrates that the design is strictly multi-browser, which is
> yesterday's news now (thank God.)

Regardless of hash-setting, using YUI on a particular page would make
the *implementation* of the page multi-browser. It doesn't make the
design multi-browser as a different implementation of a design could
work in more browsers.


> > > BTW, how many of the billion or so configurations of IE do you test?
> > > What about the others? Where do you find the time?
>
> > I'm not sure if these are rhetorical questions or not. I don't test
> > many configurations. I test in some configurations.
>
> That doesn't jibe with your theory about scripts working only where
> they've been tested. How do you sleep at night?

It jibes well. I test my scripts in some browsers/configurations. I
know my scripts work in those browser/configurations. I don't know
that my scripts work elsewhere.


> > In another message you were implying your scripts work in browsers
> > where you do not test the scripts.
>
> It's an easily demonstrable fact.

As you wrote, you sometimes encounter problems with your scripts and
so they don't always work. If you tested your scripts in those other
browsers, saw that your scripts don't work there, then you could fix
your scripts and *know* they work. You won't know without the test.
You can only guess which is a reasonable thing to do as endless
testing is not realistic. It is still guessing, however.

Peter

Roger

unread,
Jul 8, 2009, 7:57:40 PM7/8/09
to
On Jul 8, 7:48 pm, Peter Michaux <petermich...@gmail.com> wrote:

[snip retreads of previous posts]

>
> As you wrote, you sometimes encounter problems with your scripts and

Now, who doesn't? Virtually every time, I'm the one that finds them
(before they hit the testers.) In other words, I don't get a lot of
returns (and I write more scripts of more than a modest size.)

> so they don't always work. If you tested your scripts in those other
> browsers, saw that your scripts don't work there, then you could fix
> your scripts and *know* they work.

Problems are rarely a result of "other browsers." I find that if my
scripts work in FF and IE, the rest usually fall right into place.
And I'm not talking about slide shows.

> You won't know without the test.

I can be pretty damned sure and that usually turns out to be good
enough.

> You can only guess which is a reasonable thing to do as endless
> testing is not realistic. It is still guessing, however.

I have no idea what you mean. Endless testing has no practical
application. Constant testing (e.g. after every little change in
every browser) is a waste. I test when I'm ready and in a way I feel
is appropriate (varies by project.) It's not an exact science, but
it's hardly guessing either (my nearly non-existent bounce rate speaks
to that.)

Peter Michaux

unread,
Jul 8, 2009, 8:09:18 PM7/8/09
to
On Jul 8, 4:57 pm, Roger <roger.gilre...@gmail.com> wrote:
> On Jul 8, 7:48 pm, Peter Michaux <petermich...@gmail.com> wrote:

> > As you wrote, you sometimes encounter problems with your scripts and
>
> Now, who doesn't?

My point exactly. David has implied his scripts "just work" even if he
doesn't test them in a particular browser/configuration. Given the
number of bugs/browsers/configurations that have ever been in
existence, the chances are slim.


> Virtually every time, I'm the one that finds them
> (before they hit the testers.) In other words, I don't get a lot of
> returns (and I write more scripts of more than a modest size.)

That is great. Really a page doesn't have to work in every browser/
configuration on planet earth. No lost sales or complaints is the real
objective.


> > so they don't always work. If you tested your scripts in those other
> > browsers, saw that your scripts don't work there, then you could fix
> > your scripts and *know* they work.
>
> Problems are rarely a result of "other browsers." I find that if my
> scripts work in FF and IE, the rest usually fall right into place.

How exotic is your "the rest"? For example, are you testing early
versions of Safari, iCab, Ice Browser, etc? They have unique bugs that
testing in other browser will not reveal.


> > You won't know without the test.
>
> I can be pretty damned sure and that usually turns out to be good
> enough.

I agree. David seems to think he knows that his scripts work in
untested browsers.


> > You can only guess which is a reasonable thing to do as endless
> > testing is not realistic. It is still guessing, however.
>
> I have no idea what you mean. Endless testing has no practical
> application. Constant testing (e.g. after every little change in
> every browser) is a waste. I test when I'm ready and in a way I feel
> is appropriate (varies by project.) It's not an exact science, but
> it's hardly guessing either (my nearly non-existent bounce rate speaks
> to that.)

It is guessing to say a page works in browser/configuration X if you
haven't tested it there.

Peter

Roger

unread,
Jul 8, 2009, 8:21:05 PM7/8/09
to
On Jul 8, 8:09 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 4:57 pm, Roger <roger.gilre...@gmail.com> wrote:
>
> > On Jul 8, 7:48 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > As you wrote, you sometimes encounter problems with your scripts and
>
> > Now, who doesn't?
>
> My point exactly. David has implied his scripts "just work" even if he

For Christ's sake. As mentioned, I am David. This miserable thread
has exceeded my "posting limit" on Google (idiots.)

> doesn't test them in a particular browser/configuration. Given the
> number of bugs/browsers/configurations that have ever been in
> existence, the chances are slim.

But you are generalizing about nothing. I have specific evidence.
And that attitude is the typical paranoia of the inexperienced (for
them the chances are nil, even for a "hello world" app!) Where did
you pick that up?

>
> > Virtually every time, I'm the one that finds them
> > (before they hit the testers.)  In other words, I don't get a lot of
> > returns (and I write more scripts of more than a modest size.)
>
> That is great. Really a page doesn't have to work in every browser/
> configuration on planet earth. No lost sales or complaints is the real
> objective.

I don't follow. The idea is that my scripts are tested in lots of
browsers and configurations I've never tried. They don't come back
from the testers.

>
> > > so they don't always work. If you tested your scripts in those other
> > > browsers, saw that your scripts don't work there, then you could fix
> > > your scripts and *know* they work.
>
> > Problems are rarely a result of "other browsers."  I find that if my
> > scripts work in FF and IE, the rest usually fall right into place.
>
> How exotic is your "the rest"? For example, are you testing early
> versions of Safari, iCab, Ice Browser, etc? They have unique bugs that
> testing in other browser will not reveal.

You'd have to ask the testers on any given project. Some are more
thorough than others. And, of course, there's loads of published
script out there to test (and lots of people have done so.)

>
> > > You won't know without the test.
>
> > I can be pretty damned sure and that usually turns out to be good
> > enough.
>
> I agree. David seems to think he knows that his scripts work in
> untested browsers.

I am David (see above.) And because of experience, I can predict such
things with great accuracy for past, as well as future browsers (as
has been shown repeatedly.)

>
> > > You can only guess which is a reasonable thing to do as endless
> > > testing is not realistic. It is still guessing, however.
>
> > I have no idea what you mean.  Endless testing has no practical
> > application.  Constant testing (e.g. after every little change in
> > every browser) is a waste.  I test when I'm ready and in a way I feel
> > is appropriate (varies by project.)  It's not an exact science, but
> > it's hardly guessing either (my nearly non-existent bounce rate speaks
> > to that.)
>
> It is guessing to say a page works in browser/configuration X if you
> haven't tested it there.

Depends on who said it and how experienced they were at the time. You
could call it educated guessing, but even that's a stretch. Sometimes
you just know as you have experienced it before.

Peter Michaux

unread,
Jul 8, 2009, 8:34:46 PM7/8/09
to
On Jul 8, 5:21 pm, Roger <roger.gilre...@gmail.com> wrote:
> On Jul 8, 8:09 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Jul 8, 4:57 pm, Roger <roger.gilre...@gmail.com> wrote:
>
> > > On Jul 8, 7:48 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > As you wrote, you sometimes encounter problems with your scripts and
>
> > > Now, who doesn't?
>
> > My point exactly. David has implied his scripts "just work" even if he
>
> For Christ's sake.  As mentioned, I am David.

Oh. Hi David.

> This miserable thread
> has exceeded my "posting limit" on Google (idiots.)

With all your hatred of Google sites, why are you using theirs to post
to the news group? Why not use Mozilla's newsgroup reader or something
else?

Peter

Roger

unread,
Jul 8, 2009, 8:44:15 PM7/8/09
to
On Jul 8, 8:34 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 5:21 pm, Roger <roger.gilre...@gmail.com> wrote:
>
> > On Jul 8, 8:09 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Jul 8, 4:57 pm, Roger <roger.gilre...@gmail.com> wrote:
>
> > > > On Jul 8, 7:48 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > > As you wrote, you sometimes encounter problems with your scripts and
>
> > > > Now, who doesn't?
>
> > > My point exactly. David has implied his scripts "just work" even if he
>
> > For Christ's sake.  As mentioned, I am David.
>
> Oh. Hi David.

Hi.

>
> > This miserable thread
> > has exceeded my "posting limit" on Google (idiots.)
>
> With all your hatred of Google sites, why are you using theirs to post

You know that isn't true. Don't use such words to describe my
opinions about incompetently designed Websites. It just makes you
look silly.

> to the news group? Why not use Mozilla's newsgroup reader or something
> else?

Gee, because I don't feel like setting up an NNTP account since my
miserable ISP discontinued that service. Really none of your concern
though.

Peter Michaux

unread,
Jul 8, 2009, 8:59:44 PM7/8/09
to
On Jul 8, 5:44 pm, Roger <roger.gilre...@gmail.com> wrote:
> On Jul 8, 8:34 pm, Peter Michaux <petermich...@gmail.com> wrote:


> > > This miserable thread
> > > has exceeded my "posting limit" on Google (idiots.)
>
> > With all your hatred of Google sites, why are you using theirs to post
>
> You know that isn't true.

No I didn't. Your posts about the quality of Google's programming made
me think you wouldn't go anywhere near their products.


> > to the news group? Why not use Mozilla's newsgroup reader or something
> > else?
>
> Gee, because I don't feel like setting up an NNTP account since my
> miserable ISP discontinued that service.  Really none of your concern
> though.

So taken as a whole you actually like Google's service better than the
alternatives? That is contrary to the impression I get from your
frequent Google-bashing posts.

Peter

Roger

unread,
Jul 8, 2009, 9:05:09 PM7/8/09
to
On Jul 8, 8:59 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 5:44 pm, Roger <roger.gilre...@gmail.com> wrote:
>
> > On Jul 8, 8:34 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > This miserable thread
> > > > has exceeded my "posting limit" on Google (idiots.)
>
> > > With all your hatred of Google sites, why are you using theirs to post
>
> > You know that isn't true.
>
> No I didn't. Your posts about the quality of Google's programming made
> me think you wouldn't go anywhere near their products.

Do my comments about the quality of code imply hatred to you? You
take newsgroups a bit too seriously I think.

>
> > > to the news group? Why not use Mozilla's newsgroup reader or something
> > > else?
>
> > Gee, because I don't feel like setting up an NNTP account since my
> > miserable ISP discontinued that service.  Really none of your concern
> > though.
>
> So taken as a whole you actually like Google's service better than the
> alternatives?

As mentioned, none of your concern. I'm not granting interviews at
this time.

> That is contrary to the impression I get from your
> frequent Google-bashing posts.

I don't write such posts. I virtually never mention them unless asked
(or when they serve as a highly visible example of a specific blunder.)

David Mark

unread,
Jul 8, 2009, 9:39:05 PM7/8/09
to
On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > No, because your example of Web developers writing to please
> > themselves is silly and I'm tired of going around in circles regarding
> > such nonsense.
>
> It is common advice from successful companies of developers to write
> applications that you would like to use yourself.

I missed this one. What are "successful companies of developers?"
Can I assume you mean Web developers? Anyone who takes browser
scripting advice from Web developers deserves whatever they get. Use
jQuery, dude. It rocks!

[snip]

Peter Michaux

unread,
Jul 8, 2009, 10:13:02 PM7/8/09
to
On Jul 8, 6:39 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > No, because your example of Web developers writing to please
> > > themselves is silly and I'm tired of going around in circles regarding
> > > such nonsense.
>
> > It is common advice from successful companies of developers to write
> > applications that you would like to use yourself.
>
> I missed this one.  What are "successful companies of developers?"

Companies where the founders are developers.


> Anyone who takes browser
> scripting advice from Web developers deserves whatever they get.

You are a web developer and you give out advice frequently. Why should
anyone listen to you?

Peter

David Mark

unread,
Jul 8, 2009, 10:20:16 PM7/8/09
to
On Jul 8, 10:13 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 8, 6:39 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > No, because your example of Web developers writing to please
> > > > themselves is silly and I'm tired of going around in circles regarding
> > > > such nonsense.
>
> > > It is common advice from successful companies of developers to write
> > > applications that you would like to use yourself.
>
> > I missed this one.  What are "successful companies of developers?"
>
> Companies where the founders are developers.

Are they supposed to be more believable? Lots of developers are
incompetent (though some manage to overcome that handicap.)

>
> > Anyone who takes browser
> > scripting advice from Web developers deserves whatever they get.
>
> You are a web developer and you give out advice frequently.

Wrong on both counts. I used to give out advice frequently, but I
have never been a Web developer (they don't make enough money to
support my lifestyle.) ;)

> Why should
> anyone listen to you?

Why are you constantly asking me questions? How often do I
reciprocate? Apply that virtually everybody else in this business.
There you go.

Peter Michaux

unread,
Jul 8, 2009, 10:30:27 PM7/8/09
to
On Jul 8, 7:20 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 8, 10:13 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Jul 8, 6:39 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Jul 8, 5:31 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > > On Jul 8, 2:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > > On Jul 8, 12:32 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > > No, because your example of Web developers writing to please
> > > > > themselves is silly and I'm tired of going around in circles regarding
> > > > > such nonsense.
>
> > > > It is common advice from successful companies of developers to write
> > > > applications that you would like to use yourself.
>
> > > I missed this one.  What are "successful companies of developers?"
>
> > Companies where the founders are developers.
>
> Are they supposed to be more believable?  Lots of developers are
> incompetent (though some manage to overcome that handicap.)
>
>
>
> > > Anyone who takes browser
> > > scripting advice from Web developers deserves whatever they get.
>
> > You are a web developer and you give out advice frequently.
>
> Wrong on both counts.  I used to give out advice frequently, but I
> have never been a Web developer (they don't make enough money to
> support my lifestyle.)  ;)

Posting to Usenet through Google Groups is expensive? Google lets me
do it for free.

Peter

David Mark

unread,
Jul 8, 2009, 10:34:57 PM7/8/09
to

Is your life about posting to Usenet? Mine's not.

David Mark

unread,
Jul 8, 2009, 10:50:34 PM7/8/09
to

My ideas are free too:

http://alpha.forkjavascript.org/download.html

I may not be a Web developer, but I know Web developers. You sir are
no Web developer.

Matt Kruse

unread,
Jul 8, 2009, 10:58:36 PM7/8/09
to
On Jul 8, 4:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
> It works!  See above (or virtually any other post on this subject.)
> It's very handy!  Like hell.  Use cookies, genius.

Cookies don't solve the same problem. They are irrelevant.

> Oh sure, recommend something completely unneeded that is known to be
> broken in recent browsers (with something better on the horizon
> anyway.)

Oh I don't know, the concept works well for me. YMMV.

> How out of touch are you?  This hash-setting BS isn't even close to
> new.  It's from around 2006.  It was BS then and it is BS now.  End of
> story.

Again, it seems to work well for major web sites. And it works well
for me.

> And what the hell have you innovated in the last few years?

Various things.

Matt Kruse

It is loading more messages.
0 new messages