Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Problems with JS turned off?

Reply
Thread Tools

Problems with JS turned off?

 
 
Michael Winter
Guest
Posts: n/a
 
      06-18-2005
On 18/06/2005 02:31, Jeff North wrote:

> On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
> Cornford" <(E-Mail Removed)> wrote:


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

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

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


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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      06-18-2005
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.

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

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

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.

<snip>
>>| 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/interac...l#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.

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


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.

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

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


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.

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


In what sense "right comment"?

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


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.


 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      06-18-2005
Michael Winter wrote:
> On 18/06/2005 02:31, Jeff North wrote:
>> Richard Cornford wrote:

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


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

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


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.

<snip>
>> So bite me.

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


 
Reply With Quote
 
Jeff North
Guest
Posts: n/a
 
      06-18-2005
On Sat, 18 Jun 2005 02:44:32 GMT, in comp.lang.javascript Michael
Winter <(E-Mail Removed)> wrote:

>| On 18/06/2005 02:31, Jeff North wrote:
>|
>| > On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
>| > Cornford" <(E-Mail Removed)> wrote:
>|
>| [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
<noscript></noscript>."

>| 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 http://www.velocityreviews.com/forums/(E-Mail Removed)

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

---------------------------------------------------------------
(E-Mail Removed) : Remove your pants to reply
---------------------------------------------------------------
 
Reply With Quote
 
Jeff North
Guest
Posts: n/a
 
      06-18-2005
On Sat, 18 Jun 2005 15:30:38 +0100, in comp.lang.javascript "Richard
Cornford" <(E-Mail Removed)> wrote:

>| 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/interac...l#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
<noscript></noscript> just to see what happens.

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

>|
>| Richard.
>|


---------------------------------------------------------------
(E-Mail Removed) : Remove your pants to reply
---------------------------------------------------------------
 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      06-18-2005
Jeff North wrote:
> <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.

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


 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      06-18-2005
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]

>>> http://www.htmlguru.com/


[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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      06-18-2005
Jeff North wrote:
> On Sat, 18 Jun 2005 15:30:38 +0100, in comp.lang.javascript "Richard
> Cornford" <(E-Mail Removed)> wrote:
>


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


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      06-18-2005
Jeff North wrote:
> Richard Cornford wrote:
>>| 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)


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.

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

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

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


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.

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


I beg your pardon?

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


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.

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


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

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


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.

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


 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      06-18-2005
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
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]

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


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]

>> Opera 8.0 did degrade nicely to an information screen.


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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To share printer does desktop need to be turned on? =?Utf-8?B?bWFtYXBhamFtYQ==?= Wireless Networking 3 03-20-2005 03:37 PM
cookies turned off? No. GFRfan Firefox 9 03-02-2005 06:37 PM
cookies turned off? No. GFRfan Firefox 0 02-28-2005 08:41 PM
Do Cisco PIX firewalls have NAT turned on by default? Fred Knobles Cisco 3 07-23-2004 08:36 AM
Buffering cannot be turned off once it is already turned on. Lord Merlin ASP General 0 04-11-2004 06:04 PM



Advertisments