Hi,

Just had an interesting message from someone who was unable to view one of
my sites because they have JavaScript turned off, and expecting me to
re-write my site so that they could view it...

I'm interested in hearing other people's opinions about this. I use
JavaScript all the time, and can't really imagine ASP.NET development
without it...

Mark

Having JavaScript turned off is certainly a possbile scenario, but in my
experience (especially with XP SP2 & the "Information Bar"), it is rare.

When I build a site for the general public, I assume JavaScript will be
available.  If one person contacted me and told me that my site didn't work
because they have JavaScript turned off, I'd tell them to turn it on,
period.  Again, the XP Information Bar (assuming they run Windows) will
protect them when a page contains JavaScript, so there really is no reason
to turn it off there.

Show quote

Hide quote

Me too.

Me too.

They were actually using a Mac...:-)

In article <uTFfzeP0GHA.2***@TK2MSFTNGP06.phx.gbl>,

Show quote

Hide quote

Yep, although as I have mentioned to you already, I'm having a look at
Opera's functionality in this area.

Now a few comments on why I routinely run with JavaScript disabled. :-)

o - With older browsers it was an easy way to get rid of unwanted pop-ups
    and redirections, especially unwelcome when I was on dial up and
    it could cost me.

o - I had a potentially embarrassing episode at work when reading a
    newsgroup item which redirected via JS (eventually) to a porn site.
    Fortunately I caught it in time, but turning JS off was a no brainer.
    OK, that was an ancient version of Netscape, but the lesson stuck.

o - I do have a security conscious background, and keep up to date with
    what potential security holes are out there. For example, it is only
    recently that potential exploits were found in the FireFox/Mozilla
    family of products, and the recommended precaution was to disable
    Javascript. US-CERT reports for April, May and June 2006 can be found
    for these at

    http://tinyurl.com/fmtyo

o - A couple of years ago I came across a new job website, and the
    authors were asking for comments. Fine, but they refused point blank
    to support Netscape, and wouldn't let you into their site with it.

    *But*... My employer was at that time still running on Netscape 4.7.
    They had a huge amount of internal applications which all needed to
    be validated on newer browsers, and we were expressly forbidden from
    downloading or installing anything more modern meanwhile (the price
    of adopting web enabled applications early on in the game).

    The website authors couldn't get their heads around the fact that
    I wasn't free to simply install the alternative browsers they
    suggested.

Going slightly off topic now, but I must mention that from approximately
2001 on, one of the (formerly major) job agencies here steadfastly
refused to support any browser except MSIE for accessing their website,
using the argument that "95% of our visitors use MSIE, we don't care
about the rest".

Big whoopsie there, as the employer that I am talking about above had
over 30.000 well locked down PCs still using Netscape.

The 5% that the agency "didn't care about" included the hiring managers
for those 30,000 plus people, so in this case at least, looking at the
raw numbers isn't quite so straightforward.

Just some food for thought from "the other side of the fence" :-)

Mark,

Lack of imagination is not a problem. Lack of ability is. You won't be able
to. Neither me.

Well, it's interesting, and has got me thinking a bit...

You'll have heard of the 80/20 theory of software development & usage...?

1) approximately 80% of commercial software users use approximately 20% of
that software's functionality (think of Excel...)

2) generally speaking, 80% of commercial software development requires 20%
of the whole project's resources, because it's been done before - it's the
last 20% of development which takes the time and money, because it's the
"hard bit"... :-)

Most web developers spend a fair bit of time (and, therefore, money) making
sure their sites work correctly on MacOS as well as Windows, yet MacOS
represents only 3% of the browser OS market:
http://www.thecounter.com/stats/2006/August/os.php

By the same argument, browsers with JavaScript turned off accounted for 6%
of all web hits last month:
http://www.thecounter.com/stats/2006/August/javas.php so you might logically
posit an argument that we, as developers, should be spending twice as much
time and effort in getting our sites to work in that scenario...

Hi,

Mark Rae wrote:

<snip>

I am not sure that so many web developers care for Mac. My aim is to
code as standard as possible (using Firefox as a reference), and then to
check in IE if everything works as I want, with minor corrections if
needed. If I happen to have a Mac around, I'll check my sites to see if
everything is OK, and this is usually the case.

When I started making websites, I once read that 60% of a web
developer's time was used to ensure compatibility between the two major
browsers (back then, Netscape 4 and IE4). I think that the browsers (and
the development environments) improved a lot since then, and I estimate
this time down to 10% max, including HTML, CSS ad JavaScript.

With Microsoft's new taste for JavaScript (what, with ATLAS and all),
these 6% are very likely to drop soon.

HTH,
Laurent

Hi,

Mark Rae wrote:
My rule of thumb is: the site should offer minimal functionality without
JavaScript, but not more. If JavaScript is turned off, I lead the users
to a page where I explain to them how and why they should turn it on.

HTH,
Laurent

I'd be interested in seeing what you put on that page - can you post a URL?

Hi,

Mark Rae wrote:
http://www.galasoft-lb.ch/nojs.html

I use it like this:

<a href="nojs.html" onclick="myJavaScriptFunction();return false;">
This is a link using JavaScript only</a>

HTH,
Laurent

I actually prefer sites without it but from a commercial design perspective
you design a site with a specific target audience in mind and for many
dynamic sites that involves using javascript.  For non-dynamic sites I try
to cater for non-javascript browser, but its usually too expensive and time
consuming to even consider.  Think of all the flash sites around - how many
people refuse to use a flash site, the number is falling all the time.  If
you dont use flash you cant use the site - if someone wants to use a site
they turn it on, same with javascript.

The call is that if it needs javascript to function then thats a design
feature of the site, and you have to question how much work is involved in
making it work for the minority who wish to use it without javascript -
usually you can throw away the minority who cant make their browser work,
safely with javascript.  If however that means losing customers and each
sale is quite important then you have to make your sites work without it.

Regards

John Timney (MVP)

Show quote

Hide quote

Not if the proportionally small additional revenue which that would bring in
is actually less than the cost of making the site non-JS compliant in the
first place... :-)

I dont disagree with you - as I said it depends on if each sale is important
enough to the business to justify the investment.  One caveat would be that
I have though come across sites whose main driver was to get numbers up to
help build a brand or increase awareness, not to actually make sales.  In
this type of scenario proportional compatability can make a significant
business case - but we should still target a site based on well thought out
requirements.  If Javascript's not seen as a necessary (or is) then code
accordingly.

Regards

John Timney (MVP)

Hi John,

I *somewhat* agree with you on some of your points, but JavaScript is no
longer an extra that delivers *features* to web sites.  It has become a
ubiquitous part of web design.  Just as you wouldn't be able to have a web
page without HTML, in today's world, you can't have functioning eCommerce
sites without CSS, XHTML, XML and yes, JavaScript.  Since all modern
browsers have the capabilities to support these things and there are
sufficient software packages out there to protect a user against malicious
JavaScript, I subscribe to the camp that says, if you want to use this site,
turn the feature on.  All others can crawl back under their rocks.  :)

-Scott

Show quote

Hide quote

Well said! I couldn't agree more.

Mark Rae wrote:

Show quote

Hide quote

Ooh! Ooh! It looks like I'm going to be the one dissenting voice.

We put a new website live last week. Whilst it is anonymous, we do
collect a lot of diagnostic information. From one week alone, we're
seeing 20% of sessions where javascript is turned off (yes, that figure
surprised me to).

Our design ethos was, thankfully:
If the user has javascript, make the experience work slickly.
If the use doesn't have javascript, make the site work.

So, whilst a user with JS gets a smooth experience (such as an AJAX
based predictive text drop down), a non JS user can at least get
through the site unscathed (though possibly moaning about some of the
postbacks that have to occur).

Damien

Show quote

Hide quote

Fair enough - that's your decision.

I use the new <asp:Menu> control a lot in my sites these days, and that
(AFAIK) simply will *NOT* work properly with JavaScript disabled.

If I have to find a different method of site navigation just for the
paranoid few, I may as well not bother using the <asp:Menu> control at
all...

Mark Rae wrote:

Show quote

Hide quote

True, our site is still under 1.1, so we didn't get to use any of these
features. But having looked at our revised figures, we're now running
at 27% of sessions not having script available. I wonder if it's some
quirk of our target market, but I wouldn't describe 1/4 of users as a
few. (And no, we're not in a "security concious" market - our clients
are people with debt problems)

Damien

I'm sure it must be. The reason I use theCounter.com's stats is because
their counters are one of if not the most popular counters out there, and
their stats are based on hundreds of millions of hits - 118,800,730 for the
month of August 2006 which, by any test of reasonableness is a
representative sample...

Mark Rae wrote:

Show quote

Hide quote

Interesting site. Can anyone explain the following two observations (or
am I reading too much into the statistics):
1) At the end of last year, no javascript was running at ~10%. In
January, it shot down to ~3%. What happened?
2) From January onwards, it's been slowly trending upwards from 3% to
the current 6%

Damien

Damien,

I think thats a fascinating figure and a huge number to consider, would you
care to speculate as to why it could be your target market?

Show quote

Hide quote

John Timney (MVP) wrote:
Not really sure why it'd be our market especially, just the bare fact
that our experience is saying 20%, whereas global stats are showing 6%.

One speculation might be that our clients will tend to access our site
from their workplaces (not paying for internet at home), and that it's
more likely to be something locked down in a corporate environment.

Or maybe we just don't have a large enough sample size yet (we have
1500 clients having had, between them, 2300 sessions on the site. The
20% is based on the number of sessions in which JS is disabled).

Damien

In article <1157538697.683286.28***@e3g2000cwe.googlegroups.com>,

Show quote

Hide quote

Since you mentioned that it is a charity, do the counsellors themselves
recommend access points (public libraries etc) for those with out
internet access at home? If so, that may give you a pointer.

As John said, 27% is an enormous proportion, so much so that if I were you I
would want to reassure myself of its accuracy.

How are you collecting this information? Is it something you're written
yourself, or is it something like WebTrends...

Mark Rae wrote:
Because our site deploys different behaviours based on whether we have
javascript available or not, we have to collect the information
directly in our site (and record it in our database).

We send the user through a page which has a javascript block that
redirects using window.location and a meta refresh set for five seconds
(and if that path is taken, we decide that script isn't available).
That's all that this page does. I suppose we might get a false negative
under the following circumstances:
1) Part of the page loads, enough so that the meta refresh is seen, but
not enough that the script block is encountered
2) The remainder of the page does not arrive within five seconds
3) The browser respects the refresh tag before the page has loaded

Does anyone know if (3) is true or not?

Damien

Hmm - that certainly does sound pretty reliable...

I think it almost certainly does.

Have you not considered the <noscript></noscript> tag instead...?

Mark Rae wrote:

Show quote

Hide quote

Well, we're planning to swap the order in the <head> such that the
script appears above the refresh, but I still think it unlikely (with
such a small page) that it'd break in exactly the right place so
reliably to give lots of false negatives. Maybe (as I put in another
post), we just haven't had enough activity yet.

Damien

I'm not convinced that would make much difference...

I would go to management and explain it is hard to implement "AJAX"
without the "J".  The ability to disable script is primarily for
security purposes.  If your site is a valid commercial site, there
would be no reason for the user not to trust it.  However, depending on
your business... that may be another story.

Check if it is enabled and redirect to a page explaininig how to take
care of it.  If you support multiple browsers, do it for each based on
the type of browser they are accessing from.  Again, if you are on the
up and up, explain you're not collecting information, installing bad
stuff etc., (with a disclaimer that you can't be held responsible for
things they download, and all the other legal blah, blah...)

Regards
Coleman


Damien wrote:

Show quote

Hide quote

Coleman wrote:

Show quote

Hide quote

We're a charity, and we seek to help people with debt problems, so
fairly legit. However, we've always been keen to do no harm, so we get
by without javascript (but enhance the experience with it), and we're
not even allowed to set cookies :-(

Damien

Hi,

Damien wrote:
That's my aim also when I design a web application (note: I develop web
applications, that's different than a website). However, this is not
always possible. Simple example: Our last web application (building
automation management station running in a web browser) is licensed. The
licensing scheme is implemented using a lease mechanism: The licenses
are leased for 1 minute, and the lease is renewed every 30 seconds as
long as the web application is active. However, to avoid that the user
has to send postbacks to the server every 30 seconds (!), we use web
services to "trigger" the server and renew the lease. This feature is of
course non-operant if JS is off, and in that case we do not allow the
user to use our web application.

Fr a website, I try to follow your "design ethos" as much as I can.

Maybe they can't afford a JavaScript enabled browser? :-)

Laurent

Excuse me for jumping into the thread at this late stage, but as the
"guilty party" who triggered Mark's question, I thought I'd put my point
of view.

In article <1157534039.568557.232***@i42g2000cwa.googlegroups.com>,

Show quote

Hide quote

I personally think that allowing non-JS users into a site, albeit
without the "smooth experience" is the way to go (and if I choose to
turn JS off or use an ancient browser, it's my decision, and I am quite
happy to accept the consequences of that decision, in terms of
potentially ugly screens, trickier navigation etc).

How did our conversation start?

Mark posed a question over on a Mac newsgroup asking for comments about
a particular bit of behaviour in Safari, and here was my initial
response:

---- start quote ----
Ah. I have JavaScript turned off in Safari, and see nothing but a blank
page.

Please consider making the website friendly for folks like myself who
prefer to run with JavaScript turned off.
---- end quote ----

(I should have said *friendlier* there, as I was not asking for the full
shooting match, just something better than a blank page.)

My intention was to persuade Mark to display the logo and a bit of text
about the site for non-JS users, explaining why they couldn't get any
further.

Instead he came back with a much better solution. Not only could I see
the logo, but clear instructions on how to enable JS in a variety of
browsers. Better yet, when I persevered, I could get into enough of the
site to see what it was about (approx. 80% of it), and make a decision
as to whether I'd come in with full JS enabled.

Interesting. In that environnment I'd tend to put it down to running
oldish kit, whether it be stuff at home or cheap/free public access
points. Do you have any stats on how many are using dial up access? Cost
savings there may be a motivating factor. I know that when I was on dial
up access I watched my phone bill like a hawk.

Looking on the grim side, there could be a lot of out of work IT folks
using your services ... :-(

One thing this thread has not touched on is the need to cater for disabled
users across a web site, and its an area where use of Javascript will always
score poorly and is a pressing design issue for web designers worldwide with
new legislation having the potential to affect design choices.  A compliant
site containing JavaScript will typically be fully accessible if the
functionality of the script allows device independency, in other words it
can work if the user only uses a mouse, or if the user only uses a
keyboard - and the content can still be accessed if javascript is not
enabled.  There is a requirement that sites should be fully functional with
JavaScript disabled in section 508 of the Web Content Accessibility
Guidelines.

So its not that Javascript in itself is a good or a bad addition to a web
site, it should not form the underlying driving mechanism for a site.  As to
the asp.net controls, the menu control itself allows for static menu items
to assist with accessibility but it does require javacript to function.  It
does though have elements added to assist with accessibility.  For those of
you looking for extra information the section in MSDN tells you which
controls will require client script:
http://msdn2.microsoft.com/en-us/library/ms227996.aspx so you can determine
which controls are likely to be problematic to non-javascript users.

Regards

John Timney (MVP)

Show quote

Hide quote

Hmm - you're right - that's something I hadn't even remotely considered...

In article <O$vl$#Z0GHA.1***@TK2MSFTNGP02.phx.gbl>,
That is something I am acutely aware of. I live in a spa town, where
there are quite a few associated health clinics.

The official town website is bad enough to navigate with a mouse, let
alone a laptop trackpad. I would have thought that with the potential of
using the website for promoting this aspect of the town, they would have
thought of accessibility issues.

But how many of the 20% of the sessions are distinct and unique visitors and
how many of the 20% are the same visitors returning?

Show quote

Hide quote

3 password in asp.net Login control
Retrieve a value from a PopUp
FindControl in Class
regular expressions
Ambiguous Name In Mamespace?