«

I'm working on a web site that could use some control using js but am
concerned about what problems I may have with potential users having
their js turned off. Has anyone had any serious problems with this
sort of thing? I know some of these potential users are with big
companies and am wondering if anyone had real problems with that.

drhowarddrfine wrote:
> I'm working on a web site that could use some control using js but am
> concerned about what problems I may have with potential users having
> their js turned off. Has anyone had any serious problems with this
> sort of thing? I know some of these potential users are with big
> companies and am wondering if anyone had real problems with that.

Worst case, a user with Javascript disabled is unable to use your site.
However, this is a problem that can be compensated for, by making your
web site "degrade" gracefully. This means more work for you, the
developer, but it provides the intended experience for a wider range of
users, including those whose browser either doesn't support Javascript,
or has it disabled.

How much work you spend making your website usable on older versions of
browsers or those with Javascript disabled really depends on your
target audience. Optimally, your site will work on the broadest
possible range of browsers and capabilities. However, in the interests
of development time, you may want to target a percentage (say, 95%) of
the site's audience, which can be determined by keeping an eye on
server logs.

"Jc" <> writes:

> However, in the interests of development time, you may want to
> target a percentage (say, 95%) of the site's audience, which can be
> determined by keeping an eye on server logs.

The only problem with this approach is that server logs tends to be
self fulfilling. If you make a site which doesn't work with Javascript
disabled, your server logs will tell you that only people with
Javascript enabled use your site.

Making a page degrade gracefully isn't as hard as you make it sound,
if one thinks of it from the start.

/L 'Pure HTML is 100% accessible. All you an do is detract from that'
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

> From: Lasse Reichstein Nielsen <>
> Making a page degrade gracefully isn't as hard as you make it sound,
> if one thinks of it from the start.
> /L 'Pure HTML is 100% accessible. All you can do is detract from that'

I agree with you 100% with great emphasis. For example, a few years ago
Yahoo modified their Web-based services (mail and clubs->groups) to
where users couldn't join new groups without saying what word is in a
GIF or JPG image. Since my access from home is only via VT100 (text
only) dialup into Unix shell account, then running lynx (text-mode
browser) from there into the Web, I couldn't see any images, I couldn't
join any new groups from home. So that meant that whenever I wanted to
join a new group I needed to make a trip to the public library, sign up
for an hour of "computer" time, wait up to an hour for that hour to
begin, then rush everything I wanted to do during that hour. Then later
at home I could at my leisure I could browse messages in the Group and
post responses, except if the invitation to the group expired by the
time I could get to the library then my trip was wasted and I'd have to
ask for a new invitation and hope I could get to the library again
before the new invitation expired. But at least once I got into a
group, I could use most of its text-based services from home. And their
Mail service didn't allow replying to messages without JavaScript, so
if I wanted to reply I needed to copy the text of the message and the
From: address etc. to a local edit, compose my response locally, then
go to the Compose (new message) feature in Yahoo! Mail and paste in the
address and Subject and my response. It didn't properly link my
response with old message-ID, but at least it basically worked.

Then about a year ago Yahoo changed their Mail service so it's almost
totally unusable without JavaScript. I can log in and see a listing of
how many messages are new in each folder, and I can go to my InBox or
other folder and see all the messages, but there's no way to see which
of the messages in a folder are new and which are old so there's no
reasonable way to visit all the spam so they no longer show as new
messages in the folder summary page, and there's no way to complain
about spam because the SPAM button is now JavaScript, and there's no
way to send outgoing e-mail (either Compose new or Reply to old)
because that requires JavaScript, and there's no way to move spam
messages to another folder or delete them to get them out of my InBox
because both features require JavaScript, and there's no way to move my
legitimate messages out of InBox to get them away from spam, and
virtually all the other Yahoo! Mail features ar likewise unusable from
home because they require JavaScript. I'm totally ****ed at Yahoo's
decision to require JavaScript for virtually *all* their Yahoo! Mail
features, making the service virtually useless to me. It's nice that
they increased their mailbox quota from 6+1 MB to 100 MB, and then
increased it again to a gigibyte or more, but that does virtually no
good if the whole service is unusable from home.

If you're wondering why I'm browsing a JavaScript newsgroup if I have
no access to JavaScript: Well last Fall one of my instructors at De
Anza College gave me his old laptop computer, which has Java on it, and
it's been very useful for the Java class he was teaching at the time,
and for the new J2EE class I'm taking now, and just yesterday I
realized that since the laptop has NetScape which supports JavaScript,
then even though I don't have access to JavaScript online, I *do* have
access to JavaScript locally using
file://localhost/directory.../filename.html, so I now *can* develop Web
pages that make use of JavaScript locally and then upload them to the
net and install them and hope they still work for remote users, so
yesterday I taught myself JavaScript from an online tutorial and
created my first interesting JavaScript WebPage and uploaded it:
http://members.tripod.com/MaasInfo/New/2005.6.13a.html
So today I came online (in VT100 text mode of course) to look for the
JavaScript FAQ that I saw listed yesterday when I was browsing this
newsgroup for JS-programming tips, and discovered your article which I
wished to respond to (above) before continuing to look for the FAQ.

If javascript is turned off, there should be no problems. Your users
shouldn't even realize they are "missing" anything.

Problems arise if you load more javascript than your visitor can handle. I
split my users into all or nothing, because it is more work than I want to
go through to sniff out every platform and browser.

So in the head of my pages I load a script that tests for
document.implementation.hasFeature('html','1.0');
and if it returns true the serious javascript gets loaded; otherwise, no
harm done.

drWot you may have the best option. I'm a little suspicious of this
concern about the use of js when, from everything I've read, 94% or so
of all users have js turned on. Although you could say something like
"now you're turning away 6 out of every 100 viewers" but, as far as I
can figure, if they don't have js on, they probably aren't ordering
online anyway and they can just phone it in.

Some may flame me for that statement but I'm see less need for pulling
my hair out to code for the minority and have-nots and those lacking
knowledge.

On 13 Jun 2005 17:39:30 -0700, in comp.lang.javascript
"drhowarddrfine" <> wrote:

>| I'm working on a web site that could use some control using js but am
>| concerned about what problems I may have with potential users having
>| their js turned off. Has anyone had any serious problems with this
>| sort of thing? I know some of these potential users are with big
>| companies and am wondering if anyone had real problems with that.

Simply use the noscript tag to inform user that they will not have
full access to the site.

<script type="text/javascript">
....
your scripts
.....
</script>
<noscript>
....
message to user with javascript disabled
....
</noscript>
---------------------------------------------------------------
: Remove your pants to reply
---------------------------------------------------------------

Jeff North wrote:
<snip>
> Simply use the noscript tag to inform user that they will
> not have full access to the site.
>
> <script type="text/javascript">
> ...
> your scripts
> ....
> </script>
> <noscript>
> ...
> message to user with javascript disabled
> ...
> </noscript>

One thing that is apparent form searching the comp.lang.javascript
archives for NOSCRIPT is that its use is very rarely proposed (at least
in the current century), and almost never by the more experienced
contributors.

The reason for this is simply that the NOSCRIPT element is not capable
of contributing to the problems of browser scripting for the internet,
and has not been for many years.

The NOSCRIPT element is based on a premise that there are only two
outcomes in browser scripting: 1) The script will work (the environment
supports scripting and the script will fully achieve what is expected of
it, and 2) The environment does not support scripting (it is unavailable
or disabled) so no script will execute.

That premise was true when NOSCRIPT was introduced because there was
only one script supporting browser environment so a script either would
be executed and work, or it would not (assuming that bugs/errors never
got past testing).

However, for some considerable time the problems of browser scripting
have arisen form the availability of diverse client-side environments
and that means that all internet browser scripts face three possible
outcomes: 1) The script will execute and be fully supported by the
browser environment in which it finds itself, 2) The script will execute
but find that it is not supported by the browser environment (so it will
fail to fully execute (degrade under its own control), or error-out if
poorly written), and 3) The environment does not support scripting (it
is unavailable or disabled).

The middle option, of a script that is executed but cannot do what it
intended in the environment in which it finds itself, is where the art
of browser script design expresses itself. The concepts of scripted
enhancement (that are not harmful/problematic when they cannot act) and
clean degradation to fully viable underlying HTML (and server-side
alternatives) are employed to make sense of this middle option. These
are script design considerations that will feature in any quality
Internet browser script.

Having covered that middle option with good script design (and suitably
cautious/defensive implementation) the NOSCRIPT element has become
redundant. Whatever made sense in the context of a script that found
that it could achieve nothing in a scriptable environment that did not
support the features/actions that it wanted to perform makes just as
much sense in an environment where scripting is disabled/unavailable (so
the script never could achieve anything). Thus a quality Internet
browser script needs no NOSCRIPT element by design.

And there is certainly no point having a NOSCIRPT element telling a user
that they need to enable javascript in order to view a site unless you
can guarantee that enabling javascript will facilitate their viewing of
that site, which is impossible.

Richard.

On Thu, 16 Jun 2005 12:51:06 +0100, in comp.lang.javascript "Richard
Cornford" <> wrote:

>| Jeff North wrote:
>| <snip>
>| > Simply use the noscript tag to inform user that they will
>| > not have full access to the site.
>| >
>| > <script type="text/javascript">
>| > ...
>| > your scripts
>| > ....
>| > </script>
>| > <noscript>
>| > ...
>| > message to user with javascript disabled
>| > ...
>| > </noscript>
>|
>| One thing that is apparent form searching the comp.lang.javascript
>| archives for NOSCRIPT is that its use is very rarely proposed (at least
>| in the current century), and almost never by the more experienced
>| contributors.

Really?
I'm sure the WAI consortium would be interested in why they are
wasting their time, and effort, in invalidating sites that do not have
the <noscript> tag defined where any scripting language appears on a
page.

>| The reason for this is simply that the NOSCRIPT element is not capable
>| of contributing to the problems of browser scripting for the internet,
>| and has not been for many years.
>|
>| The NOSCRIPT element is based on a premise that there are only two
>| outcomes in browser scripting: 1) The script will work (the environment
>| supports scripting and the script will fully achieve what is expected of
>| it, and 2) The environment does not support scripting (it is unavailable
>| or disabled) so no script will execute.
>|
>| That premise was true when NOSCRIPT was introduced because there was
>| only one script supporting browser environment so a script either would
>| be executed and work, or it would not (assuming that bugs/errors never
>| got past testing).
>|
>| However, for some considerable time the problems of browser scripting
>| have arisen form the availability of diverse client-side environments
>| and that means that all internet browser scripts face three possible
>| outcomes: 1) The script will execute and be fully supported by the
>| browser environment in which it finds itself, 2) The script will execute
>| but find that it is not supported by the browser environment (so it will
>| fail to fully execute (degrade under its own control), or error-out if
>| poorly written), and 3) The environment does not support scripting (it
>| is unavailable or disabled).

So far you have not invalidated the use of the <noscript> tag. In fact
you have shown why you should use it.

As you point out below, items 1 and 2 are where the script will be
executed. The handling of the scripts compatability etc should be
programmed by the programmer, within the executable script.

Item 3 is where the script will not execute.

So you still have the binary option of the script executing or not.

>| The middle option, of a script that is executed but cannot do what it
>| intended in the environment in which it finds itself, is where the art
>| of browser script design expresses itself. The concepts of scripted
>| enhancement (that are not harmful/problematic when they cannot act) and
>| clean degradation to fully viable underlying HTML (and server-side
>| alternatives) are employed to make sense of this middle option. These
>| are script design considerations that will feature in any quality
>| Internet browser script.
>|
>| Having covered that middle option with good script design (and suitably
>| cautious/defensive implementation) the NOSCRIPT element has become
>| redundant. Whatever made sense in the context of a script that found
>| that it could achieve nothing in a scriptable environment that did not
>| support the features/actions that it wanted to perform makes just as
>| much sense in an environment where scripting is disabled/unavailable (so
>| the script never could achieve anything). Thus a quality Internet
>| browser script needs no NOSCRIPT element by design.

Tell that to the W3C consortium.
http://www.w3.org/TR/html4/interact/....html#h-18.3.1

In the following example, a user agent that executes the SCRIPT will
include some dynamically created data in the document. If the user
agent doesn't support scripts, the user may still retrieve the data
through a link.

<SCRIPT type="text/tcl">
...some Tcl script to insert data...
</SCRIPT>
<NOSCRIPT>
<P>Access the <A href="http://someplace.com/data">data.</A>
</NOSCRIPT>
--------------
Can you give me an example of where the same thing can be achieved
without the need for the <noscript> tag.

>| And there is certainly no point having a NOSCIRPT element telling a user
>| that they need to enable javascript in order to view a site unless you
>| can guarantee that enabling javascript will facilitate their viewing of
>| that site, which is impossible.

Debatable.
---------------------------------------------------------------
: Remove your pants to reply
---------------------------------------------------------------

Jeff North wrote:
> In the following example, a user agent that executes the SCRIPT will
> include some dynamically created data in the document. If the user
> agent doesn't support scripts, the user may still retrieve the data
> through a link.
> <SCRIPT type="text/tcl">
> ...some Tcl script to insert data...
> </SCRIPT>
> <NOSCRIPT>
> <P>Access the <A href="http://someplace.com/data">data.</A>
> </NOSCRIPT>

This is a good illustration of the problem.
My browser shows nothing at all, because it doesn't understand text/tcl
script, yet it is script enabled so it doesn't show the <noscript> content
either.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com