Problems with JS turned off?

[Michael Winter]

On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
[snip]

The WAI [...] 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?

If you read that paragraph properly, the answer is readily apparent.

I get the impression from reading all of your comments so far that you
haven't actually been reading the points put before you. Or, perhaps you
did read them, but you didn't comprehend them.

[snip]

WCAG 1.0 only features one occurrence of the string 'NOSCIRPT' [...]

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

That guideline doesn't contain a reference to the NOSCRIPT element, so
Richard's observation may well be correct (I haven't checked).

In case you didn't realise this, providing a text equivalent of a script
is simply not appropriate in all cases. The obvious example, which has
already been presented, is form validation.

Client-side validation is merely a convenience so that a visitor doesn't
need to make a round-trip to establish the fact that they made a
mistake: it can occur near instantaneously on their own machine. Saying
that this feature is unavailable via a NOSCRIPT element is pointless as
no-one should really care: validation will still occur on the server.

This particular example is also a very simple demonstration of graceful
degradation - the phrase invoked several times so far. If the script
doesn't execute (scripting incapable/disabled), or cannot function
(inadequate host) then the server will still provide the desired
behaviour. In similar situations, where a scripted system falls back to
something still usable, or even those where a script is purely
decorative and has no content that is worthy of mention, then I find
little reason to include a NOSCRIPT element. As these two situations
should always occur with a well-designed system, we have the event where
there should never really be a reason to use the aforementioned element.

[snip]

The browser [...] 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.

Invariably through graceful degradation: either make sure that no-one
cares if a script fails (for whatever reason), or provide some other
means (usually server-side, or with plain markup) to guarantee a useful
alternative. Now, incorporate the above discussion and this debate
should be over (we should be so lucky...).

[snip]

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

I think the question still stands. Achieving the intentions of the
guidelines (accessible sites), rather than following them unwaveringly,
would seem a far more productive and helpful use of time.

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

Both should end up using the same fallback, which is why NOSCRIPT is
inappropriate: it cannot provide the necessary functionality.

[snip]

So bite me.

I don't know if Richard would appreciate third-party commentary, so I'll
leave that remark to him.

[snip]

http://www.htmlguru.com/

Is that supposed to be an indication of good design? Good grief, no!

- The markup is a lovely combination of DIV soup, with a portion of
XHTML syntax thrown in for good measure.
- Navigation requires a plug-in (no alternative content), and some
of the links require script support, too.
- With scripting disabled, I get a lovely, clear white viewport.
- It rejects Opera because apparently it doesn't provide a good
enough host environment. From a very brief look at the source,
there's nothing whatsoever to justify that. Seems like incompetence
to me.

I didn't bother going further than the initial page - I saw enough.

Mike

 

[Richard Cornford]

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

When the software authors impose a bogus interpretation of the WAI
guidelines there is no reflection in the WAI or its guidelines.

What other criteria is available for accessiblity testing?

Human judgement of course; preferably informed and intelligent. The
criteria being; Is the result an accessible web site or not.

I have personally experience an instance where an action taken to
satisfy Bobby's automated testing directly resulted in an otherwise
broadly accessible web site being rendered unusable by anyone who could
not operate a mouse (or similar pointing device). If the site's authors
had had the goal of creating an accessible site that would have been an
obvious failure, their actual goal was just to satisfy Bobby so they
succeeded. But it is not difficult to see that an exclusive dependence
on mechanical accessibility checking makes little contribution to the
accessibility of web sites, and is even directly harmful to that cause.

Human judgement: Is the result an accessible web site or not. The WAI
provide no more than guidance in making that judgement.

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.

I have read it, and I have thought about it. And I have concluded that
the "text equivalent" of many things is no text at all. An image acting
as a spacer, sounds played in the background for atmosphere, and almost
anything scripted.

Where scripts stand out is that they may act in a way that could have a
text equivalent. For example, a "tool tip" script may be presenting
supplementary information that should still be included when scripting
it as a tool tip was not viable or meaningful. Or a drop-down navigation
menu, where the absence of dynamic and interactive script support should
leave some means of navigation that will inevitable have a significant
text content.

What we are disputing here is not that there should be viable
alternatives for when scripted actions are impossible or do not make
sense, but how that is to be achieved.

When providing a 'text equivalent' makes sense it makes sense in all
circumstances where the scripted action that it is an alternative to
does not make sense or is impossible. Thus you need a mechanism for
providing those 'text equivalents' that is _mutually_exclusive_ to the
scripted action for which they are an equivalent.

NOSCRIPT elements do not provide that mechanism because they are
mutually exclusive to the wrong condition. They are only used when
script interpretation in unsupported or disabled.

While scripts designed for clean degradation to viable underlying HTML
(and/or server-side fall back) will be in a position to provide those
text equivalents both when scripting is unavailable or disabled and
whenever the environment does not support the facilities needed by
script in order to act. They even facilitate the selective disabling
scripted actions by the users, such as the user of a screen reader maybe
preferring not to have an animated drop-down menu (because chunks of a
page appearing and disappearing doesn't read that well) but still
preferring client-side form validation.

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.

There is no dispute about the mechanism of NOSCIRPT elements.

The browser DID support scripts (scripting enabled),
it just didn't support the TCL script.

Which was Matt's (much as I am loathed to admit it (and wish I had
spotted it myself) ;-), very good) point. The NOSCRIPT element did
exactly what it was specified to do, and completely failed to contribute
anything to the outcome. No text equivalent was provided, and Bobby went
away happy that another inaccessible web site had met its dubious
criteria.

Therefore it is up to the programmer to ensure
that the browser supported such scripts.

Would you also ask the programmer to ensure that there were no
interruptions to the network while their script was running, no power
failures, that nobody unplugged any of the computers involved, etc, etc?
There are conditions that are outside of the control of programmers, and
the execution environment of an Internet browser script is a condition
outside of the control of the author of that script.

A browser script cannot know anything about its execution environment
until it starts executing in that environment. And if it never starts
executing it never will know anything about that environment. A
programme, no matter how it is coded, cannot ensure that it will be
executed, only how it will execute if and when it is executed.

What the script author can do is design their script for clean
degradation to underlying viable HTML (and/or server side fall-back) so
that its failure to execute (or its inability to act, or its choice not
to act) leaves that underlying HTML providing the alternative to its
action. And having done that the NOSCRIPT element has become redundant
because not acting through lack of support or choice would have the same
satisfactory outcome as being unable to act.

It is not the browsers responsibility.

Who was ever going to blame the browser? The responsibility lies with
the author. It is a responsibility to achieve a meaningful mutually
exclusive relationship between the successful execution of scripts in an
unknown browser environment and their failure to execute, for whatever
reason.

NOSCRIPT elements do not provide that relationship so it is the
responsibility of the author to employ an alternative mechanism that
does. And once they have don that there is no longer any need for
NOSCRIPT elements.

No its a html rendering process term

My question what not in what context is the term used. I wanted an
explanation or the sequence of actions and/or event that explain the use
of the words "jump to" in "browser will ignore any script tags and jump
to the noscript tag", because in most context where the words "jump to"
are use the accompanying concept would have no relationship to the
actual actions of an HTML parser or rendered with scripting
disabled/unsupported.

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

No it won't. It might get you passed automated accessibility testing
software like Bobby but the WAI's primary guideline is to create an
accessible web site and NOSCIRPT elements are redundant in achieving
that. And empty NOSCRIPT elements are doubly (and self evidently)
redundant.

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

In what way are those two conditions handled differently? In both cases
the content of SCRIPT elements will not be executed and in both cases
the content of NOSCRIPT elements will be displayed/presented.

Right comment, wrong area. So bite me.

In what sense "right comment"?

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

An error dialog and a blank screen on script enabled IE 6; that is about
as far from "successfully execute on all (script capable) browsers" as
you can get. But an examination of the fist couple of function bodies
suggests at least another couple of browsers where the script will
error-out, and that is without even trying.

There are infinitely better candidates posted to this group on a weekly
basis. But still none are clamed to "successfully execute on all (script
capable) browsers".

Richard.

 

[Richard Cornford]

Richard Cornford wrote:

WCAG 1.0 only features one occurrence of the string
'NOSCIRPT' [...]

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

That guideline doesn't contain a reference to the NOSCRIPT
element, so Richard's observation may well be correct
(I haven't checked).

I did a text search so I am confident that I am correct.

I think the question still stands. Achieving the intentions
of the guidelines (accessible sites), rather than following
them unwaveringly, would seem a far more productive and
helpful use of time.

But it isn't even following the guidelines unwaveringly. It is taking
one (poor) example and applying it to all situations regardless of its
appropriateness. Even a machine would be wrong to do that.

I don't know if Richard would appreciate third-party
commentary, so I'll leave that remark to him.

And I won't comment, as I would not expect anyone to respect
self-proclaimed claims of ability (I certainly never do).

[snip]

http://www.htmlguru.com/

Is that supposed to be an indication of good design? Good
grief, no!

- The markup is a lovely combination of DIV soup, with a
portion of XHTML syntax thrown in for good measure.
- Navigation requires a plug-in (no alternative content), and
some of the links require script support, too.
- With scripting disabled, I get a lovely, clear white viewport.
- It rejects Opera because apparently it doesn't provide a good
enough host environment. From a very brief look at the source,
there's nothing whatsoever to justify that. Seems like
incompetence to me.

I didn't bother going further than the initial page - I saw enough.

So you didn't get as far as the browser detection by UA string and eval
abuses then? It is an utterly fragile script, not even in the right
ballpark.

Richard.

 

[Jeff North]

| On 18/06/2005 02:31, Jeff North wrote:
|
| > On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
|
| [snip]
|
| >> The WAI [...] 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?
|
| If you read that paragraph properly, the answer is readily apparent.

If it was apparent then I wouldn't have asked the question.

Could *you* explain to me what "likely to do more harm than good"
means. What harm? Will the web page fry my cpu? Will it erase my hard
drive? Will following the automated WAI guidelines install virii or
trojans on my system?

It is an empty statement.

| I get the impression from reading all of your comments so far that you
| haven't actually been reading the points put before you. Or, perhaps you
| did read them, but you didn't comprehend them.

I did read them. I did comprehend them. I just have a different POV.
Maybe I should use smaller words in future.

| [snip]
|
| >> WCAG 1.0 only features one occurrence of the string 'NOSCIRPT' [...]
| >
| > You might want to look at 'guideline 1.1' before making any further
| > comments.
|
| That guideline doesn't contain a reference to the NOSCRIPT element, so
| Richard's observation may well be correct (I haven't checked).

Well here you go:
http://www.w3.org/TR/WCAG10/
Guideline 1. Provide equivalent alternatives to auditory and visual
content.
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.

http://www.w3.org/TR/WCAG10/#gl-new-technologies
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]
For example, ensure that links that trigger scripts work when
scripts are turned off or not supported (e.g., do not use
"javascript:" as the link target). If it is not possible to make the
page usable without scripts, provide a text equivalent with the
NOSCRIPT element, or use a server-side script instead of a client-side
script, or provide an alternative accessible page as per checkpoint
11.4. Refer also to guideline 1.
---------------------------------

Please note the last sentence "Refer also to guideline 1." !!!!!!!
Maybe Richard didn't read the last sentence.

Please read the 2nd last sentence. Before you get on your high horse,
all I'm trying to do is show that there is an alternative when js is
turned off and server-side functionality is not available i.e. html
page not asp, php etc

| In case you didn't realise this, providing a text equivalent of a script
| is simply not appropriate in all cases.

I have never said it was. That is why I wrote "Hey you can even use

| The obvious example, which has
| already been presented, is form validation.
|
| Client-side validation is merely a convenience so that a visitor doesn't
| need to make a round-trip to establish the fact that they made a
| mistake: it can occur near instantaneously on their own machine. Saying
| that this feature is unavailable via a NOSCRIPT element is pointless as
| no-one should really care: validation will still occur on the server.

Only if the programmer has done their job properly (didn't rely solely
on client-side validation).

| This particular example is also a very simple demonstration of graceful
| degradation - the phrase invoked several times so far. If the script
| doesn't execute (scripting incapable/disabled), or cannot function
| (inadequate host) then the server will still provide the desired
| behaviour. In similar situations, where a scripted system falls back to
| something still usable, or even those where a script is purely
| decorative and has no content that is worthy of mention, then I find
| little reason to include a NOSCRIPT element. As these two situations
| should always occur with a well-designed system, we have the event where
| there should never really be a reason to use the aforementioned element.

The above contains some useful information for novice programmers.

[snip]

| >>> 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
|
| I think the question still stands. Achieving the intentions of the
| guidelines (accessible sites), rather than following them unwaveringly,
| would seem a far more productive and helpful use of time.

Sometimes you just have to waste some of your time to appease
committees that will approve your site/web pages.

[snip]

| > http://www.htmlguru.com/
|
| Is that supposed to be an indication of good design? Good grief, no!
|
| - The markup is a lovely combination of DIV soup, with a portion of
| XHTML syntax thrown in for good measure.
| - Navigation requires a plug-in (no alternative content), and some
| of the links require script support, too.
| - With scripting disabled, I get a lovely, clear white viewport.
| - It rejects Opera because apparently it doesn't provide a good
| enough host environment. From a very brief look at the source,
| there's nothing whatsoever to justify that. Seems like incompetence
| to me.
|
| I didn't bother going further than the initial page - I saw enough.

Well you might want to forward those comments onto the author of the
page. You might also post the exchange to the newsgroup.

Email
I can be reached via email at (e-mail address removed)

Post
Jeff Rouyer
RouyerDesign.com
4501 SE Mason Hill Drive
Milwaukie, Oregon 97222

 

[Jeff North]

| Jeff North wrote:
| > Richard Cornford wrote:
| >>| Jeff North wrote:
| >>|> Richard Cornford wrote:
| <snip>
| >>|> 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 ......
|
| When the software authors impose a bogus interpretation of the WAI
| guidelines there is no reflection in the WAI or its guidelines.

Oh you mean like HTML Tidy (which was written by W3C/WAI) can't be
trusted. Thanks for the heads up on that one.

| >>| > 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?
|
| Human judgement of course; preferably informed and intelligent. The
| criteria being; Is the result an accessible web site or not.
|
| I have personally experience an instance where an action taken to
| satisfy Bobby's automated testing directly resulted in an otherwise
| broadly accessible web site being rendered unusable by anyone who could
| not operate a mouse (or similar pointing device).

I think you have that back-to-front.
http://www.w3.org/TR/WCAG10/
2.1 Ensuring Graceful Transformation
Create documents that do not rely on one type of hardware. Pages
should be usable by people without mice, with small screens, low
resolution screens, black and white screens, no screens, with only
voice or text output, etc.

| If the site's authors
| had had the goal of creating an accessible site that would have been an
| obvious failure, their actual goal was just to satisfy Bobby so they
| succeeded. But it is not difficult to see that an exclusive dependence
| on mechanical accessibility checking makes little contribution to the
| accessibility of web sites, and is even directly harmful to that cause.
|
| Human judgement: Is the result an accessible web site or not. The WAI
| provide no more than guidance in making that judgement.

Me thinks it was human judgement that misunderstood the "mechanical
accessibility checking".

| <snip>
| > 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.
|
| I have read it, and I have thought about it. And I have concluded that
| the "text equivalent" of many things is no text at all. An image acting
| as a spacer, sounds played in the background for atmosphere, and almost
| anything scripted.

Even with "no text at all" you still are required to provide
(non)information to the browser of that object.

| Where scripts stand out is that they may act in a way that could have a
| text equivalent. For example, a "tool tip" script may be presenting
| supplementary information that should still be included when scripting
| it as a tool tip was not viable or meaningful. Or a drop-down navigation
| menu, where the absence of dynamic and interactive script support should
| leave some means of navigation that will inevitable have a significant
| text content.

I understand the point that you are making but....
JS controlled tool tips are a nicety. There are other standard, and
easier methods, for displaying tooltips.

Menus in general should degrade (CSS driven) or offer an alternative
menu where accessibility issues may be of concern (droplist, js, java
etc driven).

Standard practice.

| What we are disputing here is not that there should be viable
| alternatives for when scripted actions are impossible or do not make
| sense, but how that is to be achieved.
|
| When providing a 'text equivalent' makes sense it makes sense in all
| circumstances where the scripted action that it is an alternative to
| does not make sense or is impossible. Thus you need a mechanism for
| providing those 'text equivalents' that is _mutually_exclusive_ to the
| scripted action for which they are an equivalent.
|
| NOSCRIPT elements do not provide that mechanism because they are
| mutually exclusive to the wrong condition. They are only used when
| script interpretation in unsupported or disabled.

No quite right. As seen with the example that I posted from the W3C
site. It used TCL. If browser scripting was enabled then the browser
would attempt to execute the code, whether it supported the code or
not.

[snip]

| > 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.
|
| There is no dispute about the mechanism of NOSCIRPT elements. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

| > The browser DID support scripts (scripting enabled),
| > it just didn't support the TCL script.
|
| Which was Matt's (much as I am loathed to admit it (and wish I had
| spotted it myself) ;-), very good) point. The NOSCRIPT element did
| exactly what it was specified to do, and completely failed to contribute
| anything to the outcome. No text equivalent was provided, and Bobby went
| away happy that another inaccessible web site had met its dubious
| criteria.
|
| > Therefore it is up to the programmer to ensure
| > that the browser supported such scripts.
|
| Would you also ask the programmer to ensure that there were no
| interruptions to the network while their script was running, no power
| failures, that nobody unplugged any of the computers involved, etc, etc?
| There are conditions that are outside of the control of programmers, and
| the execution environment of an Internet browser script is a condition
| outside of the control of the author of that script.

No it is not!!!
Would you expect you pages to appear on the web without a web server.
Would you expect your php pages to run if the web server didn't
support php?

Certain mechanical things, as you have pointed out, are beyond the
programmers control.

The environment that you expect your scripts to run *is* within the
programmers control. This can be achieved by placing a notice on the
front page that a certain plugin is required or any other 'special'
software that maybe needed to access the site.

Simple, easy, doable and within the programmers control.

[snip]

| >>| Explain "jump to", that doesn't sound like an HTML thing at all.
| >
| > No its a html rendering process term
|
| My question what not in what context is the term used. I wanted an
| explanation or the sequence of actions and/or event that explain the use
| of the words "jump to" in "browser will ignore any script tags and jump
| to the noscript tag", because in most context where the words "jump to"
| are use the accompanying concept would have no relationship to the
| actual actions of an HTML parser or rendered with scripting
| disabled/unsupported.

Well why don't you try it yourself.
<html>
<head>
<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>
<P>This is the body of the document</P>
</body>
</html>

Run the page with scripting enabled - you should see the alert msg box
then the page render (as expected).

No turn off scripting - what happens? Is this the result of the html
parser or the scripting engine?

Basically I don't know nor do I care.

Just for fun, you might want to change the location of the

| > <snip>
| >
| >>| > 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
|
| No it won't. It might get you passed automated accessibility testing
| software like Bobby but the WAI's primary guideline is to create an
| accessible web site and NOSCIRPT elements are redundant in achieving
| that. And empty NOSCRIPT elements are doubly (and self evidently)
| redundant.

You mean much like alt="" on spacer images?

[snip]

| > http://www.htmlguru.com/
| > Caveat: I haven't checked out every single page on every
| > available browser but the home page is ample demonstration.
|
| An error dialog and a blank screen on script enabled IE 6; that is about
| as far from "successfully execute on all (script capable) browsers" as
| you can get.

Hey, I'm not your helpdesk person. If you can't get your browser to
operate correctly then contact the relevant company. LOL

I had no trouble displaying the site with NS7.2 or
IE6.0.2900.2180.xpsp_sp2_gdr.050301-1519 or FireFox 1.0.4.

Opera 8.0 did degrade nicely to an information screen.

| But an examination of the fist couple of function bodies
| suggests at least another couple of browsers where the script will
| error-out, and that is without even trying.
|
| There are infinitely better candidates posted to this group on a weekly
| basis. But still none are clamed to "successfully execute on all (script
| capable) browsers".

One can only aspire to such heights that one's scripts will work in
all browsers. That's why you post here, isn't it?

 

[Matt Kruse]

<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
Run the page with scripting enabled - you should see the alert msg box
then the page render (as expected).

The point is, this isn't a binary condition. There are at _least_ three
possibilities:

1) My browser supports text/javascript: I see the alert

2) My browser doesn't support any script: I see the disabled message

But you're not considering:

3) My browser supports text/vbscript but not text/javascript: I see nothing
at all

Since <noscript> cannot properly handle case #3, it should be discarded in
favor of solutions which correctly support all three (and more) cases.

 

[Michael Winter]

On 18/06/2005 18:09, Jeff North wrote:

[R. Cornford:]

The WAI [...] 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.

[snip]

Could *you* explain to me what "likely to do more harm than good"
means.

From what I've read, tools like Bobby have a very narrow definition of
guideline conformance. When this definition is used to evaluate a
document, it can result in changes that adversely affect the
accessibility of that document, rather than enhance it.

Notice, "From what I've read". I've never used Bobby and the like, and
never will. From the numerous times I've seen them lambasted in Usenet,
I fail to see their value.

The sensible alternative is to use common sense. The WAI guidelines
provide areas for consideration. An individual should be capable of
evaluating these potential trouble spots and determining if an issue
exists that needs to be addressed. If the individual isn't qualified to
make these judgements, then a tool won't help - there's no substitute
for knowledge.

[snip]

[In general,] I just have a different POV.

If this is what it boils down to, then I don't see the sense in
discussing this any more. This just seems to be a waste of time for all
concerned.

[RC:]

WCAG 1.0 only features one occurrence of the string 'NOSCIRPT' [...]

[snip]

I can't be bothered to continue with this particular issue. Richard made
a very simple point of fact: NOSCRIPT is only mentioned once. End of
story. One guideline referring to another doesn't invalidate that statement.

[snip]

[snipped criticism]

Well you might want to forward those comments onto the author of the
page.

I can't say I'm particularly inclined to do so. If I contacted the
author of every site I saw that exhibited dubious design decisions, I'd
have very little free time.

Mike

 

[Randy Webb]

On Sat, 18 Jun 2005 15:30:38 +0100, in comp.lang.javascript "Richard



Well why don't you try it yourself.
<html>
<head>
<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>
<P>This is the body of the document</P>
</body>
</html>

Now, try this one:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<script type="text/vbscript">
Dim MyVar
MyVar = MsgBox ("Hello World!", 65, "MsgBox Example")
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>
<P>This is the body of the document</P>
</body>
</html>

Try it in your Opera or Mozilla browsers and report back what happens.
Then, test it in IE. All with scripting enabled.

 

[Richard Cornford]

Oh you mean like HTML Tidy (which was written by W3C/WAI)

Written by the W3C and WAI was it?

can't be trusted.

Does Tidy claim to be an automated total arbiter of web page
accessibility? If it did then it shouldn't be trusted, but it doesn't
claim any such thing.

I think you have that back-to-front.

<snip>

No, I am describing what happened and why it happened. That it was
Bobby's intention to give advice that would promote input device
independence in web pages is undeniable. That the action taken satisfied
Bobby's criteria for device independence is also undeniable. And that
the outcome was to render the page unusable with any non-pointing input
device was also self evidently true.

Me thinks it was human judgement that misunderstood the "mechanical
accessibility checking".

Yes, the misunderstanding was taking its suggestions at face value and
not trying to understand why it was making suggests. Combined with the
misperception that if a web site passed the tests the web site must then
be accessible.

Even with "no text at all" you still are required to provide
(non)information to the browser of that object.

I beg your pardon?

No quite right. As seen with the example that I posted from
the W3C site. It used TCL. If browser scripting was enabled
then the browser would attempt to execute the code, whether
it supported the code or not.

Here you are saying that a browser encountering a script element with a
TYPE attribute of "text/tcl" that that browser will attempt to execute
that script regardless of whether it has a TCL interpreter or not. If
you believe that then you really don't have a clue.

No it is not!!!
Would you expect you pages to appear on the web without a web server.
Would you expect your php pages to run if the web server didn't
support php?

The server is under control. It can be guaranteed to have the required
software installed and operating, and be configured as is required for
the site to operate.

Certain mechanical things, as you have pointed out, are
beyond the programmers control.

The environment that you expect your scripts to run *is*
within the programmers control.

No it isn't

This can be achieved by placing a notice on the front
page that a certain plugin is required or any other 'special'
software that maybe needed to access the site.

How does a notice giving advice represent controlling the script's
execution environment? What is going to force the user to follow that
advice? But declarations of that type have no place in a discussion into
which you introduced the WAI, and little place in the world of Internet
browser scripting, where such an action is the last resort of the
utterly incompetent and widely regarded with the contempt that the
suggestion deserves.

Simple, easy, doable and within the programmers control.

But in no way a guarantee of the execution environment of a client-side
script.

[snip]

| >>| Explain "jump to", that doesn't sound like an HTML
| >>| thing at all.
| >
| > No its a html rendering process term
|
| My question what not in what context is the term used. I
| wanted an explanation or the sequence of actions and/or
| event that explain the use of the words "jump to" in "browser
| will ignore any script tags and jump to the noscript tag",
| because in most context where the words "jump to" are use
| the accompanying concept would have no relationship to the
| actual actions of an HTML parser or rendered with scripting
| disabled/unsupported.

Well why don't you try it yourself.

Because trying it won't tell me what you were talking about when you
wrote "browser will ignore any script tags and jump to the noscript
tag", and specifically the role of the words "jump to" in that
statement.

The best it will do is tell me what the browsers actually do, but I am
already familiar with that so repetition would be pointless.

<html>
<head>
<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>

As a block level element the NOSCIRPT element may not be a child or
descendant of the HEAD element in valid HTML. So this example is going
to be subject to browser error-correction when it is tag-souped into an
HTML DOM.

<P>This is the body of the document</P>
</body>
</html>

Run the page with scripting enabled - you should see
the alert msg box then the page render (as expected).

No turn off scripting - what happens? Is this the
result of the html parser or the scripting engine?

With scripting disabled nothing is ever the result of the script engine.

Basically I don't know nor do I care.

I can believe that. Now where is this "jump to" that you spoke of?

Just for fun, you might want to change the location of the
<noscript></noscript> just to see what happens.

This is the circumstance were the absence of any apparent "jump to" is
most evident. The script element's contents are ignored and the HTML
parser trundles on with the first element following the unused SCRIPT
element. It doesn't do anything with the NOSCRIPT element until the
parser encounters its opening tag in the input stream. Nothing that
could be caricaturised as "jump to" appears to happen at all. Exactly as
I expected.

So the question stands; what do you mean by "jump to"?

You mean much like alt="" on spacer images?

Valid HTML 4 requires that IMG elements have an ALT attribute, so the
correct expression of an absence of a text alternative is an ALT
attribute with an empty value. The WAI do insist that accessible web
pages should validate.

Valid HTML does not have to feature NOSCRIPT elements at all. And no WAI
guideline insists that for every SCRIPT there must be a corresponding
NOSCIRPT element.

However, we have a situation where the desire is to have the browser do
nothing. I am proposing that that is best achieved by not asking the
browser to do anything, and you are proposing achieving that by asking
the browser to do something that will result in nothing. I don't see
effort with the intention that it be futile as the optimum (or even
sensible) approach to achieving nothing.

[snip]

| > http://www.htmlguru.com/
| > Caveat: I haven't checked out every single page on every
| > available browser but the home page is ample demonstration.
|
| An error dialog and a blank screen on script enabled IE 6;
| that is about as far from "successfully execute on all
| (script capable) browsers" as you can get.

Hey, I'm not your helpdesk person.

As if I would be asking you for help.

If you can't get your browser to operate
correctly then contact the relevant company. LOL

My browser is operating correctly. It is the script on the page you
proposed as able to "successfully execute on all (script capable)
browsers" that is at fault. It commences by performing a number of test
based on invalid assumptions, inevitably comes to a false conclusion and
acts on that false conclusion, erroring-out as a result.

That it should fail so spectacularly on the most common web browser in
existence flags its author as utterly incompetent as a browser script
author. The UA string browser detection it performs and the evident eval
abuses make that obvious without attempting to execute the script, but
the impression given by the source code is underlined by its inevitable
failure.

I had no trouble displaying the site with NS7.2 or
IE6.0.2900.2180.xpsp_sp2_gdr.050301-1519 or FireFox 1.0.4.

So that is your definition of "all (script capable) browsers"?

Opera 8.0 did degrade nicely to an information screen.

And if Opera had script enabled was this degrading nicely achieved with
NOSCRIPT elements?

May I remind you that it was you who propose this page, and the script
it contains, as an apparent example of a script that "successfully
execute on all (script capable) browsers". So when it fails on the most
common browser in existence and refuses to operate at all on a dynamic
visual browser as capable (and W3C DOM standard) as Opera 8 it is your
judgement of DHTML script that is brought into question.

One can only aspire to such heights that one's scripts will
work in all browsers.

That depends on what you mean by 'works'. If you mean; successfully
execute and produce the desired active outcome on all (script capable
and enabled) browser, then the theory that such is impossible remains
unrefuted. If 'works' means; exhibits planned and designed behaviour
with viable results in all possible environments (including those with
scripting unavailable), then that is demonstrably achievable.

That's why you post here, isn't it?

No it isn't.

Richard.

 

[Michael Winter]

Jeff North wrote:
[snip]

<html>
<head>
<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>

As a block level element the NOSCIRPT element may not be a child or
descendant of the HEAD element in valid HTML.

On a point of pedantry:

Ignoring the absence of a TITLE element and DOCTYPE for the moment, that
partial document is valid up to the closing tag of the NOSCRIPT element.
The invalidity occurs with the second opening BODY tag: the first was
implicitly included when the opening tag of the NOSCRIPT element was
encountered.

Still, the point remains that it's invalid, but not for quite the reason
you suggest.

[snip]

If images are acting as spacers, then the alternative text for that
image should be whitespace. That would maintain the purpose of those
images in a text form. However, spacer images are a questionable feature.

[snip]

The UA string browser detection it performs [...]

With regard to your response to me, I do recall seeing an artifact
related to browser detection but I didn't look how it was implemented.
It doesn't really matter though, does it?

I didn't look closely enough for eval abuse, but it wouldn't surprise me
to find it.

[snip]

An information screen is not degrading nicely. That is flat-out failing
to provide anything useful. I suppose it's better than crashing or
something similarly ridiculous, though.

[snip]

Mike

 

[Richard Cornford]

Jeff North wrote:
[snip]

<html>
<head>
<script type="text/javascript">
alert("Executing Script");
</script>
<noscript>
<P>You have scripting disabled</P>
</noscript>
<body>

As a block level element the NOSCIRPT element may not be a
child or descendant of the HEAD element in valid HTML.

On a point of pedantry:

All right, just this once

Ignoring the absence of a TITLE element and DOCTYPE for
the moment,

Oh no, by all means be comprehensive

that partial document is valid up to the closing tag of
the NOSCRIPT element. The invalidity occurs with the second
opening BODY tag:

You mean the point at which I inserted the coment?

the first was implicitly included when the opening tag of
the NOSCRIPT element was encountered.
Absolutely.

Still, the point remains that it's invalid, but not for
quite the reason you suggest.

That is a matter of interpretation. It is invalid HTML because the
NOSCIRPT is not allowed to be a child or descendant of the HEAD. It is
that fact that allows the parser to infer a closing HEAD tag and an
opening BODY tag, and it is the creation by inference in the given
context of those two tags that renders the second opening BODY tag the
cause of (or at least one of the causes of) the document's invalidity.

[snip]

If images are acting as spacers, then the alternative
text for that image should be whitespace.

That would be a text alternative to a semantic spacer. A presentational
spacer would likely still have no text equivalent. Though as I recall
automated accessibility testing software winges if you have empty ALT
attribute values and white space is proposed as the best (least harmful)
compromise available.

That would maintain the purpose of those
images in a text form.

The most common purpose of those images is as shims in a table based
layout, so likely not impacting on the layout of text content itself but
only its visual placement as a whole.

However, spacer images are a questionable
feature.
Absolutely.

[snip]

The UA string browser detection it performs [...]

With regard to your response to me, I do recall seeing an
artifact related to browser detection but I didn't look
how it was implemented.

It is the first 50 lines in the referenced rouyerdesign.js script file.

It doesn't really matter though, does it?

No it doesn't matter why it is not an example of that category of script
it was proposed as an example of. It is surprising that it was proposed
as an example when it actually falls so far short.

I didn't look closely enough for eval abuse, but it
wouldn't surprise me to find it.

I always do a text search for "eval" when assessing a script, it saves
so much time.

[snip]

An information screen is not degrading nicely. That is flat-out
failing to provide anything useful. I suppose it's better than
crashing or something similarly ridiculous, though.

I would categorise that as an outright failure of the script as well,
especially if it suggested that Opera 8 did not provide the features
required by the script (because the script does not attempt anything
that script enabled Opera 8 (and 7) could not deliver upon).

Richard.

 

[Jeff North]

| On 18/06/2005 23:06, Richard Cornford wrote:
| > Jeff North wrote:
[snip]

| >> <html>
| >> <head>
| >> <script type="text/javascript">
| >> alert("Executing Script");
| >> </script>
| >> <noscript>
| >> <P>You have scripting disabled</P>
| >> </noscript>
| >> <body>
| >
| > As a block level element the NOSCIRPT element may not be a child or
| > descendant of the HEAD element in valid HTML.
|
| On a point of pedantry:
| Ignoring the absence of a TITLE element and DOCTYPE for the moment, that

...and just to be even more pendantic than you. You failed to notice
that there is NO </head> tag.

Just to please the pendantic types out there - try this.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Quick and Dirty example of the NOSCRIPT element</title>
<script type="text/tcl">
<![CDATA[
alert("Executing Script");
]]>
</script>
</head>
<body>
<noscript>
<p>This page requires TCL.</p>
</noscript>
<p>This is the body of the document</p>
</body>
</html>

 

[RobG]

| On 18/06/2005 23:06, Richard Cornford wrote:
| > Jeff North wrote:

[snip]


| >> <html>
| >> <head>
| >> <script type="text/javascript">
| >> alert("Executing Script");
| >> </script>
| >> <noscript>
| >> <P>You have scripting disabled</P>
| >> </noscript>
| >> <body>
| >
| > As a block level element the NOSCIRPT element may not be a child or
| > descendant of the HEAD element in valid HTML.
|
| On a point of pedantry:
| Ignoring the absence of a TITLE element and DOCTYPE for the moment, that

...and just to be even more pendantic than you. You failed to notice
that there is NO </head> tag.

Pedantic? Head tags are optional, there is no need to take exception
to their absence.

<URL:http://www.w3.org/TR/html4/struct/global.html#edef-HEAD>

 

[Jeff North]

| Jeff North wrote:
| > Richard Cornford wrote:
| >>| <snip>
| >>| >>|> 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 ......
| >>|
| >>| When the software authors impose a bogus interpretation of
| >>| the WAI guidelines there is no reflection in the WAI or
| >>| its guidelines.
| >
| > Oh you mean like HTML Tidy (which was written by W3C/WAI)
|
| Written by the W3C and WAI was it?

HTML Validator
The errors and warnings are generated by Tidy. This program is
originally developed by the Web Consortium W3C. Tidy is a helpful
program that tries to help people to correct their HTML errors.

Oh sorry, I wrote HTML Tidy and not HTML Validator.
Or do you mean that I wrote 'written' instead of 'developed'?

[snip]

| >>| NOSCRIPT elements do not provide that mechanism because they
| >>| are mutually exclusive to the wrong condition. They are only
| >>| used when script interpretation in unsupported or disabled.
| >
| > No quite right. As seen with the example that I posted from
| > the W3C site. It used TCL. If browser scripting was enabled
| > then the browser would attempt to execute the code, whether
| > it supported the code or not.
|
| Here you are saying that a browser encountering a script element with a
| TYPE attribute of "text/tcl" that that browser will attempt to execute
| that script regardless of whether it has a TCL interpreter or not. If
| you believe that then you really don't have a clue.

Well I'm happy to be disproved on my POV. With a little bit more
testing (on my behalf), I concede your point. In previous testing I
was only using javascript that led to my misunderstanding.

But.....

Try this fully validated code:
------------------------------------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Quick and Dirty example of the NOSCRIPT element</title>
<script type="text/tcl">
<![CDATA[
alert("Executing Script");
]]>
</script>
</head>
<body>
<noscript>
<p>Noscript.1 This page requires TCL.</p>
</noscript>

<p>This is the body of the document</p>
<P>.....|<script type="text/tcl">ns_write("Try
this")</script>|.....</P>
<noscript>
<p>Noscript.2 TCL command: ns_write("Try this") | not executed.</p>
</noscript>

<P>.....|<script type="text/javascript">document.write("Try
this");</script>|.....</P>
<noscript>
<p>Noscript.3 javascript not executed.</p>
</noscript>

</body>
</html>
--------------------------------------------------

Now the W3C states:
The NOSCRIPT element allows authors to provide alternate content when
a script is not executed. The content of a NOSCRIPT element should
only be rendered by a script-aware user agent in the following cases:

* The user agent is configured not to evaluate scripts.
* The user agent doesn't support a scripting language invoked by a
SCRIPT element earlier in the document.

User agents that do not support client-side scripts must render this
element's contents.
------------------------------

Now what is interesting is the results from different browsers.

IE 6: displays the noscript element.
FF1.0.4, NS7.2 and Opera8.0 do not render the noscript but they also
don't cause an error.

The output of FF:
-------------------------
This is the body of the document
......||.....
......|Try this|.....
-------------------------
So FF ignores the noscript but executes the js as per usual.

The IE6 output:
------------------------
Noscript.1 This page requires TCL.
This is the body of the document
......||.....
Noscript.2 TCL command: ns_write("Try this") | not executed.
......||.....
Noscript.3 javascript not executed.
--------------------------
The noscript tag is 'executed' but js is also ignored even though I
have js enabled.

Now if I turn off js in FF I get the same output as IE.

Hmmmmm. So basically it boils down to how the browser has been set to
interpret the standards.

[snip a whole lot of side issues]

 

[Richard Cornford]

Oh sorry, I wrote HTML Tidy and not HTML Validator.

So it is the W3C's HTML Validator that "uses the W3C/WAI 'guidelines' to
rate a site" and insists upon NOSCRIPT elements? I think not.

Or do you mean that I wrote 'written' instead of 'developed'?

No, when you write 'Tidy' I read 'Tidy' not 'Validator'.

Well I'm happy to be disproved on my POV.

Believing that a browser that only has a javascript interpreter might be
expected to attempt to execute the contents of a SCRIPT element with
type="text/tcl" is hardly a point of view.

With a little bit more testing (on my behalf),
I concede your point. In previous testing I
was only using javascript that led to my misunderstanding.

<snip>

The previous test certainly did nothing to promote understanding. It
appeared in response to my request for clarification of the meaning of
the words "jump to" (apparently an "html rendering process term") in
"browser will ignore any script tags and jump to the noscript tag" And
so far nothing has been presented that alters my impression that html
rendering must be using "jump to" very esoterically, to mean 'continues
to parse the input stream in the normal way'.

[snip a whole lot of side issues]

You don't think that was a side issue? How incapable NOSCRIPT elements
are at providing a mutually exclusive relationship with successfully, ac
tively executing and acting client-side scripts is a bit of a side
issue, once it is obvious that they do not provide that relationship at
all.

NOSCRIPT elements are not capable of contributing to the problems of
browser scripting for the Internet.

That isn't less true when they turn out to be inconsistently
implemented.

Richard.

 

[Jeff North]

| Jeff North wrote:
| > Richard Cornford wrote:
| >>| Jeff North wrote:
| <snip>
| >>|> Oh you mean like HTML Tidy (which was written by W3C/WAI)
| >>|
| >>| Written by the W3C and WAI was it?
| <snip>
| > Oh sorry, I wrote HTML Tidy and not HTML Validator.
|
| So it is the W3C's HTML Validator that "uses the W3C/WAI 'guidelines' to
| rate a site" and insists upon NOSCRIPT elements? I think not.
|
| > Or do you mean that I wrote 'written' instead of 'developed'?
|
| No, when you write 'Tidy' I read 'Tidy' not 'Validator'.
|
| <snip>
| >>|> ... . It used TCL. If browser scripting was enabled
| >>|> then the browser would attempt to execute the code,
| >>|> whether it supported the code or not.
| >>|
| >>| Here you are saying that a browser encountering a script
| >>| element with a TYPE attribute of "text/tcl" that that
| >>| browser will attempt to execute that script regardless of
| >>| whether it has a TCL interpreter or not. If you believe
| >>| that then you really don't have a clue.
| >
| > Well I'm happy to be disproved on my POV.
|
| Believing that a browser that only has a javascript interpreter might be
| expected to attempt to execute the contents of a SCRIPT element with
| type="text/tcl" is hardly a point of view.
|
| > With a little bit more testing (on my behalf),
| > I concede your point. In previous testing I
| > was only using javascript that led to my misunderstanding.
| <snip>
|
| The previous test certainly did nothing to promote understanding. It
| appeared in response to my request for clarification of the meaning of
| the words "jump to" (apparently an "html rendering process term") in
| "browser will ignore any script tags and jump to the noscript tag" And
| so far nothing has been presented that alters my impression that html
| rendering must be using "jump to" very esoterically, to mean 'continues
| to parse the input stream in the normal way'.
|
| <snip>
| > [snip a whole lot of side issues]
|
| You don't think that was a side issue? How incapable NOSCRIPT elements
| are at providing a mutually exclusive relationship with successfully, ac
| tively executing and acting client-side scripts is a bit of a side
| issue, once it is obvious that they do not provide that relationship at
| all.
|
| NOSCRIPT elements are not capable of contributing to the problems of
| browser scripting for the Internet.
|
| That isn't less true when they turn out to be inconsistently
| implemented.

You're a small man with a small mind.
Welcome to my moron file.

[plonk]

 

[Richard Cornford]

Richard Cornford wrote:

You're a small man with a small mind.
Welcome to my moron file.

Ahh, abuse.

[plonk]

So much easier than reasoned debate ;-)

Richard.

 

[Randy Webb]

Richard Cornford wrote:

You're a small man with a small mind.
Welcome to my moron file.

Ahh, abuse.

[plonk]

So much easier than reasoned debate ;-)

One has to posess the ability to reason before s/he can engage in a
reasoned debate, do they not?

So far, Jeff has not shown that he possesses that ability.

 

[Jeff North]

| Richard Cornford wrote:
| > Jeff North wrote:
| >
| >>Richard Cornford wrote:
| >
| > <snip>
| >
| >>>| NOSCRIPT elements are not capable of contributing to the
| >>>| problems of browser scripting for the Internet.
| >
| > <snip>
| >
| >>You're a small man with a small mind.
| >>Welcome to my moron file.
| >
| >
| > Ahh, abuse.
| >
| >
| >>[plonk]
| >
| >
| > So much easier than reasoned debate ;-)
|
| One has to posess the ability to reason before s/he can engage in a
| reasoned debate, do they not?
|
| So far, Jeff has not shown that he possesses that ability.

Why waste time with trolls such as Richard Cornford.

http://groups.google.com.au/group/comp.lang.javascript/msg/d6a529fc2888d9ad?hl=en
Me: One can only aspire to such heights that one's scripts will work
in all browsers. That's why you post here, isn't it?

RC: No it isn't.

 

[Richard Cornford]

Jeff North wrote:

Why waste time with trolls such as Richard Cornford.

Me: One can only aspire to such heights that one's
scripts will work in all browsers. That's why you
post here, isn't it?

RC: No it isn't.

An out of context quote, edited without indication of the omitted
paragraph? But what is this; Jeff North defines a troll as someone who
has more than simplistic motivations for posting to a newsgroup, and/or
motivations that do meet with his approval?

And this from someone who wrote:-

| Even with "no text at all" you still are required to provide
| (non)information to the browser of that object.

Richard.