Opera gets no respect it seems

[David Mark]

As I have recently come to appreciate Opera 10's speed (particularly for
JSLint), I have taken to using it occasionally (Chrome is now my
primary). I can't stand the rest of them. My primary workstation is
fairly old and slow and FF 3.x and IE are pretty sluggish on it. An
interesting aside is that FF1 is very quick, but of course, many sites
fall apart in that one (for no good reason I'm sure).

Speaking of falling apart, after setting the option to throw up the
error console on JS exceptions, I have noticed that many major sites
crash on _every_ page. Examples are MSDN and Adsense. It's hard to
believe that Google and MS are that incompetent, but then what else is
new? I assume browser sniffing is the culprit. Anyone still think that
stuff is a good idea? Apparently it was _not_ "good enough for Google"
after all.

Quite a shame as it is a very fast, capable and standards-compliant
browser; a fact that is belied by its relative market-share. Even if
_nobody_ used it, it is still a good browser to test with as it can
expose holes that are paved over by the handful of other majors. That's
why you should care about it.

 

[Stevo]

Quite a shame as it is a very fast, capable and standards-compliant
browser; a fact that is belied by its relative market-share.

They've only got themselves to blame for originally charging for it. How
could they have competed against IE and NS when they were expecting
people to pay for something that was barely better than the free
competitors. If they'd had the vision to release it for free, the
browser wars may have been a completely different story. They didn't
have the funding to do that though. Even Netscape themselves had to give
up. If it wasn't for the open-source movement, we'd still now be stuck
with a choice of IE and whatever competitor was currently managing to
hang on for dear life trying to compete still.

I naturally have Opera installed along with all the other browsers but
it doesn't win against any of them in whatever category I might choose.
Firefox is better for customizability (plugins). Chrome is better in
terms of JavaScript speed and a simple layout. Safari, well that
naturally loses against all browsers ever made.

There's nothing wrong with Opera 9/10, but there's nothing exciting
about it that gives me a reason to want it above others.

My default browser is Firefox 3.5 with Firebug, Grease Monkey and
various other small developer addons. I use Chrome for some sites that
use too much JavaScript (like ScrumWorks).

 

[Julian Turner]

They've only got themselves to blame for originally charging for it. How
could they have competed against IE and NS when they were expecting
people to pay for something that was barely better than the free
competitors. If they'd had the vision to release it for free, the
browser wars may have been a completely different story. They didn't
have the funding to do that though. Even Netscape themselves had to give
up. If it wasn't for the open-source movement, we'd still now be stuck
with a choice of IE and whatever competitor was currently managing to
hang on for dear life trying to compete still.

I naturally have Opera installed along with all the other browsers but
it doesn't win against any of them in whatever category I might choose.
Firefox is better for customizability (plugins). Chrome is better in
terms of JavaScript speed and a simple layout. Safari, well that
naturally loses against all browsers ever made.

There's nothing wrong with Opera 9/10, but there's nothing exciting
about it that gives me a reason to want it above others.

My default browser is Firefox 3.5 with Firebug, Grease Monkey and
various other small developer addons. I use Chrome for some sites that
use too much JavaScript (like ScrumWorks).

I too have all the browsers installed, and I find that the choice
between them is often based on subtle differences.

Overally, I find that there is very little to tell between any of the
main browsers for 99% of my browsing needs.

I find that I gravitate to Opera every time for JavaScript
development, because I like the simple stack trace dialogue it
provides.

JavaScript speed and CSS compatibility aside, in terms of "dynamic"
html rendering performance (repositioning and resizing), and in terms
of performance of controls (text boxes etc), I always seem to find
that I like IE the best - it just seems a touch smoother than the
others.

In terms of load time, Chrome is the most attractive, and the browser
I tend to use for on-demand browsing, where I am not likely to be
there for a long time. Having said that, at work, IE7 on a 2.6GHz
Windows XP PC, loads as instantaneously as Chrome.

Julian

 

[David Mark]

They've only got themselves to blame for originally charging for it. How
could they have competed against IE and NS when they were expecting
people to pay for something that was barely better than the free
competitors. If they'd had the vision to release it for free, the
browser wars may have been a completely different story. They didn't
have the funding to do that though. Even Netscape themselves had to give
up. If it wasn't for the open-source movement, we'd still now be stuck
with a choice of IE and whatever competitor was currently managing to
hang on for dear life trying to compete still.

Yes, I suppose.

I naturally have Opera installed along with all the other browsers but
it doesn't win against any of them in whatever category I might choose.

I find it to be _much_ faster at JSLint for some reason.

Firefox is better for customizability (plugins). Chrome is better in
terms of JavaScript speed and a simple layout. Safari, well that
naturally loses against all browsers ever made.

I see very little difference between Chrome and Safari, but my main
workstation is fairly slow, so it could be the leveler.

There's nothing wrong with Opera 9/10, but there's nothing exciting
about it that gives me a reason to want it above others.

According to the "major" libraries, Opera 9 is "deprecated" LOL. I
don't know how people write stuff like that without stopping and
realizing they are just making very obvious excuses for their failures
(usually browser sniffing). Gee, we updated our magic "cross-browser"
library to "work" with Opera 10 (until 11 comes out of course and then
it is back to the old drawing board). They really do remind me of Wile
E Coyote.

My default browser is Firefox 3.5 with Firebug, Grease Monkey and
various other small developer addons. I use Chrome for some sites that
use too much JavaScript (like ScrumWorks).

FF/FB is a pig, though I'm sure it is fine on a brand new PC (likely
what the developers tested on).

 

[Richard Maher]

Hi Julian,

I too have all the browsers installed, and I find that the choice
between them is often based on subtle differences.

Overally, I find that there is very little to tell between any of the
main browsers for 99% of my browsing needs.

I find that I gravitate to Opera every time for JavaScript
development, because I like the simple stack trace dialogue it
provides.

But why does it have to phone home evrytime to run a simple debugging
session with that dragon-fly thing?

JavaScript speed and CSS compatibility aside, in terms of "dynamic"
html rendering performance (repositioning and resizing), and in terms
of performance of controls (text boxes etc), I always seem to find
that I like IE the best - it just seems a touch smoother than the
others.

In terms of load time, Chrome is the most attractive, and the browser
I tend to use for on-demand browsing, where I am not likely to be
there for a long time. Having said that, at work, IE7 on a 2.6GHz
Windows XP PC, loads as instantaneously as Chrome.

Julian

Cheers Richard Maher

 

[Richard Maher]

Hi David,

Quite a shame as it is a very fast, capable and standards-compliant
browser; a fact that is belied by its relative market-share.

I like the seemingly crisper, brighter, somethinger rendering of Opera but
when it comes to "standards-compliant" (and not that applets will bother you
at all Opera, like Safari, insist on using their own JAVA plugin (or at
least an ideaosynchratic security manager) Sadly, quite debilitating.

Cheers Richard Maher

 

[Ivan S]

According to the "major" libraries, Opera 9 is "deprecated" LOL.  I
don't know how people write stuff like that without stopping and
realizing they are just making very obvious excuses for their failures
(usually browser sniffing).  Gee, we updated our magic "cross-browser"
library to "work" with Opera 10 (until 11 comes out of course and then
it is back to the old drawing board).  They really do remind me of Wile
E Coyote.

I don't know have you seen this:

http://dev.opera.com/articles/view/opera-ua-string-changes/


This is a highlight:

"Opera 10 is interpreted as Opera 1"

I suppose those sites doesn't support Opera 1, but users won't be too
happy with the fact that they have the latest Opera, not the first.

 

[David Mark]

Richard Cornford wrote:

[...]

It is astounding that people still attempt to justify UA sting based
browser sniffing, when they must realise that they are placing their
hops on extracting some truth from something that is being designed to
mislead.

Yes. But I don't know if astounding is strong enough. Make no mistake,
there are indeed people out there feverishly maintaining UA-based forks
and deluded enough to think they are making "progress" or being
"pragmatic". What would you say the future holds for these gigantic
frameworks (e.g. Closure, SproutCore) that sniff browsers every ten
lines or so? I'd say a coffin (and good riddance).

 

[Dr J R Stockton]

There's nothing wrong with Opera 9/10, but there's nothing exciting
about it that gives me a reason to want it above others.

There is if you want a well-implemented Date Object - perhaps
particularly so for the resident British, Irish, and Portuguese.

FYI, new Date("2 Bananas 2004") gives the 2nd of the current month
of 2004. Or if you want new Date("Y/M/D") range to work with other
than two- or four- digit years. But it does have the sense to recognise
UTC and GMT as alphabetical indications of offset from GMT, rather than
allowing potentially ambiguous local variants.

FYI, Safari and Chrome accept new Date("1 Octopus 2004") as 1st
October 2004.

 

[Ivan S]

so the browser manufacturers ensure that their UA strings result in identification as some browser that they have seen

Well ... I've seen IE8 on MS Windows Vista detected as IE6 because it
has "6.0" in it's UA string which is misinterpreted as browser version
and I haven't seen MS fix for their IE8 UA string on Windows Vista.


IMHO, it should be obvious that browser detection is far from being
reliable and future proof, even for same browsers.

 

[Peter Michaux]

Safari, well that
naturally loses against all browsers ever made.

You really think that is true? It's worse than IE for Mac?

Peter

 

[David Mark]

You really think that is true? It's worse than IE for Mac?

Well (referring to the last one they churned out) if there's one browser
that really is a dead issue, it's that one (at least I wouldn't lose any
sleep over it). IIRC, the software itself is so poorly done that it is
prone to crashes.

But there are lots of incarnations of IE for Mac that are perfectly
usable today (though it's hard to imagine just who would be using them).
It was one of those (released around the turn of the century) that first
clued me in to the "unknown" host object types, which still influence
browser scripting today (for those who are conscious of them anyway).

I'd say IE for _Windows_ is the worst major browser in use today (by far).

 

[Dr J R Stockton]

In comp.lang.javascript message <5684c36a-0a27-4c48-8b38-b21d97c7b14f@q1
5g2000yqj.googlegroups.com>, Sat, 27 Feb 2010 04:25:20, Ivan S

Well ... I've seen IE8 on MS Windows Vista detected as IE6 because it
has "6.0" in it's UA string which is misinterpreted as browser version
and I haven't seen MS fix for their IE8 UA string on Windows Vista.


IMHO, it should be obvious that browser detection is far from being
reliable and future proof, even for same browsers.

Using the UA string for browser detection has long been deprecated.

It seems wisest, where possible, to test that features exist before
using them. However, since one generally wants the page to run in
browsers lacking the feature, alternative code must be provided, and if
that code gives the same results sufficiently rapidly there is little
point in using the feature at all and so no need to test for it.

But there is an intermediate, middle way. One can ignore the UA and
test for a feature, then use that result as indicating which browser it
is.

For example, if Number.toFixed is absent the browser must be
ancient, and if (0.007).toFixed(2) is right the browser cannot be a
so-far-released version of MSIE. In only one major PC browser does new
Date() accept a wholly invalid month name. I think only one major PC
browser accepts new Date(864e13).setMilliseconds(1) .

Unless nothing better can be found, such tests are inappropriate for
final code. But they can be used in the test stage, where it may be
desirable to suppress Problem B in browser X in order to be able to test
Part A in that browser.

 

[David Mark]

In comp.lang.javascript message <5684c36a-0a27-4c48-8b38-b21d97c7b14f@q1
5g2000yqj.googlegroups.com>, Sat, 27 Feb 2010 04:25:20, Ivan S



Using the UA string for browser detection has long been deprecated.

Yes and for reasons that should be painfully obvious, so why is it that
YUI, Dojo, ExtJS, Closure, Cappuccino, SproutCore, Prototype, MooTools,
etc. are full of forks based on this arbitrary (and optional) string of
characters? It's mind-boggling that these things could persist in 2010.
Of course, that's why they fall apart in anything but the latest major
desktop browsers in their default configurations, requiring periodic
swap-outs that are invariably incompatible with their previous releases.
The fact that (some of) these scripts are popular indicates that Web
developers, in general, need to be educated on the issues, but as a
group, they seem entirely unwilling to use their heads. Why they (not
to mention the library developers) can't see the folly in their ways is
beyond me. Perhaps they think that it is all par for the course to "get
things done." If only they would realize that their "real world" exists
only in their heads.

It seems wisest, where possible, to test that features exist before
using them.

Indeed. Seems like a no-brainer. But for those who refuse to use their
brains...

However, since one generally wants the page to run in
browsers lacking the feature, alternative code must be provided, and if
that code gives the same results sufficiently rapidly there is little
point in using the feature at all and so no need to test for it.

Yes, much of the Ajax-ified crap that is arbitrarily dumped onto
Websites is completely unnecessary. Drop 99% of it and the end-users
wouldn't even notice.

But there is an intermediate, middle way. One can ignore the UA and
test for a feature, then use that result as indicating which browser it
is.

That's called an object inference and is just another form of browser
sniffing. You can't pigeonhole browsers based on features and quirks
that are known to change (often dramatically) from one release to the
next. If you do, you are in a self-imposed, endless maintenance loop.

For example, if Number.toFixed is absent the browser must be
ancient, and if (0.007).toFixed(2) is right the browser cannot be a
so-far-released version of MSIE. In only one major PC browser does new
Date() accept a wholly invalid month name. I think only one major PC
browser accepts new Date(864e13).setMilliseconds(1) .

Unless nothing better can be found, such tests are inappropriate for
final code. But they can be used in the test stage, where it may be
desirable to suppress Problem B in browser X in order to be able to test
Part A in that browser.

Yes, such techniques can be used for testing or mock-ups, but certainly
not in production code. Unfortunately, 99.9% of sites on the Web use
browser sniffing scripts, which is one of the main reasons that the Web
is such a mess. The pseudo-intellectuals like to point out that this
fact confirms that they are on the right track (and therefore
suggestions to the contrary must be wrong).

The end-users know this all too well, but the developers seem to be in a
state of denial that their "solutions" are actually false fronts for
design failures. Their latest illogical stance is that they are
"rebels" and that it is all IE's fault and they should just let
everything break in that (the most popular) browser. (!)

 

[RobG]

Dr J R Stockton wrote: [...]

Unless nothing better can be found, such tests are inappropriate for
final code. But they can be used in the test stage, where it may be
desirable to suppress Problem B in browser X in order to be able to test
Part A in that browser.

Yes, such techniques can be used for testing or mock-ups, but certainly
not in production code. Unfortunately, 99.9% of sites on the Web use
browser sniffing scripts, which is one of the main reasons that the Web
is such a mess. The pseudo-intellectuals like to point out that this
fact confirms that they are on the right track (and therefore
suggestions to the contrary must be wrong).

The end-users know this all too well, but the developers seem to be in a
state of denial that their "solutions" are actually false fronts for
design failures. Their latest illogical stance is that they are
"rebels" and that it is all IE's fault and they should just let
everything break in that (the most popular) browser. (!)

Try this in IE 6:

http://www.cineplex.com.au/

 

[rf]

Try this in IE 6:

http://www.cineplex.com.au/

LOL. Just royally pissed off 20% of their visitors.

 

[rf]

LOL. Just royally pissed off 20% of their visitors.

Typo. 10%.

 

[David Mark]

Dr J R Stockton wrote: [...]

Unless nothing better can be found, such tests are inappropriate for
final code. But they can be used in the test stage, where it may be
desirable to suppress Problem B in browser X in order to be able to test
Part A in that browser.

Yes, such techniques can be used for testing or mock-ups, but certainly
not in production code. Unfortunately, 99.9% of sites on the Web use
browser sniffing scripts, which is one of the main reasons that the Web
is such a mess. The pseudo-intellectuals like to point out that this
fact confirms that they are on the right track (and therefore
suggestions to the contrary must be wrong).

The end-users know this all too well, but the developers seem to be in a
state of denial that their "solutions" are actually false fronts for
design failures. Their latest illogical stance is that they are
"rebels" and that it is all IE's fault and they should just let
everything break in that (the most popular) browser. (!)

Try this in IE 6:

http://www.cineplex.com.au/

An alert (!) pops up:-

"We have detected that the browser you are using is no longer supported."

For one, they assume the end-user knows what a browser is. Telling them
it is "no longer supported", particularly in an alert, will make many of
them think that their PC is broken.

"We recommend you use minimum Internet Explorer 7 or above, or Firefox 2
or above as we we are no longer supporting the browser you are using."

Oh yeah, up yours yours.

Good way to piss off a prospective visitor. Some of them will be
unfamiliar with "Internet Explorer 7" and/or "Firefox 2" and will
hurriedly hit the back button, rightfully assuming that the site is broken.

These "rebels" don't seem to realize that many users (e.g. corporate
users) have no choice in the matter. I'd think that would be enough to
convince them that it is a stupid idea to pester users about their
"choice" of browsers.

And I wonder if that site was written by Paul D. Waite?

http://stackoverflow.com/questions/...-browser-framework-that-supports-old-browsers

As an aside, what a useless site that is. But I recently saw a noted
jQuery shill comment that people should avoid the "trollings" of CLJ and
seek better advice there (or on the Dojo mailing list). God save us.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sun, 28 Feb 2010 19:14:26, David Mark

Dr J R Stockton wrote:


That's called an object inference and is just another form of browser
sniffing. You can't pigeonhole browsers based on features and quirks
that are known to change (often dramatically) from one release to the
next. If you do, you are in a self-imposed, endless maintenance loop.

You should read the whole of an article before thinking about answering
any of it.

Yes, such techniques can be used for testing or mock-ups, but certainly
not in production code.
...

Not a useful contribution.

 

[David Mark]

In comp.lang.javascript message <[email protected]
september.org>, Sun, 28 Feb 2010 19:14:26, David Mark


You should read the whole of an article before thinking about answering
any of it.

I was commenting on your description above. If the article says
something else, that's another concern.

Not a useful contribution.

In your opinion.