If you think you must modify the hash, think again

D

David Mark

As I've said before, if you find yourself leaning towards a design that
modifies the location hash because you think that an app can't be
"modern" or "robust" or "fast" without such hack-ery, think again.
There's always a better design (and often it involves leveraging what
the browser does best, which is _browsing_).

I ran across this recently:-

http://stackoverflow.com/questions/1078501/keeping-history-of-hash-anchor-changes-in-javascript

It is a microcosm for everything that has gone wrong with "Web 2.0"
(quotes indicate that term is used to describe so many things it is
meaningless). These ridiculous "history managers" and "back button
fixers" (see Dojo and YUI) are self-imposed doom and gloom. Doesn't
work in IE < 8 (or IE8 compatibility views of course), also fails in
less-than-ancient Opera versions. Standardizing this nonsense with a
hash change event must have felt like validation for a clearly backwards
approach to Web application authoring, but it's just more folly. You
can't force users to upgrade their browsers to accommodate incompetent
designs (and some couldn't do it if they wanted to).
 
P

Peter Michaux

As I've said before, if you find yourself leaning towards a design that
modifies the location hash because you think that an app can't be
"modern" or "robust" or "fast" without such hack-ery, think again.
There's always a better design (and often it involves leveraging what
the browser does best, which is _browsing_).

Browsers are not just used to navigate around a collection of linked
documents anymore. Browsers are used as an application platform. Use
as an application platform is increasing, not decreasing.

Setting location.hash is a fine idea and I appreciate applications
like Gmail and Yahoo! Maps that use the technique. I hope to see more
web applications doing it and steadily improving browser support for
it.

- - -

You are also neglecting issues related to working in a difficult
development environment/team. Some folks might be willing to implement
your alternative design but others won't be. At that point the client-
side programmer may use hash setting as a compromise.

Peter
 
D

David Mark

Peter said:
Browsers are not just used to navigate around a collection of linked
documents anymore.

I know that. We've had this discussion already. :) The issue is _how_
it is done (and the prevailing trend has been to throw away all of the
advantages of _browsing_, which is not required to write robust
applications).
Browsers are used as an application platform.

Sure they are! I write applications for them every day. What I don't
do is program for failure by designing applications that must rely on a
heart-stopping number of hacks to shoehorn everything into one document
(and then barely work in a handful of observed environments and doing
God knows what in unknown environments).
Use
as an application platform is increasing, not decreasing.

Yes, until something more appropriate replaces Web browsing as the
application platform of choice (the Apple iPhone apps are a step in that
direction, which is why Apple doesn't even bother with a MobileMe
website). ;)
Setting location.hash is a fine idea and I appreciate applications
like Gmail and Yahoo! Maps that use the technique.

We've been over this. It is not a fine idea. It is a completely
backwards Wile E. Coyote type idea. The writing on the wall is clear.
Look at all of the ridiculous hoops you must jump through just to create
a half-ass cross-browser application. It doesn't make a whit of sense.
I defy anyone to read that StackOverflow interchange and not feel the
need to wonder just how crazy and misguided those people are.
I hope to see more
web applications doing it and steadily improving browser support for
it.

Why would you hope that? I hope people get a clue and realize they are
programming for failure. Why do you think the authors of Dojo and YUI
keep blaming old browsers for their incompetence (and calling for them
to be banned?) It would be laughable if it weren't so freaking irritating.
- - -

You are also neglecting issues related to working in a difficult
development environment/team.

I'm not neglecting anything. You seem to be assuming you can read my
mind (I get a lot of that). :)
Some folks might be willing to implement
your alternative design but others won't be.

That's as maybe. Some people think jQuery is an elegant design. It's a
crazy world.
At that point the client-
side programmer may use hash setting as a compromise.

They might. I'd sure as hell try to talk them out of it though. ;)
 
D

David Mark

David said:
I know that. We've had this discussion already. :) The issue is _how_
it is done (and the prevailing trend has been to throw away all of the
advantages of _browsing_, which is not required to write robust
applications).


Sure they are! I write applications for them every day. What I don't
do is program for failure by designing applications that must rely on a
heart-stopping number of hacks to shoehorn everything into one document
(and then barely work in a handful of observed environments and doing
God knows what in unknown environments).


Yes, until something more appropriate replaces Web browsing as the
application platform of choice (the Apple iPhone apps are a step in that
direction, which is why Apple doesn't even bother with a MobileMe
website). ;)


We've been over this. It is not a fine idea. It is a completely
backwards Wile E. Coyote type idea. The writing on the wall is clear.
Look at all of the ridiculous hoops you must jump through just to create
a half-ass cross-browser application. It doesn't make a whit of sense.
I defy anyone to read that StackOverflow interchange and not feel the
need to wonder just how crazy and misguided those people are.


Why would you hope that? I hope people get a clue and realize they are
programming for failure. Why do you think the authors of Dojo and YUI
keep blaming old browsers for their incompetence (and calling for them
to be banned?) It would be laughable if it weren't so freaking irritating.

And it's worth noting that it is the exact same situation with the
horribly ill-advised technique of downloading scripts via XHR and
evaluating them on the client side. I asked some of the Dojo guys why
they thought _that_ was a good idea (despite the fact that, as
implemented, it required either synchronous XHR or some horribly
convoluted workaround that completely changed their application at
deployment time). They said something along the lines of "because the
Web has applications now" and wondered aloud how I could have missed
that. Well, LOL; the Web (public and private) has had applications for
over a decade and I, for one, never encountered the need to resort to
such obviously flawed designs. YMMV. ;)
 
P

Peter Michaux

Sure they are! I write applications for them every day. What I don't
do is program for failure by designing applications that must rely on a
heart-stopping number of hacks to shoehorn everything into one document
(and then barely work in a handful of observed environments and doing
God knows what in unknown environments).

Putting a whole company's worth of tools into a single page certainly
doesn't work. Having GMail, Adsense, and Maps all in the same page
would be lunacy. GMail all in one page is not lunacy. It is great for
the user with sufficient horsepower and bandwidth. For others they do
provide a stripped down client.

Yes, until something more appropriate replaces Web browsing as the
application platform of choice (the Apple iPhone apps are a step in that
direction, which is why Apple doesn't even bother with a MobileMe
website). ;)

I would take Web apps in Safari over iPhone apps any day both from a
user and developer perspective.

We've been over this. It is not a fine idea. It is a completely
backwards Wile E. Coyote type idea.

:) Acme JavaScript Library.

Look at all of the ridiculous hoops you must jump through just to create
a half-ass cross-browser application.

Not really. These days, just set the location hash and poll it. For
users of new browsers the back button will work to navigate though the
DHTML page changes. For users of old browsers, the experience will be
different. Hitting the back button might mean going back a genuine
page. So what? That' is not the end of the world. This way the
application is not dependent on location hash setting but most users
can benefit from it.

Peter
 
D

David Mark

Peter said:
Putting a whole company's worth of tools into a single page certainly
doesn't work. Having GMail, Adsense, and Maps all in the same page
would be lunacy.

Yes. That would be taking the strategy to an obscene extreme (which is
the polar opposite of what I advocate).
GMail all in one page is not lunacy.

I didn't say it was. But you have to stop and think: what is a page?
It is great for
the user with sufficient horsepower and bandwidth.

I don't really see why you would need any extreme horsepower or
bandwidth to read and write email from a Web document (or documents).
But then, if Google wrote it... :) Why does everyone want to use
Google as an example. It's such a self-defeating proposition.
For others they do
provide a stripped down client.

Of course they do. They couldn't write a non-behemoth, so they ended up
writing a whole extra application. And, as is well-documented, they
have enough trouble maintaining one.
I would take Web apps in Safari over iPhone apps any day both from a
user and developer perspective.

I don't follow. Are you comparing desktop Safari to mobile Webkit?
That's apples and grapes.
:) Acme JavaScript Library.

Yep. It's what I call the Cult Of Programming by Observation and not
Understanding a Thing (COPOUT).

http://vids.myspace.com/index.cfm?fuseaction=vids.individual&VideoID=7622124
Not really. These days, just set the location hash and poll it.

That doesn't work in IE < 8 (or IE8's various compatibility modes),
which is a real downer as the Dojo folks (for example) often find
themselves recommending the forcing of compatibility mode (via a META)
to make applications built with older Dojo's (predating IE8 observation
marathons and re-workings) to "work".

http://n3.nabble.com/What-is-the-latest-on-Defect-10491-tp463125p463125.html

And don't click that link in the latest Opera unless you enjoy needless
aggravation. :)

Speaking of that bunch, get a load of this all-in-one-page wonder:-

http://www.dojofoundation.org/

This is what I'm talking about. All of those eyes (and hands) and where
are the brains? :)
For
users of new browsers the back button will work to navigate though the
DHTML page changes.

You said it. New browsers? Many users don't know what a browser is,
let alone that there are new ones. You can't force the general public
to update browsers and that fact should be considered from the start of
any design slated for the Web.
For users of old browsers, the experience will be
different.

Ain't that the truth? Broken would better describe the experience in
many common cases (and I'm talking about major browsers in heavy use today).
Hitting the back button might mean going back a genuine
page.

Having dealt with a project that did this recently, I can tell you it
may do all sorts of bizarre things. Going back to a "genuine page" is
the least of the worries. The fact is, the history gets all out of
sync, which breaks many useful browser features (e.g. the bookmarking
that seems to be the biggest concern of such designs). And the
inescapable truth is that there is virtually always a better way
(meaning one that does not break browsers for no good reason).
So what? That' is not the end of the world.

What is? Some say we will find out in a couple of years, but they are
likely just as nutty as those who think Web applications are the wave of
the future for anyone but hobbyists and scientists. ;)
This way the
application is not dependent on location hash setting but most users
can benefit from it.

Nice thought, but it doesn't match up with reality.
 
P

Peter Michaux

I don't really see why you would need any extreme horsepower or
bandwidth to read and write email from a Web document (or documents).
But then, if Google wrote it... :) Why does everyone want to use
Google as an example. It's such a self-defeating proposition.

People like using Google's apps as examples because people like using
Google's apps. I like using fully featured GMail more than a static
1997 webmail client.

Of course they do. They couldn't write a non-behemoth, so they ended up
writing a whole extra application. And, as is well-documented, they
have enough trouble maintaining one.

A lot of people do not have any trouble using GMail. I never have a
problem.

Apparently "There are several hundred thousands lines of javascript in
Gmail". I always think "several" means at least 4. That boggles my
mind. GCC is written in C and has a bit over a million lines of code.
To think that the GMail client, written in such a high-level language
like JavaScript, is getting even close to the size of GCC makes me
think something is wrong. Still, I like using GMail so I don't worry
too much.

I don't follow. Are you comparing desktop Safari to mobile Webkit?
That's apples and grapes.

I like using web apps with Safari on my iPhone than using iPhone apps
on my iPhone and not just by a little bit. I like the web apps a lot
more.

That doesn't work in IE < 8 (or IE8's various compatibility modes),

I haven't be experiencing any problems with IE < 8.

Speaking of that bunch, get a load of this all-in-one-page wonder:-

http://www.dojofoundation.org/

This is what I'm talking about. All of those eyes (and hands) and where
are the brains? :)

I agree that an information-based site like that, which would be
desirable to have indexed well by search engines, should not be done
with hash navigation. That is a really bad idea.

I think what they were going for was to show off dojo through their
own site.

You said it. New browsers? Many users don't know what a browser is,
let alone that there are new ones.

In some cases it doesn't matter much if users with new browsers and
users with old browsers have the same experience. The important part
is they all have a good experience.

You can't force the general public
to update browsers and that fact should be considered from the start of
any design slated for the Web.

For the general web. A lot of applications are behind login and
benefit more by using fancy features than being accessible to all.
That is a business call.

Having dealt with a project that did this recently, I can tell you it
may do all sorts of bizarre things. Going back to a "genuine page" is
the least of the worries. The fact is, the history gets all out of
sync,

Under what circumstances? I'm not experiencing any problems in my
tests.

Peter
 
D

David Mark

Peter said:
People like using Google's apps as examples because people like using
Google's apps. I like using fully featured GMail more than a static
1997 webmail client.



A lot of people do not have any trouble using GMail. I never have a
problem.

Apparently "There are several hundred thousands lines of javascript in
Gmail". I always think "several" means at least 4. That boggles my
mind. GCC is written in C and has a bit over a million lines of code.
To think that the GMail client, written in such a high-level language
like JavaScript, is getting even close to the size of GCC makes me
think something is wrong. Still, I like using GMail so I don't worry
too much.

Actually, I intended "iPhone apps" rather than "mobile Webkit".
I like using web apps with Safari on my iPhone than using iPhone apps
on my iPhone and not just by a little bit. I like the web apps a lot
more.

The iPhone apps are actually far more capable than Web apps (just on a
much smaller screen). Now imagine such a solution for the desktop,
without all of the browser scripting baggage to hold it back. That's
the future...
I haven't be experiencing any problems with IE < 8.

Then I assume you have used the ill-advised IFrame injection hack.
IE6/7 (and IE8 in IE7 compatibility mode) don't add the hash changes to
history. In fact, setting the hash and then attempting to read it back
(from either location.hash or location.href) often failed in my testing.
Older versions of Opera (e.g. some of 9.x) have similar problems. It's
a major can of worms that I never attempted to open (the abstraction
described on the label indicated a bad idea) until presented with a
project that was doing it.
I agree that an information-based site like that, which would be
desirable to have indexed well by search engines, should not be done
with hash navigation. That is a really bad idea.

Yes, that site gives new meaning to the word failure. That's the sort
of overzealous "Ajax at all costs" design that is ruining the Web.
I think what they were going for was to show off dojo through their
own site.

LOL. That tells you something about Dojo's cracked foundation (in terms
of code and contributor mindset). Try it with your browser slightly
smaller than whatever (high) resolution the author tested in. :)
In some cases it doesn't matter much if users with new browsers and
users with old browsers have the same experience. The important part
is they all have a good experience.

I agree 100%. My point is that users of old browsers will often have a
dreadful experience with this technique. I went through it all about a
week ago and my suspicions were confirmed in spades.
For the general web. A lot of applications are behind login and
benefit more by using fancy features than being accessible to all.
That is a business call.

But as there is virtually always a better design available, an informed
businessperson should not feel the urge to make that call. ;)
Under what circumstances? I'm not experiencing any problems in my
tests.

Just the simple act of setting the hash and reading it back is extremely
problematic. Some of the issues were described (and bizarre workarounds
proposed) in the cited StackOverflow exchange. All of those people
complaining that the end result didn't seem to work in IE6/7 were not
just whistling Dixie. I can confirm that there are major issues in
those browsers with relation to setting the hash with script. If you
set the hash and then can't read it back reliably (which I can
definitely confirm), it pretty much sinks the whole endeavor. I sure as
hell wouldn't inject an IFrame (as seen in ill-advised junk like YUI and
Dojo) or mess with Opera's navigation mode (also in YUI IIRC) to try to
make such an obvious non-starter start. ;)
 
J

Jorge

(...)
Just the simple act of setting the hash and reading it back is extremely
problematic.  Some of the issues were described (and bizarre workarounds
proposed) in the cited StackOverflow exchange.  All of those people
complaining that the end result didn't seem to work in IE6/7 were not
just whistling Dixie.  I can confirm that there are major issues in
those browsers with relation to setting the hash with script.  If you
set the hash and then can't read it back reliably (which I can
definitely confirm), it pretty much sinks the whole endeavor.  I sure as
hell wouldn't inject an IFrame (as seen in ill-advised junk like YUI and
Dojo) or mess with Opera's navigation mode (also in YUI IIRC) to try to
make such an obvious non-starter start.  ;)

I think that none of the many long-standing bugs in IEs are merely
accidents due to incompetence. Rather the opposite, I firmly believe
that most of them are bricks on the road clever and intentionally left
there -service pack after service pack- by M$ in order to handicap the
web and its potential, which M$ has always seen as a threat for their
OS business.

There's no need to be a genius in order to see that if the web ever
succeeded as an application delivery channel it would have been the
end for the proprietary Windows®™ API lock-in. That's why it's been
into M$ plans for the last so many years to lock and f*ck the browsers
API as much as possible in as obscure -and not too evident- as
possible ways.

You, Cornford, and so many others not only in this group but in the
whole web panorama are good living examples of M$'s intended effect,
whenever you advocate ditching a clever idea due to a certain IE
(in)compatibility.

This is exactly the same reason why there's no <canvas> in IEs: they
don't want the browsers API to provide such an essential
functionality. Think about it: there's no way but the <canvas> to draw
arbitrary pixels on-screen.

So in order to get out of this trap in which we've been for so long, I
think that the way forward for the web should not care the slightest
about working around any of the many of IE's misbehaviours. Instead,
think about killing IE forever. It deserves it.
 
R

Richard Cornford

On Mar 23, 10:05 am, Jorge wrote:
So in order to get out of this trap in which we've been for so
long, I think that the way forward for the web should not care
the slightest about working around any of the many of IE's
misbehaviours. Instead, think about killing IE forever. It
deserves it.

Dreaming of killing IE is futile. That action is not within your
power, or that of any web developers (individually or collectively).
The world will change (probably in unpredictable ways) but a
responsible web developer will learn to cope with the way things are
now rather then how they wish things to be.

For years there were people maintaining that only IE mattered; that it
was the de facto standard, the only really capable browser and that
there was no point in the extra work necessary to accommodate the
statistically insignificant number of user's of alternative browsers.
Those people were wrong when they said that, and proved wrong by the
passage of time. But arguing today that nobody should bother to
support IE is just repeating that mistake with a different subject. It
is arrogant to take such a position, and even more arrogant to think
that it might change anything.

Richard.
 
D

David Mark

Jorge said:
I think that none of the many long-standing bugs in IEs are merely
accidents due to incompetence. Rather the opposite, I firmly believe
that most of them are bricks on the road clever and intentionally left
there -service pack after service pack- by M$ in order to handicap the
web and its potential, which M$ has always seen as a threat for their
OS business.

No kidding.
There's no need to be a genius in order to see that if the web ever
succeeded as an application delivery channel it would have been the
end for the proprietary Windows®™ API lock-in.

And I don't think that it takes a genius to see that the Web as it sits
today (e.g. mashed up kiddie scripts running on top of invalid
documents) will ever be a serious application delivery channel.
Seriously. How crazy would you have to be to think mankind won't come
up with something better than follies jQueryUI, Dojo, etc. It is to
laugh. :)
That's why it's been
into M$ plans for the last so many years to lock and f*ck the browsers
API as much as possible in as obscure -and not too evident- as
possible ways.

I have little doubt there is truth to that.
You, Cornford, and so many others not only in this group but in the
whole web panorama are good living examples of M$'s intended effect,
whenever you advocate ditching a clever idea due to a certain IE
(in)compatibility.

I don't think you understand the reality that IE is the stock browser on
all Windows machines, many of which are used by people who don't know or
care what a browser is. Furthermore, even if they do know and are aware
of alternatives, they may not be able to change it if they wanted to.
Professionals recognize reality for what it is and deal with it.
Amateurs fantasize about other worlds (which in their minds often become
their concept of the "real world".)
This is exactly the same reason why there's no <canvas> in IEs: they
don't want the browsers API to provide such an essential
functionality. Think about it: there's no way but the <canvas> to draw
arbitrary pixels on-screen.

Who cares? That's not what Web browsers are for and it will never be
what Web browsers are for. The day is _not_ coming when you write the
next Photoshop to run in a Web browser. Just forget all such notions
and you'll be a less irritable individual. :)
So in order to get out of this trap in which we've been for so long, I
think that the way forward for the web should not care the slightest
about working around any of the many of IE's misbehaviours. Instead,
think about killing IE forever. It deserves it.

Neither you nor I has the power to kill a browser. And I don't care
what Crockford says about it. ;)
 
J

Jorge

I don't think you understand the reality that IE is the stock browser on
all Windows machines, many of which are used by people who don't know or
care what a browser is.  Furthermore, even if they do know and are aware
of alternatives, they may not be able to change it if they wanted to.
Professionals recognize reality for what it is and deal with it.
Amateurs fantasize about other worlds (which in their minds often become
their concept of the "real world".)


Who cares?  That's not what Web browsers are for and it will never be
what Web browsers are for.  The day is _not_ coming when you write the
next Photoshop to run in a Web browser.  Just forget all such notions
and you'll be a less irritable individual.  :)


Neither you nor I has the power to kill a browser.  And I don't care
what Crockford says about it.  ;)

Wrt the libraries you're missing the big picture: they compete to
provide a better API, but instead you only see and look at the(ir) low-
level code.

Wrt IEs bugs, the very same day the big sites stop providing IE-
specific work arounds in their code, M$ will be forced to fix them or
the users will be forced to upgrade to a better browser (!IE).

Wrt web apps, take a look at the programs in your "start" menu, and
you'll discover that ~ 90% of them could -as of today- very well and
easily be replaced by web apps. Even Photoshop which is not exactly
the best candidate for a web app, has already a web app version, as
you know. Less capable, yes, but it's there, and it's a start.

Wrt web apps, note that nowadays most people are already spending most
of their time @ the browser. IOW, the browser is already the preferred
app platform.

The web has already moved forward quite a bit lately, and is moving
forward even further, and will get there with or without M$,
regardless of IE. Currently M$'s best hope is not to be left behind.

Yours, Cornford's and many other's attitude is outdated and against
the web's best interests. :)
 
D

David Mark

Jorge said:
Wrt the libraries you're missing the big picture: they compete to
provide a better API, but instead you only see and look at the(ir) low-
level code.

No, Jorge, I am not missing any picture. I wrote one, remember?
Clearly I understand the concept of a higher-level abstraction. But
higher-level abstractions rest on lower-level abstractions, sort of like
the earth's crust rests on its core. And when the foundation is faulty,
these things ultimately shake and fall apart. Have you watched the news
(or browsed the Web) lately?

Clearly if the goal is to "save time" (and presumably money) by
abdicating responsibility for the code that sits just above the DOM
layer (e.g. the low-level library code), it doesn't make a whit of sense
for that code to be written according to the observations of the day.
It's like building a beach house at low tide, watching it get washed out
and away and then re-building it again in perpetuity. Get it?
Wrt IEs bugs, the very same day the big sites stop providing IE-
specific work arounds in their code, M$ will be forced to fix them or
the users will be forced to upgrade to a better browser (!IE).

You didn't read a word I said, did you?
Wrt web apps, take a look at the programs in your "start" menu, and
you'll discover that ~ 90% of them could -as of today- very well and
easily be replaced by web apps.

Not a chance. Most Web apps are incapable of providing basic
functionality for even a fleeting moment in time.
Even Photoshop which is not exactly
the best candidate for a web app, has already a web app version, as
you know. Less capable, yes, but it's there, and it's a start.

And what is it built atop? That's all I really need to know about it.
And how many professional graphics designers would opt for it over the
desktop version?
Wrt web apps, note that nowadays most people are already spending most
of their time @ the browser.

Except when they are doing something other than browsing. ;)
IOW, the browser is already the preferred
app platform.

That doesn't follow at all.
The web has already moved forward quite a bit lately, and is moving
forward even further, and will get there with or without M$,
regardless of IE. Currently M$'s best hope is not to be left behind.

I want the last few seconds of my life back. :)
Yours, Cornford's and many other's attitude is outdated and against
the web's best interests. :)

You are deluded.
 
T

Thomas Allen

As I've said before, if you find yourself leaning towards a design that
modifies the location hash because you think that an app can't be
"modern" or "robust" or "fast" without such hack-ery, think again.
There's always a better design (and often it involves leveraging what
the browser does best, which is _browsing_).

What you're not mentioning is that some developers use the location
hash to this effect because it allows them to use JavaScript to get
around all of the things that browsers do poorly, specifically
maintaining state and other data in a user session, and maintaining a
steady user interface. Any page-based approach involves page refreshes
rather than simple Ajax requests, wiping the page and interrupting the
user's activities.
Doesn't work in IE < 8 (or IE8 compatibility views of course)

Why do you say that? The technique I'm using works in IE6, 7, and
onward. Perhaps you're referring to the use of the new onhashchange
event being pushed...developers have been aping that for a while by
checking the hash's value at an interval.

Thomas
 
D

David Mark

Thomas said:
What you're not mentioning is that some developers use the location
hash to this effect because it allows them to use JavaScript to get
around all of the things that browsers do poorly, specifically
maintaining state and other data in a user session, and maintaining a
steady user interface.

As for maintaining state, there are myriad ways to accomplish that (e.g.
cookies, query strings, etc.) And lightweight documents don't interrupt
anything when navigating (even without fast history features). Often
there is no indication at all that a round trip has occurred (and with
fast history, often there is no round trip).
Any page-based approach involves page refreshes
rather than simple Ajax requests, wiping the page and interrupting the
user's activities.

There's really very little in the way of "wiping" for my apps/sites and
my host doesn't even give me an easy way to do far future expiration
dates on assets. Granted, if you load up on the http requests, you will
have problems, but cramming everything into one document and throwing
away all of the benefits of navigation is then just working around
self-imposed problems.
Why do you say that? The technique I'm using works in IE6, 7, and
onward.

What technique is that and what are you using it for? I've experimented
recently with IE8 in IE7 compatibility mode on XP and attempting to poll
for hash changes was a no-go. Apparently others have run into this,
hence the bizarre IFRAME injections.
Perhaps you're referring to the use of the new onhashchange
event being pushed...

No. That's clearly more reliable.
developers have been aping that for a while by
checking the hash's value at an interval.

Yes, that's what I'm talking about. Monkeying might be a better way to
describe it (at least for every implementation I've seen). ;)

If you feel you have a rock solid approach that works in IE < 8 (and
comparable modes), I'd be glad to give it a whirl on the same machine I
tested on. NM if it uses IFRAME's though (that's a disqualification as
far as I am concerned). But realize that IE is not the only issue, just
one observed failure. There was at least one strain of Opera 9.x that
failed miserably too. Unlike positive results, observed failures are
significant (and deal-breakers on the Web for all but the most ancient
browsers).
 
J

Jorge

What you're not mentioning is that some developers use the location
hash to this effect because it allows them to use JavaScript to get
around all of the things that browsers do poorly, specifically
maintaining state and other data in a user session, and maintaining a
steady user interface. Any page-based approach involves page refreshes
rather than simple Ajax requests, wiping the page and interrupting the
user's activities.


Why do you say that? The technique I'm using works in IE6, 7, and
onward. Perhaps you're referring to the use of the new onhashchange
event being pushed...developers have been aping that for a while by
checking the hash's value at an interval.

Exactly, absolutely.

And, the fact that state saved at whatever the client-side storage
means at your disposal, can't be sent along with a url:

mySite/myApp?someParams#someState
 
D

David Mark

Jorge said:
Exactly, absolutely.

Which bit are you heartily agreeing with?
And, the fact that state saved at whatever the client-side storage
means at your disposal, can't be sent along with a url:

mySite/myApp?someParams#someState

So what? Are you espousing some sort of one-size-fits-all application
design that is irretrievably hinged on setting the hash with script?
Show me any _specific_ design like that and I'll show you a better way...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top