If you think you must modify the hash, think again

Discussion in 'Javascript' started by David Mark, Mar 21, 2010.

  1. David Mark

    David Mark Guest

    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).
    David Mark, Mar 21, 2010
    #1
    1. Advertising

  2. On Mar 21, 3:22 pm, David Mark <> wrote:
    > 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
    Peter Michaux, Mar 21, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    Peter Michaux wrote:
    > On Mar 21, 3:22 pm, David Mark <> wrote:
    >> 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.


    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. ;)
    David Mark, Mar 21, 2010
    #3
  4. David Mark

    David Mark Guest

    David Mark wrote:
    > Peter Michaux wrote:
    >> On Mar 21, 3:22 pm, David Mark <> wrote:
    >>> 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.

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


    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. ;)
    David Mark, Mar 21, 2010
    #4
  5. On Mar 21, 4:09 pm, David Mark <> wrote:
    > Peter Michaux wrote:
    > > On Mar 21, 3:22 pm, David Mark <> wrote:


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


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


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


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


    :) 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
    Peter Michaux, Mar 21, 2010
    #5
  6. David Mark

    David Mark Guest

    Peter Michaux wrote:
    > On Mar 21, 4:09 pm, David Mark <> wrote:
    >> Peter Michaux wrote:
    >>> On Mar 21, 3:22 pm, David Mark <> wrote:

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


    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.

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

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

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

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

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


    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.
    David Mark, Mar 21, 2010
    #6
  7. On Mar 21, 5:05 pm, David Mark <> wrote:
    > Peter Michaux wrote:
    > > On Mar 21, 4:09 pm, David Mark <> wrote:
    > >> Peter Michaux wrote:
    > >>> On Mar 21, 3:22 pm, David Mark <> wrote:


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


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


    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.


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

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


    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.


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


    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.


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


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

    Peter
    Peter Michaux, Mar 22, 2010
    #7
  8. David Mark

    David Mark Guest

    Peter Michaux wrote:
    > On Mar 21, 5:05 pm, David Mark <> wrote:
    >> Peter Michaux wrote:
    >>> On Mar 21, 4:09 pm, David Mark <> wrote:
    >>>> Peter Michaux wrote:
    >>>>> On Mar 21, 3:22 pm, David Mark <> wrote:

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

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


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

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

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

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


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

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


    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.

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


    But as there is virtually always a better design available, an informed
    businessperson should not feel the urge to make that call. ;)

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

    >
    > 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. ;)
    David Mark, Mar 23, 2010
    #8
  9. David Mark

    Jorge Guest

    On Mar 23, 9:55 am, David Mark <> wrote:
    > (...)
    > 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.
    --
    Jorge.
    Jorge, Mar 23, 2010
    #9
  10. On Mar 23, 10:05 am, Jorge wrote:
    <snip>
    > 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.
    Richard Cornford, Mar 23, 2010
    #10
  11. David Mark

    David Mark Guest

    Jorge wrote:
    > On Mar 23, 9:55 am, David Mark <> wrote:
    >> (...)
    >> 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.


    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. ;)
    David Mark, Mar 23, 2010
    #11
  12. Richard Cornford, Mar 23, 2010
    #12
  13. David Mark

    Jorge Guest

    On Mar 23, 2:07 pm, David Mark <> wrote:
    >
    > 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. :)
    --
    Jorge.
    Jorge, Mar 23, 2010
    #13
  14. David Mark

    David Mark Guest

    Jorge wrote:
    > On Mar 23, 2:07 pm, David Mark <> wrote:
    >> 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.


    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.
    David Mark, Mar 23, 2010
    #14
  15. David Mark

    Thomas Allen Guest

    On Mar 21, 5:22 pm, David Mark <> wrote:
    > 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
    Thomas Allen, Mar 23, 2010
    #15
  16. David Mark

    David Mark Guest

    Thomas Allen wrote:
    > On Mar 21, 5:22 pm, David Mark <> wrote:
    >> 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.


    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.

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


    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).
    David Mark, Mar 23, 2010
    #16
  17. David Mark

    Jorge Guest

    On Mar 23, 6:39 pm, Thomas Allen <> wrote:
    > On Mar 21, 5:22 pm, David Mark <> wrote:
    >
    > > 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.


    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
    --
    Jorge.
    Jorge, Mar 23, 2010
    #17
  18. David Mark

    David Mark Guest

    Jorge wrote:
    > On Mar 23, 6:39 pm, Thomas Allen <> wrote:
    >> On Mar 21, 5:22 pm, David Mark <> wrote:
    >>
    >>> 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.

    >
    > 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...
    David Mark, Mar 23, 2010
    #18
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. NeoGeoSNK
    Replies:
    25
    Views:
    921
    NeoGeoSNK
    Nov 24, 2006
  2. Replies:
    0
    Views:
    597
  3. Replies:
    1
    Views:
    864
    Jack Klein
    Apr 13, 2005
  4. rp
    Replies:
    1
    Views:
    513
    red floyd
    Nov 10, 2011
  5. Srijayanth Sridhar
    Replies:
    19
    Views:
    610
    David A. Black
    Jul 2, 2008
Loading...

Share This Page