What are your users using? IE vs FF and everyone else

[Diogenes]

Kind readers,

The first cut of this was originally posted in
comp.infosystems.www.authoring.stylesheets

I was dismissed as being off topic.

The reason for posting in 'stylesheets' was I felt
this group would be the most sensitive to the differences
between the browsers and what their respective audiences
were using.

So I repost again, this time with more specific information.
I may or may not have a point here, depending on how you read
this, and your general temperament.

================================================================

IE is losing market share because it is an inferior product. A number
of news articles (from google news) regarding the demise of the Netscape
browser cited FireFox as having 16% of market share.

I think that number is low. I provided a link to a site that more than
doubles that figure.

http://www.w3schools.com/browsers/browsers_stats.asp

I'm not saying these numbers are the final authority. It's
just one sample.

I manage 2 sites, one personal, the other commercial. Both are low
traffic. Here are their numbers for Dec, produced by AWSTATS:

Personal Comm
FireFox (all versions) 57% 68.5%
IE 39.2 24.4
Others 2.9 6.9

Granted, this is a very small sample, a selective audience, yada,
yada, yada, but I trust these numbers.

I was wondering what other are experiencing on their 100K
visitors/month website.

I imagine that the FF usage in Europe is MUCH higher that 16%.

FWIW, another twist to all of this is that Microsoft is using the
demise of Netscape an an argument in court that an extension of its
'anti-trust oversight' should NOT be extended. The original reasons
for this oversight have disappeared (NS is gone).

http://www.theregister.co.uk/2008/01/03/microsoft_scoffs_antitrust_extention_seekers/

My recent experience in buying computers in the retail market in
Calgary, Canada, is that Microsoft Vista is the ONLY windows OS
on offer and IE is the only browser installed on these whiz bang
machines that do everything with almost everything pre-installed
(including stuff you don't want).

You have to pull strings to get XP, for instance, and download FF
yourself. Right? Please tell me I'm wrong.

It's not the Adam Smith 'invisible hand' that is guiding the market
here, it's the invisible hand of Bill Gates.

One last link, by John Dovorak, says it better than I ever can.

http://www.pcmag.com/article2/0,2704,2246368,00.asp


Cheers
-Dio

 

[Travis Newbury]

I was dismissed as being off topic.

My question again is why does it matter to the site what browser
someone visits with? Isn't the mantra "be browser independent?"

 

[_q_u_a_m_i_s's]

My question again is why does it matter to the site what browser
someone visits with? Isn't the mantra "be browser independent?"

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page. You need to do too muck code-hacking to that all browsers would
be happy.

Ever tried the same page in IE, FF, Opera and Safari? I mean a "web
2.0" page..with lots of js & css in it.

Not trying to say that IE is the "bad one" in this area(even if i
really think so) but when IE was 99% of all browsers visiting a web-
site you just needed to program that page for IE, with all its hacks,
and workarounds.... now you need to make the same thing for at least 2
browsers. So right now (or until IE dissapears, or becomes a real
browser) you need to make the same page for 2 different browsers, and
when a change is required you have to make the same change twice...
this means a lot of code to handle, and a lot of opportunities for
bugs appearing (you can never know all the quirks of a browser,
especially in the case of IE where IE5 behaves different than IE6, and
IE6 different than IE7).

 

[Anthony Levensalor]

_q_u_a_m_i_s's said:

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page. You need to do too muck code-hacking to that all browsers would
be happy.

There really isn't all that much 'code-hacking' required. Conscientious
coding is much better than hacking and as far as Javascript goes, it is
not difficult at all to find the common threads and use them
appropriately so that code works in Safari, Opera, IE, and FireFox.

Ever tried the same page in IE, FF, Opera and Safari? I mean a "web
2.0" page..with lots of js & css in it.

Yes, and I've written quite a few as well. With only minor CSS hacks
most things work out just fine, and using object detection in Javascript
means never having to say you're sorry.

Not trying to say that IE is the "bad one" in this area(even if i
really think so) but when IE was 99% of all browsers visiting a web-
site you just needed to program that page for IE, with all its hacks,
and workarounds.... now you need to make the same thing for at least 2
browsers. So right now (or until IE dissapears, or becomes a real
browser) you need to make the same page for 2 different browsers, and
when a change is required you have to make the same change twice...
this means a lot of code to handle, and a lot of opportunities for
bugs appearing (you can never know all the quirks of a browser,
especially in the case of IE where IE5 behaves different than IE6, and
IE6 different than IE7).

No, no, IE is the bad one.

All the best,
~A!

 

[Travis Newbury]

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page.

If you redirect me and tell me to get a "real browser" I will likely
leave your site and never return.

Your visitor will think: "Since ever site I normally go to works just
fine with my browser, I can only assume that it is YOUR site that is
broken and NOT my browser. Bye bye now..."

Just a thought.

 

[Anthony Levensalor]

Travis Newbury said:

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page.

[snip]
Your visitor will think: "Since ever site I normally go to works just
fine with my browser, I can only assume that it is YOUR site that is
broken and NOT my browser. Bye bye now..."

Just a thought.

And I personally think the user who would say that would be 100%
correct. It is really not that difficult to make sites that are
cross-compatible these days.

~A!

 

[Sherman Pendley]

My question again is why does it matter to the site what browser
someone visits with? Isn't the mantra "be browser independent?"

In theory yes, but in practice we're often forced to use strange hacks
to work around a certain browser's broken behavior.

The need for "body { font-size:100%; }" for instance, which IIRC is a
workaround for a bug in IE. Here's a hack that's perfectly standards-
compliant, but used only for the benefit of that one browser.

Whether a browser has 70%+ or 5% market share is an important factor in
one's planning. The fact that IE has such a large market share means
that web developers should be aware of it and test their sites against
it - preferably with all of the recent versions of it. And when new
versions of popular browsers are released, we need to stay informed
about whatever new bugs they add to the mix...

Ideally, all this following and testing against this browser or that
wouldn't be necessary, but browser bugs are an annoying reality. We
can't just cover our ears and chant "standards" until the bugs go
away, if we want to attract and keep and audience.

Fortunately, virtualization like Parallels, VMWare, and VirtualPC has
made it easy to test against a variety of IE/Windows versions without
having to build a whole computer lab.

If IE had a hypothetical market share of 5%, then I wouldn't consider
it worth the time to worry about its bugs. In fact, on my CamelBones
site I *don't* bother with testing against IE. CB is a tool for Mac
developers, and all IE/Windows readers are going to quickly realize
that these aren't the droids they're looking for. My logs show IE/Win
numbers that are practically nil.

sherm--

 

[Sherman Pendley]

There really isn't all that much 'code-hacking'
required. Conscientious coding is much better than hacking and as far
as Javascript goes, it is not difficult at all to find the common
threads and use them appropriately so that code works in Safari,
Opera, IE, and FireFox.

And even then, you won't need to constantly write that kind of code.

There are plenty of free libraries that encapsulate all that browser-
checking and other standard code into a simple function call. And if
you don't like those, it's not hard to write your own.

sherm--

 

[Anthony Levensalor]

Sherman Pendley said:

And even then, you won't need to constantly write that kind of code.

There are plenty of free libraries that encapsulate all that browser-
checking and other standard code into a simple function call. And if
you don't like those, it's not hard to write your own.

sherm--

Yeah, but browser checking sucks, and it's not a good move. There will
be more browsers than the ones we have now, and the ones we have now
will eventually go away. Why try to keep up?

Not only that, but there are a great deal more browsers than there are
scripts that include them all. Object/Function/Array/Collection
detection on an as-needed basis works the best, and you don't have to
have 80kb of Javascript code, 79kb of which you'lll never use, to do it.
It's a beautiful thing.

~A!

 

[Gregor Kofler]

Sherman Pendley meinte:

There are plenty of free libraries that encapsulate all that browser-
checking and other standard code into a simple function call. And if
you don't like those, it's not hard to write your own.

Libraries that do *browser*-checking are - at best - useless. Most of
the time they'll be the source of errors.

Gregor

 

[Randy Webb]

Diogenes said the following on 1/9/2008 3:00 AM:

Kind readers,

The first cut of this was originally posted in
comp.infosystems.www.authoring.stylesheets

I was dismissed as being off topic.

Your anti-MS rants are just as off topic in comp.lang.javascript as they
are in ciwas.

You reply and tell me what it has to do with Javascript and I will be
happy to debunk the many myths in your post.

<snip>

 

[Diogenes]

Travis Newbury said:

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page.

[snip]
Your visitor will think: "Since ever site I normally go to works just
fine with my browser, I can only assume that it is YOUR site that is
broken and NOT my browser. Bye bye now..."

Just a thought.

And I personally think the user who would say that would be 100%
correct. It is really not that difficult to make sites that are
cross-compatible these days.

~A!

Quamis's was just making a tongue-in-cheek remark. You guys really
need to lighten up.

 

[Anthony Levensalor]

*** Diogenes *** wrote a whole bunch of nifty stuff On 1/9/2008 9:02 PM:

Travis Newbury said:

Yeah, it is, but when doing lots of js and css... you just wanna
redirect IE users to get a real browser and let on FF users see your
page. [snip]
Your visitor will think: "Since ever site I normally go to works just
fine with my browser, I can only assume that it is YOUR site that is
broken and NOT my browser. Bye bye now..."

Just a thought.

And I personally think the user who would say that would be 100%
correct. It is really not that difficult to make sites that are
cross-compatible these days.

~A!

Quamis's was just making a tongue-in-cheek remark. You guys really
need to lighten up.

Hah! We don't have to do anything, thank you very much. IE rants in
comp.lang.javascript deserve whatever they get, thanks for coming by.

~A!

 

[Diogenes]

Hah! We don't have to do anything, thank you very much. IE rants in
comp.lang.javascript deserve whatever they get, thanks for coming by.

~A!

As I was saying...

 

[Diogenes]

Your anti-MS rants are just as off topic in comp.lang.javascript as they
are in ciwas.

You reply and tell me what it has to do with Javascript and I will be
happy to debunk the many myths in your post.

Javascript is client side programming that will work, for the most
part, with all modern browsers without resorting to special
code that targets a specific browser.

Exceptions to this include embedded sound and video objects and
code that employs programming colliquisms such as 'document.all'.

Over to you RANDY WEBB ... yes, the many myths? I'll be satisfied
if you offer 3.

-Dio

 

[David Mark]

And even then, you won't need to constantly write that kind of code.

What kind of code?

There are plenty of free libraries that encapsulate all that browser-

Yes, there are plenty of clueless morons churning out free JavaScript
libraries. They take the four browsers they have heard of, note the
user agent string for each, run lots of tests on each, indexing the
results by this string and then cobble together code that branches
accordingly. This is, of course, a colossal waste of time. The
reasons are myriad.

1. The user agent string is meaningless. Browser developers forge it
and users can change it. This dates back to the "browser wars" of
last century. IE has always spoofed Mozilla, many mobile devices and
fringe browsers spoof IE, etc. Nobody wants to be exluded from
content on the basis of browser sniffing.

2. Any inference based on the "detected" name/platform/version of a
browser becomes suspect every time a new version is released. Imagine
having to re-test everything each time an auto-update dialog pops up.
If a revision invalidates one or more workarounds, the only recourse
is to add new branches to the code. Then affected parts of the code
(assuming they are isolated) must be re-tested with not only the new
version, but each that preceded it.

3. New agents come out every other day. Mobile devices, set top
boxes, refrigerators, watches, etc. There is no end to it. It would
be impossible to constantly add branches for each and it is
impractical to ignore them.

4. Since browser sniffing logic is clearly faulty, it stands to reason
that graceful degradation based on such logic is impossible. The
typical release of a JavaScript library "works" for a finite period of
time for the default configuration of a handful of supported
browsers. Results are undefined for all other cases, causing scripts
to break in unpredictable ways that can easily render documents
unusable.

All of this adds up to major maintenance and support headaches that
get worse as time goes by. Delegating these issues to the authors of
JavaScript libraries would seem quite a leap of faith.

The library authors are stuck in an endless cycle of working around
their own incompetent design decisions. This is quite obvious from
reading the associated blogs, mailing lists, support tickets, etc.

None of this is news. People in this group (clj) who know better have
been ripping these libraries to shreds for years. It is a rare
occasion that the responsible parties speak up to justify their
existence. The last such post that I remember was full of inept
explanations, feeble excuses and arguments that have been invalid for
over a decade.

And server log sniffing is also a waste of time. Even if the relative
popularity of specific browsers was important, statistics culled from
server logs are inherently unreliable. In addition to the previously
mentioned impossibility of user agent identification, a large segment
of the population browses behind proxy servers.

The solution is simple. See the FAQ entry on feature detection and
write code once for all browsers. Obviously code must be tested with
as many browsers as possible, but if it is free of faulty inferences,
it won't have to be endlessly reworked and re-tested.

 

[Randy Webb]

Diogenes said the following on 1/9/2008 11:06 PM:

Javascript is client side programming that will work, for the most
part, with all modern browsers without resorting to special
code that targets a specific browser.

Nobody said any differently. And, nothing in your original post had
anything to do with javascript. It reads as the typical anti-MS rant
because some mythical voodoo statistics said so.

Exceptions to this include embedded sound and video objects and
code that employs programming colliquisms such as 'document.all'.

I don't use either. And, I don't go back to sites that try to force
music on me.

Over to you RANDY WEBB ... yes, the many myths? I'll be satisfied
if you offer 3.

Myth #1: That webstats, any of them, are worth the paper it would take
to print them. They are useless. Totally useless.

Myth #2: That you can't buy a retail PC with any Windows on it besides
Vista. We recently installed over 100 (109 to be exact) desktop units
that had Windows XP installed on them.

Myth #3: That anything that John Dovorak (whoever that may be) has to
say about Microsoft has anything to do with Javascript.

Nothing in your post had anything to do with Javascript. Perhaps you
should try reposting and at least try to ask about some JS slant to it.

As for market share, the only way you will *ever* get rid of IE is if
you get rid of Windows. And with the rate that PC's are bought, that
isn't happening any time soon.

Curious though. Are there any of the anti-MS crowd that want to bitch
and complain about the PC manufacturers that practically gave Bill Gates
the monopoly he has? Bill Gates saw an opportunity and he took it. The
PC manufacturers were beating at his door wanting a bulk discount. They
gave him a monopoly in return for that discount. It was about the money.

 

[Anthony Levensalor]

* Diogenes wrote, on %m/1240588 /%y at %:%m:

Javascript is client side programming that will work, for the most
part, with all modern browsers without resorting to special
code that targets a specific browser.

Exceptions to this include embedded sound and video objects and
code that employs programming colliquisms such as 'document.all'.

Over to you RANDY WEBB ... yes, the many myths? I'll be satisfied
if you offer 3.

-Dio

Myth #1:
That you have the ability to understand the basics of communication in
the English language.

Fact #1:
You were asked what this topic had to do with Javascript. You responded
by stating that Javascript runs in modern browsers. This still has
nothing to do with the topic of the thread, which is Browser Market
Share, not browser detection, or anything associated with Javascript.

Myth #2:

> Javascript is client side programming

Fact #2:
Javascript runs on both the client and the server

Myth #3:
that will work, for the most

> part, with all modern browsers without resorting to special
> code that targets a specific browser.

Fact #3:
Your myth implies that javascript requires no sort of checking to make
sure the features being used are supported in the currently running
environment. This is untrue, because object/feature/function detection
is a staple of modern Javascript coding practices, and as a technique is
a more elegant and far less error prone method for targeting a specific
browser.

Consider any function trying to get the source element of an event:

function eventHandler(e) {
// in some browsers, e will be undefined, IE is one.
// in Mozilla, e will be an event object
if (window.event) {
e = window.event;
}

var elm = e.srcElement; // IE
var elm = e.target; // Mozilla
}

There are countless other examples.
style.filter
style.opacity

Both work with the alpha opacity of an element. In IE, however, you
cannot change the opacity of an element that does not have a width and
height explicitly set.

Myth #4:

> Exceptions to this include embedded sound and video objects and

Fact #4:
Since your initial premise was incorrect, your exceptions to that
premise are also incorrect by default.

The following works in IE, FireFox, Opera, and Safari for Windows:

<embed type="application/x-mplayer2"
src="11%20My%20Friend%20Of%20Misery.mp3" autostart="false" loop="false">

With no modification. It isn't even valid markup, and it has that kind
of compatibility.

Myth #5:

> code that employs programming colliquisms such as 'document.all'. (as

another exception)

Fact #5:
document.all _is_ code that targets specific browsers. That doesn't
require a workaround or special code, it requires a basic education in
DOM standards and script bindings.


~A!

 

[David Mark]

* Diogenes wrote, on %m/1240588 /%y at %:%m:










Myth #1:
That you have the ability to understand the basics of communication in
the English language.

Fact #1:
You were asked what this topic had to do with Javascript. You responded
by stating that Javascript runs in modern browsers. This still has
nothing to do with the topic of the thread, which is Browser Market
Share, not browser detection, or anything associated with Javascript.

Myth #2:
 > Javascript is client side programming

Fact #2:
Javascript runs on both the client and the server

Myth #3:
that will work, for the most
 > part, with all modern browsers without resorting to special
 > code that targets a specific browser.

Fact #3:
Your myth implies that javascript requires no sort of checking to make
sure the features being used are supported in the currently running
environment. This is untrue, because object/feature/function detection
is a staple of modern Javascript coding practices, and as a technique is
a more elegant and far less error prone method for targeting a specific
browser.

Consider any function trying to get the source element of an event:

function eventHandler(e) {
   // in some browsers, e will be undefined, IE is one.
   // in Mozilla, e will be an event object
   if (window.event) {
     e = window.event;
   }

   var elm = e.srcElement; // IE
   var elm = e.target; // Mozilla

}

e = e || window.event;
var elm = e.target || e.srcElement;

There are countless other examples.
style.filter
style.opacity

Both work with the alpha opacity of an element. In IE, however, you
cannot change the opacity of an element that does not have a width  and
height explicitly set.

Specifically, IE will not set the opacity unless the element sets its
proprietary "hasLayout" property. Here is one way to force it:

if (el.currentStyle && !el.currentStyle.hasLayout) { el.style.zoom =
1; }

Myth #4:
 > Exceptions to this include embedded sound and video objects and

Fact #4:
Since your initial premise was incorrect, your exceptions to that
premise are also incorrect by default.

The following works in IE, FireFox, Opera, and Safari for Windows:

<embed type="application/x-mplayer2"
src="11%20My%20Friend%20Of%20Misery.mp3" autostart="false" loop="false">

With no modification. It isn't even valid markup, and it has that kind
of compatibility.

I'll take your word for it, but standard nested objects can work just
as well these days.

 

[Anthony Levensalor]

* David Mark wrote
[snip]

e = e || window.event;
var elm = e.target || e.srcElement;

Aye, that was not meant to be running code. That is precisely how I do
it in my apps.

Specifically, IE will not set the opacity unless the element sets its
proprietary "hasLayout" property. Here is one way to force it:

if (el.currentStyle && !el.currentStyle.hasLayout) { el.style.zoom =
1; }

Good tip, I was not aware of that. Danke.

[snip]

I'll take your word for it, but standard nested objects can work just
as well these days.

Whole post took about three minutes to write up, I was kinda just
showing him the door on this one. I did test the embed, and netscape 9
was the only one that wanted to download a plugin and couldn't find it.

The Object->Param->Embed construct that works even better and is much
more useful was just too long to type for my purposes here.

~A!