Detecting JS enabled/capable browser

[Jim Ley]

Re: Detecting JS enabled/capable browser

On Tue, 28 Dec 2004 13:02:09 +0000, Dr John Stockton
<spam@merlyn.de mon.co.uk> wrote:[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. 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.[/color]

If 90% get the enhanced behaviour from the script, then it's an
extremely effective use of resources, if 10% don't then so what, it's
not hurt them, but neither has the lack of site functionality the
alternative approach yields.
[color=blue]
>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.[/color]

You've got to assume users are thick, 'cos generally they are (or
rather they're probably just lazy, there's other places to
buy/visit/etc.) and they won't understand what you're saying and will
just leave. Script can always be done just to add value, sometimes
incredible value, so it's well worth doing it. There's almost never a
sound reason to just use script other than the ego or laziness of the
author.
[color=blue]
> 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.[/color]

Except of course, that was a mistaken approach, which has led to
significant repair costs from all such businesses that took that
approach, when it would've been much cheaper to do it properly
correctly in the first place.

Jim.

[Gus Richter]

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]

You may find these to be useful:
http://www.faqts.com/knowledge_base/...id/3459/fid/47
http://www.faqts.com/knowledge_base/...aid/323/fid/47

--
Gus

[Andrew Thompson]

Re: Detecting JS enabled/capable browser

On Tue, 28 Dec 2004 20:00:13 GMT, Jim Ley wrote:
[color=blue]
> On Tue, 28 Dec 2004 12:37:02 -0600, "Ryan Stewart"
> <zzanNOtozz@gSP AMo.com> wrote:
>[color=green]
>>"Andrew Thompson" <SeeMySites@www .invalid> wrote in message
>>news:1gtn9yg1 fh2sz.773729p30 b2x.dlg@40tude. net...[/color][/color]
...[color=blue][color=green][color=darkred]
>>> - 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]

I am not sure I understand the finer intricacies of what you wrote,
Jim, so I thought I'd leave it but add. Ryan.. what about the UA's
that claim (character for character) to be IE?

The original intent of browser string spoofing was to get around the
idiotic web-designers who attempt to make a 'Netscape only/IE only' site.

In my plan, the only reason to collect UA strings was to cross-match
them against the information discovered through the CSS import hacks
(which reveal the core rendering engine of an UA) and a slew of JS
feature detection (also to help narrow down the UA), and thereby get
some gauge of the level of browser string spoofing.
[color=blue][color=green][color=darkred]
>>> - 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.[/color]

Interesting points. Ryan wants to do this as a silent app.
(which will be much more difficult) but the testing facility
I planned would ask for active user involvement as a prerequisite,
so it might be handy to forewarn them of the prompts and ask
them if prompts were encountered. (Yes, yes, ..I know! 'The User',
the single least reliable source of information available)

--
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

[Richard Cornford]

Re: Detecting JS enabled/capable browser

Ryan Stewart wrote:[color=blue]
> Richard Cornford wrote:[color=green][color=darkred]
>>> Ryan Stewart wrote:
>>>> I'm working on a project to collect web
>>>> application usage statistics. ...[/color][/color][/color]
<snip>[color=blue][color=green]
>> 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, ...[/color][/color]
<snip>[color=blue]
> I always arrange to not have to care. I'm simply curious
> and would like to have some numbers to show.[/color]

The desire to have numbers to show is completely understandable, but
numbers are not particularly useful in themselves. You need to know what
those numbers really mean, and be in a position to explain their meaning
to others.
[color=blue]
> 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,[/color]

I don't think you will find that out, unless you are in a position to
tell me which 3 of the web browsers I have installed on this computer
send the User Agent header:-

Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

- by default (literally), and distinguish between them (and there is a
good chance that you have never even heard of the two that are not IE
6).
[color=blue]
> and I'd also just like to know how many of them
> have turned off JS.[/color]

The usual proposal is to have some JS execute in a way that will send
evidence of its action back to the server. But a client with JS enabled
cannot guarantee the success of that action as it will be at least in
part dependent on the DOM provided by the browser, and will be subject
to language implementation bugs (ECMA standardisation has gone a long
way towards removing language implementation bugs but there are still
some). So any test script is virtually guaranteed to be incapable of
performing the required actions on at least some clients and so will
result in a false indication of a javascript incapable client.

But knowing a client's willingness to execute javascript remains
pointless, given javascript capable clients with such limited DOMs that
simple form validation is about the limit of their capabilities.
[color=blue]
> 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]

Caching is the main factor. Clients cache and organisations like ISPs
operate large-scale caches. HTTP is designed to encourage caching so
many request-response transactions will never arrive at the server(s)
for any given site, instead being handled by an intervening cache.
Clients often have user (and administrator) configurable cache settings
and exhibit different behaviour even with superficially similar cache
settings. And the other caches mean that the customers of one ISP may
have considerably more requests served from a cache than the customers
of another. The exact behaviour and characteristics of these caches is
impossible to gauge.

It has been proposed that this caching is already essential as the extra
load imposed on the network of having to route each and every
request/response to/from the actual server responsible would result in
traffic too heavy to be handled.

Obviously, with only a proportion of requests actually arriving at the
server, any statistics gathered on the server cannot be complete. And
the extent to which they may be representative of total requests cannot
be determined (or even estimated) because the information needed to do
that is never available.

This, and the many other factors that a well worded google search would
highlight, leave me thinking that any effort directed at the gathering
of web statistics would be wasted.

The consequences of individuals placing any trust in web statistics
(Think: Hans Christian Anderson's "The Emperor's New Clothes") produces
a feed-back effect that contributes to the meaninglessness of those
statistics. You often encounter people asserting that it is OK to build
IE only JS dependant web sites because their server logs show only a
tiny percentage of visitors not using IE with JS enabled. But given an
IE only, JS dependent web site, is it surprising that users who do not
fall into that category do not hand around on such a site producing log
entries? It becomes a chicken and egg situation where the statistics are
being used to justify the design decisions, while the statistics are
heavily biased by the consequences of the decisions that they were used
to justify.

In the end I think that web statistics are used to re-enforce prejudices
or justify decisions that were going to be made anyway, and so long as
those statistics broadly conform to the expectations of the interested
parities then they will not be (sufficiently) questioned and their
(in)accuracy won't make much difference. In which case I can see no
reason for going to any effort to gather and analyse any data, instead
it would just be a matter of finding out what the
expectations/prejudices of the interested parties were and generating
numbers that broadly conform with them. A set of meaningless numbers
derived with baseless assumptions is not really different from a set of
numbers directly based on assumptions and prejudices.

Richard.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:cqt6bt$a6f $1$8300dec7@new s.demon.co.uk.. .[color=blue]
> I don't think you will find that out, unless you are in a position to
> tell me which 3 of the web browsers I have installed on this computer
> send the User Agent header:-
>
> Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
>
> - by default (literally), and distinguish between them (and there is a
> good chance that you have never even heard of the two that are not IE
> 6).
>[/color]

No, can't do that. I'd imagine the two "others" are something somebody coded
independently and didn't bother coming up with their own UA string since the
IE one worked just fine. But it's fairly irrelevant to my situation, and
completely so to this post.

[...]

Thanks for the JS advice. That's all I came here for.

[Richard Cornford]

Re: Detecting JS enabled/capable browser

Ryan Stewart wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> I don't think you will find that out, unless you are in a position to
>> tell me which 3 of the web browsers I have installed on this computer
>> send the User Agent header:-
>>
>> Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
>>
>> - by default (literally), and distinguish between them (and there is
>> a good chance that you have never even heard of the two that are not
>> IE 6).[/color]
>
> No, can't do that. I'd imagine the two "others" are
> something somebody coded independently[/color]

Independently of whom, Microsoft?
[color=blue]
> and didn't bother coming up with their own UA string
> since the IE one worked just fine.[/color]

They are both the produces of commercial software houses, and currently
under active development. The spoofing IE's UA string 100% is probably
deliberate as it is not unusual for less skilled/knowledgeable web
developers to attempt to actively exclude UAs that are not IE from their
web site, or provide a limited (and often out of date) alternative for
UAs they don't recognise, regardless of the actual capabilities of those
UAs. If admitting to be a browser that those developers have never heard
of results in the user getting an inferior experience then it is
obviously better for those browsers to clam to be a browser that has
come to the attention of web developers. Another feed-back effect that
diminishes the usefulness of web statistics.
[color=blue]
> But it's fairly irrelevant to my
> situation, and completely so to this post.[/color]
<snip>

If you want to know what percentage of IE users disable javascript then
not being able to tell IE from browsers claming to be IE represents a
significant limitation.

And if you are going to assume that those browsers represent an
insignificant contribution to your figures then you are applying your
own prejudices to your task. You have no evidence that your prejudice is
valid (because all web statistics suffer exactly the same problem) and
as a result you eventual figures will be no more significant than
figures you make up directly based on those prejudices. In which case
you may as well fabricate the figures and save yourself the trouble and
expense of gathering and analysing any data.

Richard.

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:cqtkbp$p7s $1$8300dec7@new s.demon.co.uk.. .
[...][color=blue]
> If you want to know what percentage of IE users disable javascript then
> not being able to tell IE from browsers claming to be IE represents a
> significant limitation.[/color]
[...]
I grow weary of this argument. All I want here is JS suggestions. Nobody
here knows my environment orwhat I have to be able to do to gather useful
information.

[MyndPhlyp]

Re: Detecting JS enabled/capable browser


"Ryan Stewart" <zzanNOtozz@gSP AMo.com> wrote in message
news:CIWdncBngt rGKk_cRVn-iw@texas.net...[color=blue]
> "Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
> news:cqtkbp$p7s $1$8300dec7@new s.demon.co.uk.. .
> [...][color=green]
> > If you want to know what percentage of IE users disable javascript then
> > not being able to tell IE from browsers claming to be IE represents a
> > significant limitation.[/color]
> [...]
> I grow weary of this argument. All I want here is JS suggestions. Nobody
> here knows my environment orwhat I have to be able to do to gather useful
> information.[/color]

Ryan:

It seems to be habitual in the NG (by some) to pick nits, prove one's
omnipotence, find flaw in other's suggestions, and bash Americans rather
than offer solutions.

Although not perfect, your best bet (as already suggested in varying
methods) is to use some client-side JavaScript to determine if JavaScript is
enabled.

Set up your navigation links wrapped in <div>'s (or <span>'s) setting one
with a display property of none and the other with a display property of
block, inline or list-item as appropriate. The <div> with the none display
property would have its href URL indicate that JavaScript functioned. The
<div> that displays by default would have its href URL indicate JavaScript
did not function. Use the client-side JavaScript to flip the display
properties when the page loads so that the hidden <div>'s become visible and
the visible <div>'s become hidden.

In forms, you can utilize hidden fields and do similar majik to change the
default value of the hidden field when the form is submitted.

The URL parameters (or form values), or the lack thereof, get picked up by
the next page that makes the determination and logs the results accordingly.

Far from perfect when judged by the anal-retentive. If the browser doesn't
support CSS1, both <div>'s may or may not display. The JavaScript may have
to be sensitive to the various browsers in order to successfully change the
display property. And there are other things that can get in the way not to
mention the labor intensive maintenance of this. You might want to limit
yourself to just the main page of the site while doing the URL/form
processing in the pages linked to by the main page. It should at least give
you a rough idea of what your community has.

[Lee]

Re: Detecting JS enabled/capable browser

MyndPhlyp said:[color=blue]
>
>
>"Ryan Stewart" <zzanNOtozz@gSP AMo.com> wrote in message
>news:CIWdncBng trGKk_cRVn-iw@texas.net...[color=green]
>> "Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
>> news:cqtkbp$p7s $1$8300dec7@new s.demon.co.uk.. .
>> [...][color=darkred]
>> > If you want to know what percentage of IE users disable javascript then
>> > not being able to tell IE from browsers claming to be IE represents a
>> > significant limitation.[/color]
>> [...]
>> I grow weary of this argument. All I want here is JS suggestions. Nobody
>> here knows my environment orwhat I have to be able to do to gather useful
>> information.[/color]
>
>Ryan:
>
>It seems to be habitual in the NG (by some) to pick nits, prove one's
>omnipotence, find flaw in other's suggestions, and bash Americans rather
>than offer solutions.[/color]

Some people find such criticism (when polite) to be more useful than cookbook
advise. Would you really be willing to trust advise from a newsgroup where
people weren't eager to find flaws in each others suggestions?

[Ryan Stewart]

Re: Detecting JS enabled/capable browser

"Lee" <REM0VElbspamtr ap@cox.net> wrote in message
news:cqui88011i u@drn.newsguy.c om...[color=blue]
> MyndPhlyp said:[color=green]
>>Ryan:
>>
>>It seems to be habitual in the NG (by some) to pick nits, prove one's
>>omnipotence , find flaw in other's suggestions, and bash Americans rather
>>than offer solutions.[/color]
>
> Some people find such criticism (when polite) to be more useful than
> cookbook
> advise. Would you really be willing to trust advise from a newsgroup
> where
> people weren't eager to find flaws in each others suggestions?
>[/color]
Absolutely. I welcome any ideas/criticisms related to my question. This is a
JavaScript group, and I asked a JavaScript question. I'm getting a lot of
non-JavaScript related answers, which are thought-provoking, but largely
irrelevant to what I'm trying to accomplish. I definitely appreciate
MyndPhlyp's input. I hadn't thought of the div flipping idea before. One
other thing that I should have included in my original post, but have
mentioned several times since in this thread, is that solutions only need to
work in relatively modern and mainstream browsers, as that's what my users
will have.

[Dr John Stockton]

Re: Detecting JS enabled/capable browser

JRS: In article <41d1bb56.35308 2375@news.indiv idual.net>, dated Tue, 28
Dec 2004 20:05:46, seen in news:comp.lang. javascript, Jim Ley
<jim@jibbering. com> posted :[color=blue]
>[color=green]
>>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.[/color]
>
>You've got to assume users are thick, 'cos generally they are (or
>rather they're probably just lazy, there's other places to
>buy/visit/etc.) and they won't understand what you're saying and will
>just leave. Script can always be done just to add value, sometimes
>incredible value, so it's well worth doing it. There's almost never a
>sound reason to just use script other than the ego or laziness of the
>author.[/color]

One should assume, when authoring, that where users are thick authors
should be smarter - in particular, that the author can write in terms
which will be useful to the user, even when the terms are not fully
understood.

But note that I wrote, quoted above "If it is not possible to do
anything useful without script" - in that case, the best thing the users
can do is just leave.

[color=blue][color=green]
>> 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.[/color]
>
>Except of course, that was a mistaken approach, which has led to
>significant repair costs from all such businesses that took that
>approach, when it would've been much cheaper to do it properly
>correctly in the first place.[/color]

Exactly.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demo n.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.