Detecting JS enabled/capable browser

[Ryan Stewart]

I'm working on a project to collect web application usage statistics. What
are the recommended ways of detecting whether a browser is JavaScript
enabled and/or capable? Obviously I can write a script to invoke something
on the server, and if it works, then it works. Is there a better way? I'm
looking for the least intrusive way of doing it, from a web application
point of view. i.e. I'd like to be able to drop this into an existing
application without altering anything already there. It would be nice if
there were just a "JavaScript-Enabled" HTTP header.

[Jim Ley]

Re: Detecting JS enabled/capable browser

On Fri, 24 Dec 2004 14:04:23 -0600, "Ryan Stewart"
<zzanNOtozz@gSP AMo.com> wrote:
[color=blue]
>I'm working on a project to collect web application usage statistics. What
>are the recommended ways of detecting whether a browser is JavaScript
>enabled and/or capable? Obviously I can write a script to invoke something
>on the server, and if it works, then it works. Is there a better way? I'm
>looking for the least intrusive way of doing it, from a web application
>point of view. i.e. I'd like to be able to drop this into an existing
>application without altering anything already there. It would be nice if
>there were just a "JavaScript-Enabled" HTTP header.[/color]

The gross statistic javascript enabled is almost completely pointless
thing to collect, as it tells you nothing about how capable the script
engine is, NN2 had script support, do you really want to know if it's
script enabled? Does your application work with it?

Jim.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Jim Ley" <jim@jibbering. com> wrote in message
news:41cc7d3e.9 505868@news.ind ividual.net...[color=blue]
> On Fri, 24 Dec 2004 14:04:23 -0600, "Ryan Stewart"
> <zzanNOtozz@gSP AMo.com> wrote:[color=green]
>>I'm working on a project to collect web application usage statistics. What
>>are the recommended ways of detecting whether a browser is JavaScript
>>enabled and/or capable? Obviously I can write a script to invoke something
>>on the server, and if it works, then it works. Is there a better way? I'm
>>looking for the least intrusive way of doing it, from a web application
>>point of view. i.e. I'd like to be able to drop this into an existing
>>application without altering anything already there. It would be nice if
>>there were just a "JavaScript-Enabled" HTTP header.[/color]
>
> The gross statistic javascript enabled is almost completely pointless
> thing to collect, as it tells you nothing about how capable the script
> engine is, NN2 had script support, do you really want to know if it's
> script enabled? Does your application work with it?
>[/color]
That's why I'm collecting browser statistics, too, in addition to many other
things. The JavaScript portion is the only part related to this newsgroup.
Do you know how to do it or not?

[Tim Williams]

Re: Detecting JS enabled/capable browser

A small piece of js on the client to create an image and set its
source to a url of your choice? (Match up logged info with your other
browser stats)

If this is for an application involving login then alternatively you
could have some js on the login page populate a hidden form element
(and then hope the user doesn't enable/disable while using the
application.... )

Neither distinguish between js-incapable and js-disabled though....

Tim.


"Ryan Stewart" <zzanNOtozz@gSP AMo.com> wrote in message
news:kfidnbrK6r Si61HcRVn-rQ@texas.net...[color=blue]
> I'm working on a project to collect web application usage
> statistics. What are the recommended ways of detecting whether a
> browser is JavaScript enabled and/or capable? Obviously I can write
> a script to invoke something on the server, and if it works, then it
> works. Is there a better way? I'm looking for the least intrusive
> way of doing it, from a web application point of view. i.e. I'd like
> to be able to drop this into an existing application without
> altering anything already there. It would be nice if there were just
> a "JavaScript-Enabled" HTTP header.
>[/color]

[Richard]

Re: Detecting JS enabled/capable browser

Ryan Stewart wrote:
[color=blue]
> I'm working on a project to collect web application usage statistics. What
> are the recommended ways of detecting whether a browser is JavaScript
> enabled and/or capable? Obviously I can write a script to invoke something
> on the server, and if it works, then it works. Is there a better way? I'm
> looking for the least intrusive way of doing it, from a web application
> point of view. i.e. I'd like to be able to drop this into an existing
> application without altering anything already there. It would be nice if
> there were just a "JavaScript-Enabled" HTTP header.[/color]


Wonder what that <noscript> tag is all about?

www.google.com has a few answers.

[Evertjan.]

Re: Detecting JS enabled/capable browser

Richard wrote on 27 dec 2004 in comp.lang.javas cript:
[color=blue]
> Wonder what that <noscript> tag is all about?
>
> www.google.com has a few answers.
>[/color]

<http://www.w3.org/TR/REC-html40/interact/scripts.html>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Richard Cornford]

Re: Detecting JS enabled/capable browser

Richard wrote:[color=blue]
> Ryan Stewart wrote:
>[color=green]
>> I'm working on a project to collect web application usage
>> statistics. What are the recommended ways of detecting
>> whether a browser is JavaScript enabled and/or capable? ...[/color][/color]

The recommended approach is to arrange to not have to care. That avoids
the consequences of the aspects of HTTP that make any form of statistics
gathering flawed to the point of being useless, the impossibility of
implementing any mechanism for determining that client-side scripting is
available without an omniscient knowledge of all scriptable web
browsers, and the fact that such information is next to useless anyway.

<snip>[color=blue]
> Wonder what that <noscript> tag is all about?
>
> www.google.com has a few answers.[/color]

The NOSCRIPT element was a nice idea that was rendered useless by
suffering short-sighted implementation and specification. They may have
had some value while there was just one scriptable client. They
certainly no longer have any value in Internet browser scripting because
they can do nothing towards covering the third inevitability of script
outcome. And once that third possibility has been covered by design the
NOSCRIPT tag has become superfluous as the consequences of a client's
inability to execute scripts has already been addressed.

Richard.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Richard" <Anonymous@127. 001> wrote in message
news:cqpc1d05b8 @news3.newsguy. com...[color=blue]
> Ryan Stewart wrote:
>[color=green]
>> I'm working on a project to collect web application usage statistics.
>> What
>> are the recommended ways of detecting whether a browser is JavaScript
>> enabled and/or capable? Obviously I can write a script to invoke
>> something
>> on the server, and if it works, then it works. Is there a better way? I'm
>> looking for the least intrusive way of doing it, from a web application
>> point of view. i.e. I'd like to be able to drop this into an existing
>> application without altering anything already there. It would be nice if
>> there were just a "JavaScript-Enabled" HTTP header.[/color]
>
> Wonder what that <noscript> tag is all about?
>
> www.google.com has a few answers.
>[/color]
No, I know exactly what it's all about, and
http://www.w3.org/TR/html401/interac...#edef-NOSCRIPT is a much
more direct link. It is, however, totally irrelevant to my question. I don't
want to *do* something based on JS availability. I just want to *know* about
it so that I can track it.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Evertjan." <exjxw.hannivoo rt@interxnl.net > wrote in message
news:Xns95CCB3D E69C8eejj99@194 .109.133.29...[color=blue]
> Richard wrote on 27 dec 2004 in comp.lang.javas cript:
>[color=green]
>> Wonder what that <noscript> tag is all about?
>>
>> www.google.com has a few answers.
>>[/color]
>
> <http://www.w3.org/TR/REC-html40/interact/scripts.html>
>[/color]
Ah, yeah. That's what I said :)

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:cqpgt7$mqs $1$8300dec7@new s.demon.co.uk.. .[color=blue]
> Richard wrote:[color=green]
>> Ryan Stewart wrote:[color=darkred]
>>> I'm working on a project to collect web application usage
>>> statistics. What are the recommended ways of detecting
>>> whether a browser is JavaScript enabled and/or capable? ...[/color][/color]
>
> The recommended approach is to arrange to not have to care. That avoids
> the consequences of the aspects of HTTP that make any form of statistics
> gathering flawed to the point of being useless, the impossibility of
> implementing any mechanism for determining that client-side scripting is
> available without an omniscient knowledge of all scriptable web
> browsers, and the fact that such information is next to useless anyway.
>[/color]
I always arrange to not have to care. I'm simply curious and would like to
have some numbers to show. I would guess that about 95% of the users that I
code for are using IE 6. Of the rest, most probably use NN 7. That's
something I'm going to find out, and I'd also just like to know how many of
them have turned off JS. I'm guessing that percentage will be very low--in
the neighborhood of 2%. I am also curious as to what about HTTP makes you
think that statistics gathering is pointless.

[Andrew Thompson]

Re: Detecting JS enabled/capable browser

On Tue, 28 Dec 2004 00:00:28 -0600, Ryan Stewart wrote:
[color=blue]
> I am also curious as to what about HTTP makes you
> think that statistics gathering is pointless.[/color]

Speaking from my own experience, I might add the following points..

- Is a reported figure of '3/10,000 IE 4' users to be trusted?
Or is it that the site crashes IE 4 on the entry page, and
IE 4 users get no further (and spend no *money*) on the site.

- Browser UA strings are notoriously inaccurate.

- Caching of the page between server and potential clients
might result in the page not even being fetched from the server
for some, or some thousands, of potential visitors.

- Any statistic collected from XYZ.com tells you not
'what % of internet surfers..', but instead 'what % of
internet surfers who visited xyz.com..' a much less useful
statistic for other web hosts.

Those are some of the most major and obvious pitfalls of
collecting data re visitors. Experts on the topic would
probably be able to add a half dozen more technical reasons
and a baker's dozen of 'lies, damn lies and statistics' reasons.

OTOH, I myself am interested in setting up just such a 'testing
machine' as you have been discussing across various groups, even
with the potential for misinformation and misuse of the information.

I was thinking of..
- feature detection for JS, I also wanted to attempt to use JS
in efforts to determine what pixel size is '100%' in browsers,
more to prove that you cannot second guess, and should use '100%'.
- CSS import hacks (possible user input required)
- testing for browser recognition of common media types
- Java support (both version and browser functionality,
particularly showDocument and whether the browser/VM
combo. steals the focus)

Of course, with you with your teeth into it and me having
put my plans on the back burner, it sounds as though you will
beat me to the punch!

In answer to your specific question, you might experiment
with this..
- Test the browser for met-refresh redirects.
- If successful, go to a page that has a refresh for 10 seconds
- ..but also has a JS that redirects immediately to
'YesWeHaveJSTha tWillRedirectAP age.jsp'

You should have an answer (for visitors to your site who
had 'meta-refresh' enabled and the page did not crash their
browser or got bored and opted out..) to your specific question.

Good luck with it. I'm outta' here..
(Ducks and runs from this the possible rotten fruit
hurled in his general direction)

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Andrew Thompson" <SeeMySites@www .invalid> wrote in message
news:1gtn9yg1fh 2sz.773729p30b2 x.dlg@40tude.ne t...[color=blue]
> Speaking from my own experience, I might add the following points..
>
> - Is a reported figure of '3/10,000 IE 4' users to be trusted?
> Or is it that the site crashes IE 4 on the entry page, and
> IE 4 users get no further (and spend no *money*) on the site.
>[/color]
I can guarantee 99.999999999% plus that nobody will hit this (where I'm
planning to use it) with IE 4 or any outdated browser. Even if someone does,
and the site crashes in it, we are likely to hear about it to fix it, so
long as the user has a reason for using such a browser.
[color=blue]
> - Browser UA strings are notoriously inaccurate.
>[/color]
I plan to match them nearly character for character and collect unrecognized
ones for research.
[color=blue]
> - Caching of the page between server and potential clients
> might result in the page not even being fetched from the server
> for some, or some thousands, of potential visitors.
>[/color]
Thanks for reminding me of that. I'll plan for it.
[color=blue]
> - Any statistic collected from XYZ.com tells you not
> 'what % of internet surfers..', but instead 'what % of
> internet surfers who visited xyz.com..' a much less useful
> statistic for other web hosts.
>[/color]
Except that most users that I will monitor are logging in to secure
applications. Therefore it can be done on a per user basis if I desire.
Aside from that, it could be done on a per session basis for less accurate
results and possibly with IP matching if one wanted to get ambitious.
[color=blue]
> OTOH, I myself am interested in setting up just such a 'testing
> machine' as you have been discussing across various groups, even
> with the potential for misinformation and misuse of the information.
>[/color]
OT: How are you planning on writing it? I'm thinking about a JAR that can be
dropped into a webapp along with maybe a redirecting index.jsp.
[color=blue]
> I was thinking of..
> - feature detection for JS, I also wanted to attempt to use JS
> in efforts to determine what pixel size is '100%' in browsers,
> more to prove that you cannot second guess, and should use '100%'.
> - CSS import hacks (possible user input required)
> - testing for browser recognition of common media types
> - Java support (both version and browser functionality,
> particularly showDocument and whether the browser/VM
> combo. steals the focus)
>[/color]
Hmm, interesting ideas.
[color=blue]
> Of course, with you with your teeth into it and me having
> put my plans on the back burner, it sounds as though you will
> beat me to the punch!
>[/color]
We'll see. It's just a hobby project atm :)
[color=blue]
> In answer to your specific question, you might experiment
> with this..
> - Test the browser for met-refresh redirects.
> - If successful, go to a page that has a refresh for 10 seconds
> - ..but also has a JS that redirects immediately to
> 'YesWeHaveJSTha tWillRedirectAP age.jsp'
>[/color]
I've considered something along these lines.

[...]
Thanks for the thoughtful reply.

[Dr John Stockton]

Re: Detecting JS enabled/capable browser

JRS: In article <D6adnf7H47YZa0 3cRVn-2A@texas.net>, dated Tue, 28 Dec
2004 00:00:28, seen in news:comp.lang. javascript, Ryan Stewart
<zzanNOtozz@gSP AMo.com> posted :[color=blue]
>"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
>news:cqpgt7$mq s$1$8300dec7@ne ws.demon.co.uk. ..[color=green]
>> Richard wrote:[color=darkred]
>>> Ryan Stewart wrote:
>>>> I'm working on a project to collect web application usage
>>>> statistics. What are the recommended ways of detecting
>>>> whether a browser is JavaScript enabled and/or capable? ...[/color]
>>
>> The recommended approach is to arrange to not have to care. That avoids
>> the consequences of the aspects of HTTP that make any form of statistics
>> gathering flawed to the point of being useless, the impossibility of
>> implementing any mechanism for determining that client-side scripting is
>> available without an omniscient knowledge of all scriptable web
>> browsers, and the fact that such information is next to useless anyway.
>>[/color]
>I always arrange to not have to care. I'm simply curious and would like to
>have some numbers to show. I would guess that about 95% of the users that I
>code for are using IE 6. Of the rest, most probably use NN 7. That's
>something I'm going to find out, and I'd also just like to know how many of
>them have turned off JS. I'm guessing that percentage will be very low--in
>the neighborhood of 2%. I am also curious as to what about HTTP makes you
>think that statistics gathering is pointless.[/color]


If you really do not care whether your script is enabled or not, then
that can only mean that your scripting adds no value. In that case,
writing script is a waste of your time and a waste of your employer's
time, and delivering script is a waste of Internet and users' resources.
But it may serve to inflate someone's ego.

If it is possible to present a useful page, section, paragraph, ... on
the subject without using script, then one should arrange to present in
that manner if script is not available.

If it is not possible to do anything useful without script, then the
user should be informed that there is a prerequisite for a useful
experience, called "javascript enabled", and that he is advised to seek
a system with that property.

If the scriptless experience is not as useful as the scripted one, then
the user should also be told; he may prefer to seek the better
experience, and it may be easy enough to find it. He may just have
forgotten to re-enable scripts!


One can, of course, take a commercial decision that as 98% of users have
script enabled there's no need to bother about the others; why invest
resources on 2% of possible customers? That is the attitude that was,
in the past, taken towards the physically-disabled - enough customers
can climb the steps into out shop, no point in bothering about the rest.


One thing that one can, AIUI, learn by reading javascript books, web
pages, and newsgroups is that a recommended approach, even a commonly-
recommended approach, is not necessarily an optimum, or even a sensible,
one.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Dr John Stockton" <spam@merlyn.de mon.co.uk> wrote in message
news:G4q9yMRRlV 0BFwsS@merlyn.d emon.co.uk...[color=blue]
> If you really do not care whether your script is enabled or not, then
> that can only mean that your scripting adds no value.[/color]
[...]

In general, what you propose is essentially what I do. That is what I meant
by saying I arrange not to care. However, that's not relevant to this
question. I'm not trying to find out whether "my script" will run or not. I
am not writing a script. I'm writing a code library to gather information
about my customer base. Part of my reason for doing so is so that when my
coworkers ask why we should write web applications that don't rely on
JavaScript for proper functionality, I can pull up the logs and say,
"Because x% of users/hits on our other applications were browsers with
scripting disabled." I'm guessing x will be a very low number, so I won't
really be able to use this argument, but that will be nice to know as well.

[Jim Ley]

Re: Detecting JS enabled/capable browser

On Tue, 28 Dec 2004 12:37:02 -0600, "Ryan Stewart"
<zzanNOtozz@gSP AMo.com> wrote:
[color=blue]
>"Andrew Thompson" <SeeMySites@www .invalid> wrote in message
>news:1gtn9yg1f h2sz.773729p30b 2x.dlg@40tude.n et...[color=green]
>> Speaking from my own experience, I might add the following points..
>>
>> - Is a reported figure of '3/10,000 IE 4' users to be trusted?
>> Or is it that the site crashes IE 4 on the entry page, and
>> IE 4 users get no further (and spend no *money*) on the site.
>>[/color]
>I can guarantee 99.999999999% plus that nobody will hit this (where I'm
>planning to use it) with IE 4 or any outdated browser. Even if someone does,
>and the site crashes in it, we are likely to hear about it to fix it, so
>long as the user has a reason for using such a browser.
>[color=green]
>> - Browser UA strings are notoriously inaccurate.
>>[/color]
>I plan to match them nearly character for character and collect unrecognized
>ones for research.[/color]

Then well over 50% of all your visitors will be using unrecognised
ones, character for character is possible, but with IE, plugins and
UA's built in IE recording all sorts of things in the UA string then
these will be changing daily. Then there's mozilla of course which
has many families and people using daily builds, and more...
[color=blue]
>[color=green]
>> - Caching of the page between server and potential clients
>> might result in the page not even being fetched from the server
>> for some, or some thousands, of potential visitors.
>>[/color]
>Thanks for reminding me of that. I'll plan for it.[/color]

but how are you going to effect your collection of statistics bases on
this (it's not unreasonable to assume differently capable UA's have
different caching behaviour, we know for a fact IE in "check each
time" and mozilla in "check each time" cache settings exhibit
different behaviour with IE well over-represented in any requests.
[color=blue][color=green]
>> - Test the browser for met-refresh redirects.
>> - If successful, go to a page that has a refresh for 10 seconds
>> - ..but also has a JS that redirects immediately to
>> 'YesWeHaveJSTha tWillRedirectAP age.jsp'
>>[/color]
>I've considered something along these lines.[/color]

so what happens when script is enabled but meta is disabled, or meta
is on a prompt basis, or javascript is on a prompt basis - all of
which are possible in Internet explorer, let alone other user agents.

Jim.