Problems with JS turned off?

[drhowarddrfine]

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.

 

[Jc]

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.

 

[Lasse Reichstein Nielsen]

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'

 

[Robert Maas, see http://tinyurl.com/uh3t]

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

 

[drWot]

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.

 

[drhowarddrfine]

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.

 

[Jeff North]

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

 

[Richard Cornford]

Jeff North wrote:

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.

 

[Jeff North]

| 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 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/scripts.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

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

 

[Matt Kruse]

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.

 

[Richard Cornford]

Richard Cornford wrote:

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.

When did the WAI 'consortium' (working group?) start 'invalidating' web
sites?

But the WAI know that their current advice is (or may be superficially
interpreted as) bad, because Jim keeps telling them. My impression is
that they don't/won't change their advice because they don't understand
browser scripting well enough (as individuals) and would prefer to be
rid of it entirely.

However, the notion that for every SCRIPT there must be a NOSCRIPT is
not WIA advice, it is more the product of inadequate mechanical
accessibility testing. For many scripted actions there would be no
meaningful NOSCRIPT content to provide. Client-side pre-submit form
validation being one very common and obvious example.

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

How have I shown that 'you should use it'? Why would I promote a
situation where a proportion of users are denied access to content
because of the browser they choose to use in an Internet context?

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.

A script may execute but be unable to act, due to the environment not
providing the features that it need in order to act. Indeed there do not
appear to be many non-trivial actions that a script could attempt to
undertake that will not fail on at least one known browser (and there
are always many browsers that are unknown to each individual script
author).

So there are still 3 outcomes, with one outcome in a script supporting
browser being identical to the outcome in a script incapable/disabled
browser.

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

A description of the intended purpose of the NOSCRIPT element has no
baring on its inability to satisfy that purpose.

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>

<P id="scirptTarget">
Access the <A href="http://someplace.com/data">data.</A>
</P>
<scirpt type="text/javascirpt">
if(
// Test to see if this browser supports the dynamic features
// that would be required for the insertion of this 'data':
// the replacing of the contents of an IDed P element with
// alternative content
){
// Locate the IDed P element in the DOM and replace its
// contents with the 'data'. Or, possibly remove the P
// element from the DOM and inset the 'data' elsewhere,
// having tested for that facility instead.
}
</scirpt>

- No need for NOSCRIPT elements, and all script failure scenarios result
in the user having the options that your approach only provides when
scripting is completely unavailable on the client, leaving the user's of
less dynamic, but scriptable browsers, without any means of accessing
the 'data'.

Debatable.

Only by people who are happy to tell lies to their users. Or do you mean
that it is debatable whether it is impossible to write a non-trivial
script that will successfully execute in all browser environments?

In the latter case no debate is necessary as the question can be
empirically resolved through the creation of one example non-trivial
script that could not be shown to fail in at lest one environment. No
such script has yet been created, and as more browsers come into
existence the chances of it happening are diminishing.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Thu, 16
Jun 2005 12:51:06, seen in Richard Cornford

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.

Incorrect.

If a page is specifically designed to provide javascript executed at the
client, and to do nothing useful otherwise, then a NOSCRIPT can inform a
user whose browser is not executing script of the situation, without
bothering those whose browsers do execute script.

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.

That's just logically fallacious. It is only necessary that the
NOSCRIPT section states that proper viewing is impossible without
javascript, but may be possible with it.


FAQ section 5 should be corrected.

 

[Richard Cornford]

Incorrect.

If a page is specifically designed to provide javascript
executed at the client, and to do nothing useful otherwise,

A page cannot be designed to be dependent on javascript alone. It must
be dependent on scripting _and_ a certain group of host-provided
facilities and features. It must require _both_ before it can do
anything useful.

then a NOSCRIPT can inform a user whose browser is
not executing script of the situation, without
bothering those whose browsers do execute script.

Because NOSCRIPT can do nothing for the users of script enabled browsers
that do not provide the required features the SCRIPT/NOSCRIPT
combination fails to address all possibilities, while good script design
strives to achieve 100% coverage.

There are many better design strategies for achieving what NOSCRIPT
attempts, that will provide much more satisfactory results. For example,
a script the attempted to employ little more than - document.write -
might have the 'noscript' content contained in suitably CSS classed
elements within the HTML and write out a style element that assigned -
display:none; - to those elements (which would need to be suitably
worded to take account of browsers that support scripting but where CSS
was disabled/unavailable). And a script that depended upon - innerHTML -
could use that facility to remove such elements from a page. Thus the
availability of an announcement to the user would be more closely
related to the user's need for such an announcement and not just tied to
a subset of failure scenarios.

If it is important to explain/justify the failure it should be important
to justify all such failures.

That's just logically fallacious. It is only necessary
that the NOSCRIPT section states that proper viewing is
impossible without javascript, but may be possible with it.

If instead of using forms of words along the lines of "you need to
enable javascript in order to view this site", authors chose wording
that accurately summed up the real situation they would likely better
appreciate the folly in some of their design decisions. Something like:-

"In order to view this site you must be using a script enabled browser
from a limited list of known browsers/browser versions in their default
configurations (or near default configurations) and outside of the
possible influence of external software like firewalls, proxies and
advertising/pop-up blockers".

- would, in many cases, better reflect reality, and that might be
shortened to saying 'things _may_ be better with scripting
enabled/available'. If your announcement doesn't promise anything then
it cannot be a lie (as the advertising world knows only too well).

But the exact wording is very much a secondary issue to the relationship
between the showing of such messages and the absence of a reason for
showing messages (the fully successful execution of the corresponding
script). The NOSCRIPT element is not capable of providing a mutually
exclusive relationship, while other approaches either can, or come
significantly closer.

Richard.

 

[Matt Kruse]

a script the attempted to employ little more than -
document.write - might have the 'noscript' content contained in
suitably CSS classed elements within the HTML and write out a style
element that assigned - display:none; - to those elements (which
would need to be suitably worded to take account of browsers that
support scripting but where CSS was disabled/unavailable). And a
script that depended upon - innerHTML - could use that facility to
remove such elements from a page.

Sounds good in theory, but do you ever actually _use_ such an approach?

It often becomes impractical and ugly for all but the simplest of
applications.

 

[Jeff North]

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

.... and that is the way it should work.
You have scripting enabled therefore the script should be executed. It
is up to the programmer to handle such errors.

Now turn off scripting in your browser and see what happens.
The noscript section is activated.

(Please note the title of the thread).

 

[Richard Cornford]

Sounds good in theory, but do you ever actually _use_ such an
approach?

<snip>

In the sense that I start from a basis of viable HTML and use scripts to
manipulate that into the state in which I intend it to be scripted,
having verified that the script concerned can successfully act, then I
do use that type of strategy.

I do not use it for showing the user messages about the capabilities of
their browsers. Partly because I have provided them with viable HTML as
a minimum and so no longer need to care about whether their browser will
support its scripted enhancements, and partly because I don't think most
users know anything about Internet technologies, so there is no point in
bothering them with details most will likely not understand.

Richard.

 

[Jeff North]

| Jeff North wrote:
| > Richard Cornford wrote:
| <snip>
| >>| 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.
|
| When did the WAI 'consortium' (working group?) start 'invalidating' web
| sites?

Oh you know, Bobby, Tidy et al.

| But the WAI know that their current advice is (or may be superficially
| interpreted as) bad, because Jim keeps telling them. My impression is
| that they don't/won't change their advice because they don't understand
| browser scripting well enough (as individuals) and would prefer to be
| rid of it entirely.

Until they do 'get rid of it' the specification remains.
People like me, who do not have direct access to the people within the
consortium, must rely on what is published.

| However, the notion that for every SCRIPT there must be a NOSCRIPT is
| not WIA advice, it is more the product of inadequate mechanical
| accessibility testing. For many scripted actions there would be no
| meaningful NOSCRIPT content to provide. Client-side pre-submit form
| validation being one very common and obvious example.
|
| <snip>
| > So far you have not invalidated the use of the <noscript>
| > tag. In fact you have shown why you should use it.
|
| How have I shown that 'you should use it'? Why would I promote a
| situation where a proportion of users are denied access to content
| because of the browser they choose to use in an Internet context?
|
| > 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.
|
| A script may execute but be unable to act, due to the environment not
| providing the features that it need in order to act.

Please note the title of the thread.

If scripting is enabled then the browser will try to execute the
script - right. Whether or not it can is another story and it is up to
the programmer to catch this 'problem' - yes.

If scripting is disabled then the browser will ignore any script tags
and jump to the noscript tag, if one is included.

| Indeed there do not
| appear to be many non-trivial actions that a script could attempt to
| undertake that will not fail on at least one known browser (and there
| are always many browsers that are unknown to each individual script
| author).

But that is up to the programmer to ensure that the script will
execute, or degrade gracefully, IF SCRIPTING IS ENABLED.

If scripting is disabled then the code will not be executed no matter
how well crafted it is. By using the noscript tag you can inform the
user of loss of functionality on the page. Hey you can even use

| So there are still 3 outcomes, with one outcome in a script supporting
| browser being identical to the outcome in a script incapable/disabled
| browser.

incapable != 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.
| <snip>
|
| > Tell that to the W3C consortium.
| > http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.1
|
| A description of the intended purpose of the NOSCRIPT element has no
| baring on its inability to satisfy that purpose.
|
| > 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.
|
| <P id="scirptTarget">
| Access the <A href="http://someplace.com/data">data.</A>
| </P>
| <scirpt type="text/javascirpt">
| if(
| // Test to see if this browser supports the dynamic features
| // that would be required for the insertion of this 'data':
| // the replacing of the contents of an IDed P element with
| // alternative content
| ){
| // Locate the IDed P element in the DOM and replace its
| // contents with the 'data'. Or, possibly remove the P
| // element from the DOM and inset the 'data' elsewhere,
| // having tested for that facility instead.
| }
| </scirpt>

Oh I see, 20+ lines of cross browser compatible code to do what a
<noscript><a href...</noscript> section can do - right.

BTW it is script not scirpt. The fact that this appears multiple times
shows that it is not a typo (which I normally do not comment on).

| - No need for NOSCRIPT elements, and all script failure scenarios result
| in the user having the options that your approach only provides when
| scripting is completely unavailable on the client, leaving the user's of
| less dynamic, but scriptable browsers, without any means of accessing
| the 'data'.
|
| >>| 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.
|
| Only by people who are happy to tell lies to their users. Or do you mean
| that it is debatable whether it is impossible to write a non-trivial
| script that will successfully execute in all browser environments?

Obviously you have not heard of, or used, DHTML.

 

[Richard Cornford]

Richard Cornford wrote:

Oh you know, Bobby, Tidy et al.

I am familiar with mechanical accessibility testing, and its
limitations. But the existence of such software doesn't mean that the
WAI is 'invalidating' web sites.

Until they do 'get rid of it' the specification remains.

The WAI has produced no specifications. They produce guidelines, that
require intelligent interpretation, which is why automated accessibility
testing is as likely to do more harm than good if used as the only
criteria for accessibility.

People like me, who do not have direct access to the
people within the consortium,

It is still a working group, and you can offer them your opinions if you
feel like it.

must rely on what is published.

You might then try actually reading what they publish. WCAG 1.0 only
features one occurrence of the string 'NOSCIRPT' and it appears in an
example not in one of the actual checkpoints. It is an example for
checkpoint 6.3, which reads:-

| 6.3 Ensure that pages are usable when scripts, applets, or other
| programmatic objects are turned off or not supported. If this is
| not possible, provide equivalent information on an alternative
| accessible page. [Priority 1]

And the propose use of NOSCRIPT elements in the example is not only a
manifestation of a limited grasp of scripting on the part of the author
of the example, it also fails to satisfy the guideline as, as I have
repeatedly explained, it does not account for the condition where
scripting is available but the script itself is "not supported" by the
browser's environment.

A poor example, that fails to satisfy its associated checkpoint, is not
a justification for any particular action, regardless of how many
examples of automated accessibility software are authored by individuals
who also don't understand scripting well enough to see how it should be
written to satisfy the guidelines.

Please note the title of the thread.

It is a subject not a title.

If scripting is enabled then the browser will try to
execute the script - right.

If it has an interpreter for the specified script type, otherwise, as
Matt Kruse pointed out, it won't be able to comprehend the source code.

Whether or not it can is another story and it is up to
the programmer to catch this 'problem' - yes.

Yes it is up to the programmer (or, more reasonably, the script designer
as it is a design issue not an implementation issue) to take account of
the possibility that a browser may support scripting but not provide the
environment that the script needs. The point of my comments is that once
the programmes has designed for that possibility (the possibility that
the script will not be able to act at all) they have already done
everything that they need to do in order to accommodate browsers where
scripting is unavailable.

If scripting is disabled then the browser will ignore any script
tags and jump to the noscript tag, if one is included.

Explain "jump to", that doesn't sound like an HTML thing at all.

But that is up to the programmer to ensure that the script will
execute, or degrade gracefully, IF SCRIPTING IS ENABLED.

When a script degrades gracefully in the face of its inability to act it
will have done everything that would need to be done when scripting is
unavailable. That is what clean degradation is.

If scripting is disabled then the code will not be executed
no matter how well crafted it is.

But it won't be any more 'not executed' when scripting is unavailable as
it would be 'not executed' in an environment that does not facilitate
its execution.

By using the noscript tag you can inform the
user of loss of functionality on the page.

And by not using the NOSCRIPT _element_ you can inform the user of the
loss of functionality, except that without the NOSCRIPT element you can
inform them of the loss of functionality whenever they don't have that
functionality, instead of just when they don't have client-side
scripting available.

Not that there is much to be gained by bothering the user with that type
of technical detail.

Hey you can even use
<noscript></noscript>.

What possible good does that do anyone?

incapable != disabled.

Hence the use of both. Scripts still fail to execute on a script
incapable browser in exactly the same way as they fail to execute on a
script disabled browser.

Oh I see, 20+ lines of cross browser compatible code to do what a
<noscript><a href...</noscript> section can do - right.

The original example included most of that code in order to include the
'data' in the first place, the only difference would be the code that
removed the original content, which would not necessarily be more than a
couple of lines.

And no it doesn't do what NOSCRIPT elements would do, it does more. it
covers both the possibility that scripting is unavailable and the
possibility that the browser environment does not support the features
required by the script. It reduces the possible outcomes form three back
down to two, mutually exclusive, possibilities. Thus it completely
addresses the reality of browser scripting and does not leave users
falling through the cracks in the way that NOSCRIPT elements do.

BTW it is script not scirpt. The fact that this appears
multiple times shows that it is not a typo (which I
normally do not comment on).

Obviously you don't touch-type, else you would recognise that
transposing characters typed with alternate hands is probably the most
common typo.

Obviously you have not heard of, or used, DHTML.

<snip>

I beg your pardon?

But what is this comment supposed to be about? Are you suggesting that
it is possible to write DHTML that will successfully execute on all
(script capable) browsers? If so feel free to demonstrate.

Richard.

 

[Jeff North]

| Jeff North wrote:
| > Richard Cornford wrote:

| > Oh you know, Bobby, Tidy et al.
|
| I am familiar with mechanical accessibility testing, and its
| limitations. But the existence of such software doesn't mean that the
| WAI is 'invalidating' web sites.

When the software uses the W3C/WAI 'guidelines' to rate a site ......

| > Until they do 'get rid of it' the specification remains.
|
| The WAI has produced no specifications. They produce guidelines, that
| require intelligent interpretation, which is why automated accessibility
| testing is as likely to do more harm than good if used as the only
| criteria for accessibility.

What other criteria is available for accessiblity testing?

| > People like me, who do not have direct access to the
| > people within the consortium,
|
| It is still a working group, and you can offer them your opinions if you
| feel like it.
|
| > must rely on what is published.
|
| You might then try actually reading what they publish. WCAG 1.0 only
| features one occurrence of the string 'NOSCIRPT' and it appears in an
| example not in one of the actual checkpoints. It is an example for
| checkpoint 6.3, which reads:-

You might want to look at 'guideline 1.1' before making any further
comments.

1.1 Provide a text equivalent for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: images,
graphical representations of text (including symbols), image map
regions, animations (e.g., animated GIFs), applets and programmatic
objects, ascii art, frames, ****** scripts *******, images used as
list bullets, spacers, graphical buttons, sounds (played with or
without user interaction), stand-alone audio files, audio tracks of
video, and video.

| >>| > So you still have the binary option of the script
| >>| > executing or not.
| >>|
| >>| A script may execute but be unable to act, due to the environment
| >>| not providing the features that it need in order to act.
| >
| > Please note the title of the thread.
|
| It is a subject not a title.

Picky, pick, picky.

| > If scripting is enabled then the browser will try to
| > execute the script - right.
|
| If it has an interpreter for the specified script type, otherwise, as
| Matt Kruse pointed out, it won't be able to comprehend the source code.

You missed a few words from what I posted:
http://www.w3.org/TR/html401/interact/scripts.html#idx-script-6
If the user agent doesn't support scripts, .....

I take that to mean: if the browser doesn't have a scripting engine or
scripting is disabled.

The browser DID support scripts (scripting enabled), it just didn't
support the TCL script. Therefore it is up to the programmer to ensure
that the browser supported such scripts. It is not the browsers
responsibility.

| > If scripting is disabled then the browser will ignore any script
| > tags and jump to the noscript tag, if one is included.
|
| Explain "jump to", that doesn't sound like an HTML thing at all.

No its a html rendering process term

| > Hey you can even use
| > <noscript></noscript>.
|
| What possible good does that do anyone?

It will allow you to have your page pass the W3C/WAI guidelines

| > incapable != disabled.
|
| Hence the use of both. Scripts still fail to execute on a script
| incapable browser in exactly the same way as they fail to execute on a
| script disabled browser.

Yes they 'fail to execute' but the handling of this failure is
completely different.

| >>| Only by people who are happy to tell lies to their users.
| >>| Or do you mean that it is debatable whether it is impossible
| >>| to write a non-trivial script that will successfully execute
| >>| in all browser environments?
| >
| > Obviously you have not heard of, or used, DHTML.
| <snip>
|
| I beg your pardon?

Right comment, wrong area. So bite me.

| But what is this comment supposed to be about? Are you suggesting that
| it is possible to write DHTML that will successfully execute on all
| (script capable) browsers? If so feel free to demonstrate.

http://www.htmlguru.com/
Caveat: I haven't checked out every single page on every available
browser but the home page is ample demonstration.

 

[Matt Kruse]

The browser DID support scripts (scripting enabled), it just didn't
support the TCL script. Therefore it is up to the programmer to ensure
that the browser supported such scripts. It is not the browsers
responsibility.

How, as a programmer, could you ever be expected to ensure that the browser
supported such scripts?

If any scripting is available, the noscript content will be hidden.
However, unless you have the scripting capability used in the code itself,
there is no way to provide an alternate route for browsers that don't
understand the code you've supplied.