Prev: ECMA-262-3 in detail. Chapter 4. Scope chain.
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-03-22)
From: Jorge on 23 Mar 2010 12:38
On Mar 23, 5:22 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> You are deluded.

I'm not. You're giving air to IE and its bugs. You should better
attempt to asphyxiate it instead.
--
Jorge.
From: David Mark on 23 Mar 2010 12:48
Jorge wrote:
> On Mar 23, 5:22 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>> You are deluded.
>
> I'm not. You're giving air to IE and its bugs. You should better
> attempt to asphyxiate it instead.

There is a slight flaw in your scheme. It is a waste of time to attempt
the impossible. ;)

Get better, Jorge!
From: Thomas Allen on 23 Mar 2010 13:39
On Mar 21, 5:22 pm, David Mark <dmark.cins...(a)gmail.com> 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
From: Jorge on 23 Mar 2010 15:37
On Mar 23, 5:48 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> Get better, Jorge!

I'm all right. Thanks.
--
Jorge.
From: David Mark on 23 Mar 2010 15:40
Thomas Allen wrote:
> On Mar 21, 5:22 pm, David Mark <dmark.cins...(a)gmail.com> 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).
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ECMA-262-3 in detail. Chapter 4. Scope chain.
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-03-22)