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

On Jul 8, 12:32 pm, Peter Michaux <petermich...@xxxxxxxxx> wrote:
On Jul 8, 1:28 am, David Mark wrote:



On Jul 8, 3:37 am, Peter Michaux wrote:
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.

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

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.

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.


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.

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

Relevant Pages

  • Re: Alternating text
    ... > browsers, or if person A successively accesses the page on two browsers, ... succession. ... If the visitor has cookies ... > The defects of HTML and CSS have nothing to do with this. ...
    (alt.html)
  • Re: in operator and feature detection technique...
    ... it can be used and it is used this way (when the support for ... So your history begins not long before 2000 CE? ... _free_ updates then they are welcome to join into "Old Browsers User ... 1.0+) have always been languages that used prototype-based inheritance. ...
    (comp.lang.javascript)
  • David Mark, I got one for you
    ... IE6 and IE7 require the iframe hack, ... whether or not the hash is accessible. ... I obviously cannot manipulate the hash on page load (in the main ... browsers history ...
    (comp.lang.javascript)
  • Re: If you think you must modify the hash, think again
    ... Just the simple act of setting the hash and reading it back is extremely ... those browsers with relation to setting the hash with script. ... API as much as possible in as obscure -and not too evident- as ... care what a browser is. ...
    (comp.lang.javascript)
  • Re: IIS 6.0 not sending cookies to IE6
    ... there isn't anything in IIS to discriminate ... against particular browsers, either. ... gobble up cookie headers -- neither browser nor server can do anything about ... default.asp?page=2) and while doing that sends some cookies to the ...
    (microsoft.public.inetserver.iis)