IE9--the end of the line for browser sniffers?

D

David Mark

From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent). They all
have tons of rickety branches based on an "isIE" variable. Dojo, for
example, has hundreds of scripts, each with at least a few sniffs (some
have dozens) and they are all interdependent as hell (often one script
tries to work around the mistakes of others).

IE8 was a major blow, but I think IE9 will be the knockout. What can
they do but scrap the old junk and start over? So much for all of those
pretty widgets. :)
 
J

Joe Nine

Joe said:
Why? The useragent changes I've read about sound to be completely normal
and as expected. For example, "MSIE 8" is now "MSIE 9". Anyone looking
for that digit will see 8 is now 9.

http://blogs.msdn.com/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx

Read your post again and I see you're only saying that IE9 will be the
last of the versions that don't cause the useragent sniffers a problem.
Not that IE9 itself will cause a problem. I expect they'll start doing
what Opera 10 did (identify itself as 9.80). Microsoft already did that
with Win 7 which identifies itself as Win 6.1 instead of Win 7.
 
D

David Mark

Joe said:
Why? The useragent changes I've read about sound to be completely normal
and as expected. For example, "MSIE 8" is now "MSIE 9". Anyone looking
for that digit will see 8 is now 9.

Most of the isIE branches are based solely on IE, not its version.
Suddenly most of those bogus inferences will be wrong. ;)
 
D

David Mark

Joe said:
Read your post again and I see you're only saying that IE9 will be the
last of the versions that don't cause the useragent sniffers a problem.
Not that IE9 itself will cause a problem. I expect they'll start doing
what Opera 10 did (identify itself as 9.80). Microsoft already did that
with Win 7 which identifies itself as Win 6.1 instead of Win 7.

No, see my follow-up.
 
J

Joe Nine

David said:
Most of the isIE branches are based solely on IE, not its version.
Suddenly most of those bogus inferences will be wrong. ;)

Why? If the useragent still contains "MSIE" (and according to that link
I posted it does, so) where's the problem? You never actually stated why
people's "isIE" variables will no longer initialize correctly. You seem
to have heard something contradictory to that article but haven't
elaborated on it [enough for me to understand ;-)].
 
D

David Mark

Joe said:
Why? If the useragent still contains "MSIE" (and according to that link
I posted it does, so) where's the problem?

The problem is that the current batch of "major" libraries (plus tens of
thousands of little scripts floating around out there) make about a
million inferences between them based on the UA string containing
"MSIE". Many of those inferences will be wrong in IE9. Get the
picture? :)

I suppose a lot of them will tell the developers who have trusted in
these things to force IE9 into some sort of compatibility mode. That's
what Dojo does whenever people complain about IE8 breaking their huge
Web apps. No time to rewrite everything is there?
You never actually stated why
people's "isIE" variables will no longer initialize correctly.

You simply don't get it. The whole problem is that they will
"initialize correctly", which will break the scripts.
You seem
to have heard something contradictory to that article but haven't
elaborated on it [enough for me to understand ;-)].

Can you hear me now? :)
 
J

Joe Nine

David said:
Joe said:
Why? If the useragent still contains "MSIE" (and according to that link
I posted it does, so) where's the problem?

The problem is that the current batch of "major" libraries (plus tens of
thousands of little scripts floating around out there) make about a
million inferences between them based on the UA string containing
"MSIE". Many of those inferences will be wrong in IE9. Get the
picture? :)

I suppose a lot of them will tell the developers who have trusted in
these things to force IE9 into some sort of compatibility mode. That's
what Dojo does whenever people complain about IE8 breaking their huge
Web apps. No time to rewrite everything is there?
You never actually stated why
people's "isIE" variables will no longer initialize correctly.

You simply don't get it. The whole problem is that they will
"initialize correctly", which will break the scripts.
You seem
to have heard something contradictory to that article but haven't
elaborated on it [enough for me to understand ;-)].

Can you hear me now? :)

I guess I'm still too dumb. IE7 identified itself as "MSIE 7" and all
the isIE brigade were happy. IE8 identified itself as "MSIE 8" and they
remained happy. Now IE9 has followed the same strategy and as predicted
identified themselves as "MSIE 9", which will still allow isIE to
initialize properly. No problem that I can see there. If the user goes
into compatibility mode, it will identify itself as "MSIE 7" just like
IE8 did in compatibility mode.

I still don't see why you think that would break any libraries. I don't
even know why I'm pursuing this, I don't sniff for IE anyway, but I
think a really big piece of information might have been missing from
your post. As in, what problem sniffing IE9 as IE might cause.
 
D

David Mark

Joe said:
David said:
Joe said:
David Mark wrote:
Joe Nine wrote:
David Mark wrote:
From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent). They all
have tons of rickety branches based on an "isIE" variable. Dojo, for
example, has hundreds of scripts, each with at least a few sniffs
(some
have dozens) and they are all interdependent as hell (often one
script
tries to work around the mistakes of others).

IE8 was a major blow, but I think IE9 will be the knockout. What can
they do but scrap the old junk and start over? So much for all of
those
pretty widgets. :)
Why? The useragent changes I've read about sound to be completely
normal
and as expected. For example, "MSIE 8" is now "MSIE 9". Anyone looking
for that digit will see 8 is now 9.

Most of the isIE branches are based solely on IE, not its version.
Suddenly most of those bogus inferences will be wrong. ;)
Why? If the useragent still contains "MSIE" (and according to that link
I posted it does, so) where's the problem?

The problem is that the current batch of "major" libraries (plus tens of
thousands of little scripts floating around out there) make about a
million inferences between them based on the UA string containing
"MSIE". Many of those inferences will be wrong in IE9. Get the
picture? :)

I suppose a lot of them will tell the developers who have trusted in
these things to force IE9 into some sort of compatibility mode. That's
what Dojo does whenever people complain about IE8 breaking their huge
Web apps. No time to rewrite everything is there?
You never actually stated why
people's "isIE" variables will no longer initialize correctly.

You simply don't get it. The whole problem is that they will
"initialize correctly", which will break the scripts.
You seem
to have heard something contradictory to that article but haven't
elaborated on it [enough for me to understand ;-)].

Can you hear me now? :)

I guess I'm still too dumb.

Ignorance is not the same as stupidity.
IE7 identified itself as "MSIE 7" and all
the isIE brigade were happy.

Not really.
IE8 identified itself as "MSIE 8" and they
remained happy.

Definitely not. For example, huge applications were built on top of
Dojo 1.3. Many of them fell apart in IE8. And, of course, upgrading
Dojo to "keep up" was (and is) a nightmare. The Dojo developers have
taken to telling their users who can't or won't go through that ordeal
to force IE7 compatibility mode. Their excuse is that IE8 wasn't around
when Dojo 1.3 was written. But that's no excuse at all. It wasn't
around when My Library was written, either. ;) I didn't have to change
one line (of roughly 10,000).
Now IE9 has followed the same strategy and as predicted
identified themselves as "MSIE 9", which will still allow isIE to
initialize properly.

You don't get it. IE9 will have very different features, so the umpteen
thousand bad inferences in these things will be invalidated. It would
actually be better if IE9 did *not* "identify" as IE. Then they might
have a shot.
No problem that I can see there. If the user goes
into compatibility mode, it will identify itself as "MSIE 7" just like
IE8 did in compatibility mode.

Dojo, for example, has all sorts of problems with that too.
I still don't see why you think that would break any libraries.

Do you see now?
I don't
even know why I'm pursuing this, I don't sniff for IE anyway, but I
think a really big piece of information might have been missing from
your post. As in, what problem sniffing IE9 as IE might cause.

Something's missing alright, but not in my posts.
 
J

Joe Nine

David said:
Joe said:
David said:
Joe Nine wrote:
David Mark wrote:
Joe Nine wrote:
David Mark wrote:
From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent). They all
have tons of rickety branches based on an "isIE" variable. Dojo, for
example, has hundreds of scripts, each with at least a few sniffs
(some
have dozens) and they are all interdependent as hell (often one
script
tries to work around the mistakes of others).

IE8 was a major blow, but I think IE9 will be the knockout. What can
they do but scrap the old junk and start over? So much for all of
those
pretty widgets. :)
Why? The useragent changes I've read about sound to be completely
normal
and as expected. For example, "MSIE 8" is now "MSIE 9". Anyone looking
for that digit will see 8 is now 9.

Most of the isIE branches are based solely on IE, not its version.
Suddenly most of those bogus inferences will be wrong. ;)
Why? If the useragent still contains "MSIE" (and according to that link
I posted it does, so) where's the problem?
The problem is that the current batch of "major" libraries (plus tens of
thousands of little scripts floating around out there) make about a
million inferences between them based on the UA string containing
"MSIE". Many of those inferences will be wrong in IE9. Get the
picture? :)

I suppose a lot of them will tell the developers who have trusted in
these things to force IE9 into some sort of compatibility mode. That's
what Dojo does whenever people complain about IE8 breaking their huge
Web apps. No time to rewrite everything is there?

You never actually stated why
people's "isIE" variables will no longer initialize correctly.
You simply don't get it. The whole problem is that they will
"initialize correctly", which will break the scripts.

You seem
to have heard something contradictory to that article but haven't
elaborated on it [enough for me to understand ;-)].
Can you hear me now? :)
I guess I'm still too dumb.

Ignorance is not the same as stupidity.
IE7 identified itself as "MSIE 7" and all
the isIE brigade were happy.

Not really.
IE8 identified itself as "MSIE 8" and they
remained happy.

Definitely not. For example, huge applications were built on top of
Dojo 1.3. Many of them fell apart in IE8. And, of course, upgrading
Dojo to "keep up" was (and is) a nightmare. The Dojo developers have
taken to telling their users who can't or won't go through that ordeal
to force IE7 compatibility mode. Their excuse is that IE8 wasn't around
when Dojo 1.3 was written. But that's no excuse at all. It wasn't
around when My Library was written, either. ;) I didn't have to change
one line (of roughly 10,000).
Now IE9 has followed the same strategy and as predicted
identified themselves as "MSIE 9", which will still allow isIE to
initialize properly.

You don't get it. IE9 will have very different features, so the umpteen
thousand bad inferences in these things will be invalidated. It would
actually be better if IE9 did *not* "identify" as IE. Then they might
have a shot.
No problem that I can see there. If the user goes
into compatibility mode, it will identify itself as "MSIE 7" just like
IE8 did in compatibility mode.

Dojo, for example, has all sorts of problems with that too.
I still don't see why you think that would break any libraries.

Do you see now?
I don't
even know why I'm pursuing this, I don't sniff for IE anyway, but I
think a really big piece of information might have been missing from
your post. As in, what problem sniffing IE9 as IE might cause.

Something's missing alright, but not in my posts.

Now I get it, because of this (new) info:

"huge applications were built on top of Dojo 1.3. Many of them fell
apart in IE8"

"IE9 will have very different features, so the umpteen thousand bad
inferences in these things will be invalidated. It would actually be
better if IE9 did *not* "identify" as IE"

We don't all know that IE8 broke Dojo in a big way, or that IE9 will be
so different. Neither things were mentioned in the initial post ;-)

Thanks for providing the extra info that fills in the gaps of the first
post :)
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
september.org>, Wed, 19 May 2010 09:02:14, David Mark
From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent). They all
have tons of rickety branches based on an "isIE" variable. Dojo, for
example, has hundreds of scripts, each with at least a few sniffs (some
have dozens) and they are all interdependent as hell (often one script
tries to work around the mistakes of others).

IE8 was a major blow, but I think IE9 will be the knockout. What can
they do but scrap the old junk and start over? So much for all of those
pretty widgets. :)


I expect that it will still be possible to detect it as an IE by using
isIE = !+0.7.toFixed()
or
S = "1000000000000000000000000" ;
+(S+" ") != +(S+".0") ;
 
D

David Mark

Dr said:
In comp.lang.javascript message <[email protected]
september.org>, Wed, 19 May 2010 09:02:14, David Mark



I expect that it will still be possible to detect it as an IE by using
isIE = !+0.7.toFixed()
or
S = "1000000000000000000000000" ;
+(S+" ") != +(S+".0") ;

But what would you infer from that (other than the obvious?)
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
september.org>, Thu, 20 May 2010 21:19:27, David Mark
But what would you infer from that (other than the obvious?)

That the browser is either IE, or a clone so faithful that it ought to
be treated as IE.

That Microsoft is careless.

I don't know whether you consider one of those, or something else, to be
obvious.

One can also check VBScript DatePart; in IE 4-8 there is a bug that MS
have known about for years - their bug fix article contains "Last
Review: June 24, 2004 - Revision: 3.0" (the fix routine gives correct
results, but is lousy in design). But that's not needed to detect IE,
unless any other browsers do VBScript. The bug is, of course, shared
with WSH VBS, MS Word, MS Excel at least. However, it is relatively
unlikely to affect American residents.
 
D

David Mark

In comp.lang.javascript message <[email protected]
september.org>, Thu, 20 May 2010 21:19:27, David Mark
<[email protected]> posted:







That the browser is either IE, or a clone so faithful that it ought to
be treated as IE.

What does "treated as IE" mean? Assume that other observations you
made today are going to be valid in the future? This is what I'm
talking about.
That Microsoft is careless.

Yes, that and a buck fifty will buy you a cup of coffee.
I don't know whether you consider one of those, or something else, to be
obvious.

Why are you trying to sniff out IE in the first place? That's the
rub.
One can also check VBScript DatePart; in IE 4-8 there is a bug that MS
have known about for years - their bug fix article contains "Last
Review: June 24, 2004 - Revision: 3.0" (the fix routine gives correct
results, but is lousy in design).  But that's not needed to detect IE,
unless any other browsers do VBScript.  The bug is, of course, shared
with WSH VBS, MS Word, MS Excel at least.  However, it is relatively
unlikely to affect American residents.

Oh good. :)
 
D

Dr J R Stockton

In comp.lang.javascript message <b9bfa123-c3fb-4e0c-86ae-ef2cfa6548fc@m3
3g2000vbi.googlegroups.com>, Sat, 22 May 2010 16:28:33, David Mark
On May 22, 12:28 pm, Dr J R Stockton <[email protected]>
wrote:

What does "treated as IE" mean? Assume that other observations you
made today are going to be valid in the future? This is what I'm
talking about.

One can never trust the future. For example, I know of at least one
case in which a browser was 262-compliant, but did not in later versions
remain so.

Yes, that and a buck fifty will buy you a cup of coffee.

Not round here. It would be of more than $1.50 quality; and they'd want
proper money too.

Why are you trying to sniff out IE in the first place? That's the
rub.



It should not be done in finished code, but it can be rather useful in
cross-browser testing : switch off one part that gives difficulty in IE
and continue on easier IE work, knowing that the expert on IE will be
back tomorrow or hoping that the newsgroup will be able to help.


Never trust anyone here who types faster than he can think.
 
R

RobG

From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent). They all
have tons of rickety branches based on an "isIE" variable. Dojo, for
example, has hundreds of scripts, each with at least a few sniffs (some
have dozens) and they are all interdependent as hell (often one script
tries to work around the mistakes of others).

Maybe it's the end of SharePoint too?

| function GetInnerText(e)
| {
| if (browseris.safari)
| return e.innerHTML;
| else if (browseris.nav)
| return e.textContent;
| else
| return e.innerText;
| }


It takes effort to screw up such a simple function so badly. The sniff
for ".nav" is amusing too (my wrapping):

| this.nav=((agt.indexOf('mozilla')!=-1)&&
| ((agt.indexOf('spoofer')==-1) &&
| (agt.indexOf('compatible')==-1)));
| this.nav6=this.nav && (this.major==5);
| this.nav6up=this.nav && (this.major >=5);
| this.nav7up=false;

Love that last line.

There are whole slabs of this stuff that are full of howlers, have a
look at it sometime. And these guys write operating systems.
 
D

David Mark

RobG said:
Maybe it's the end of SharePoint too?

| function GetInnerText(e)
| {
| if (browseris.safari)
| return e.innerHTML;

Sure. In "Safari" (and I guess Chrome too), HTML and text are
equivalent. :)
| else if (browseris.nav)
| return e.textContent;
| else
| return e.innerText;
| }


It takes effort to screw up such a simple function so badly. The sniff
for ".nav" is amusing too (my wrapping):

Too much. :)
| this.nav=((agt.indexOf('mozilla')!=-1)&&
| ((agt.indexOf('spoofer')==-1) &&
| (agt.indexOf('compatible')==-1)));

So if it has "mozilla", but *not* "compatible", then it must be
compatible with Mozilla. This is the worst thing I've ever seen. I
keep thinking I've seen the worst (e.g. Dojo was my most recent
candidate) and then something like this comes alone. :)
| this.nav6=this.nav && (this.major==5);
| this.nav6up=this.nav && (this.major >=5);
| this.nav7up=false;

Love that last line.

Feeling 7-Up, I'm feeling 7-Up...


They are so fired.
There are whole slabs of this stuff that are full of howlers, have a
look at it sometime. And these guys write operating systems.

Poorly last I checked. Granted, I haven't seen their latest. It sure
as hell wasn't my idea. :)
 
S

S.T.

From what I've heard of IE9, it sure seems to spell doom for Dojo,
ExtJs, YUI, etc. And jQuery too (at least to some extent).

FWIW, ran most aspects of my jQuery-heavy websites and extranet apps
through the the IE9 Platform Preview and not seeing any issues
whatsoever. Not even issues with jQueryUI library, which I'm still not
sold on as release-ready but use in controlled environments sometimes.

Dojo, YUI, ExtJS... don't know, don't care.
 
D

David Mark

FWIW, ran most aspects of my jQuery-heavy websites and extranet apps
through the the IE9 Platform Preview and not seeing any issues
whatsoever.

It's not worth a plugged nickel. jQuery doesn't use UA sniffing (and
still no thank you card from them). They use bogus object inferences,
which are less likely to be affected by what I described. But your
empirical evidence gathered with the preview
edition and your "jQuery-heavy" websites is virtually worthless.

The library authors use similar "logic" in their code. Often the only
justification for their actions (or lack thereof) is that the code
doesn't appear to fail in the three or four browsers they "care"
about. Do you not see the fallacy in (and futility of) such
thinking? The trail of wrecked browsers in their rear view mirrors
should clue *them* in at least. But rather than learn anything from
their mistakes, they just stop caring about whatever it was they
couldn't figure out and move on to the next set of observation-based
inferences.

See the endless rewrites and still no end in sight. See the virtually
mandatory "upgrades" that virtually always break compatibility. They
don't know when they are breaking their own compatibility any more
than they know when they've lopped off another browser (or
configuration). And these are the people you are leaning on for
browser scripting? They are going to somehow save you time? Good
luck with that strategy.
Not even issues with jQueryUI library, which I'm still not
sold on as release-ready but use in controlled environments sometimes.

You are making a huge mistake with that crap. It's been proven that
not only is the jQuery core crawling with bugs, but the authors are
completely clueless about them. You can't even explain the bugs to
them. So how is it that widgets built atop this refuse are immune?
Furthermore, IIRC, the widgets (like most 3rd-party jQuery tack-ons)
rely on the UA string.

Where's the bad pebble in the beach? Can't find it? It must not
exist! Sifted every grain and nothing's there? Guess it is safe to
assume there never will be. And, gee that must have taken about an
infinite amount of time. Never mind, feel free to frolic barefoot
forever! S.T. says all clear! :)

I say wear shoes. They aren't hard to come by and think of the time
you will save. ;)
Dojo, YUI, ExtJS... don't know, don't care.

Oddly enough, I don't care that you don't care. :)
 
D

David Mark

In comp.lang.javascript message <b9bfa123-c3fb-4e0c-86ae-ef2cfa6548fc@m3
3g2000vbi.googlegroups.com>, Sat, 22 May 2010 16:28:33, David Mark
<[email protected]> posted:







One can never trust the future.  For example, I know of at least one
case in which a browser was 262-compliant, but did not in later versions
remain so.

Nothing is guaranteed of course. The batteries could go dead in your
smoke detectors, but that doesn't mean you shouldn't use them.
Not round here.  It would be of more than $1.50 quality; and they'd want
proper money too.

What does that mean?
It should not be done in finished code, but it can be rather useful in
cross-browser testing : switch off one part that gives difficulty in IE
and continue on easier IE work, knowing that the expert on IE will be
back tomorrow or hoping that the newsgroup will be able to help.

There are better ways to do that (e.g. conditional compilation).
Never trust anyone here who types faster than he can think.

And how are you to gauge posters' typing speed?
 
G

Garrett Smith

It's not worth a plugged nickel. jQuery doesn't use UA sniffing (and
still no thank you card from them).

To whom might that "thank you" card be most appropriately delivered?
 

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

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top