473,320 Members | 1,695 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Problems with JS turned off?

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

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


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

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

Jul 23 '05 #2
"Jc" <go****@weinrichs.com> writes:
However, in the interests of development time, you may want to
target a percentage (say, 95%) of the site's audience, which can be
determined by keeping an eye on server logs.


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

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

/L 'Pure HTML is 100% accessible. All you an do is detract from that'
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #3
> From: Lasse Reichstein Nielsen <lr*@hotpop.com>
Making a page degrade gracefully isn't as hard as you make it sound,
if one thinks of it from the start.
/L 'Pure HTML is 100% accessible. All you can do is detract from that'


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

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

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

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

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

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

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

Jul 23 '05 #6
On 13 Jun 2005 17:39:30 -0700, in comp.lang.javascript
"drhowarddrfine" <ro*******@gmail.com> wrote:
| I'm working on a web site that could use some control using js but am
| concerned about what problems I may have with potential users having
| their js turned off. Has anyone had any serious problems with this
| sort of thing? I know some of these potential users are with big
| companies and am wondering if anyone had real problems with that.


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

<script type="text/javascript">
....
your scripts
.....
</script>
<noscript>
....
message to user with javascript disabled
....
</noscript>
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #7
Jeff North wrote:
<snip>
Simply use the noscript tag to inform user that they will
not have full access to the site.

<script type="text/javascript">
...
your scripts
....
</script>
<noscript>
...
message to user with javascript disabled
...
</noscript>


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

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

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

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

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

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

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

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

Richard.
Jul 23 '05 #8
On Thu, 16 Jun 2005 12:51:06 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> wrote:
| Jeff North wrote:
| <snip>
| > Simply use the noscript tag to inform user that they will
| > not have full access to the site.
| >
| > <script type="text/javascript">
| > ...
| > your scripts
| > ....
| > </script>
| > <noscript>
| > ...
| > message to user with javascript disabled
| > ...
| > </noscript>
|
| One thing that is apparent form searching the comp.lang.javascript
| archives for NOSCRIPT is that its use is very rarely proposed (at least
| in the current century), and almost never by the more experienced
| contributors.
Really?
I'm sure the WAI consortium would be interested in why they are
wasting their time, and effort, in invalidating sites that do not have
the <noscript> tag defined where any scripting language appears on a
page.
| The reason for this is simply that the NOSCRIPT element is not capable
| of contributing to the problems of browser scripting for the internet,
| and has not been for many years.
|
| The NOSCRIPT element is based on a premise that there are only two
| outcomes in browser scripting: 1) The script will work (the environment
| supports scripting and the script will fully achieve what is expected of
| it, and 2) The environment does not support scripting (it is unavailable
| or disabled) so no script will execute.
|
| That premise was true when NOSCRIPT was introduced because there was
| only one script supporting browser environment so a script either would
| be executed and work, or it would not (assuming that bugs/errors never
| got past testing).
|
| However, for some considerable time the problems of browser scripting
| have arisen form the availability of diverse client-side environments
| and that means that all internet browser scripts face three possible
| outcomes: 1) The script will execute and be fully supported by the
| browser environment in which it finds itself, 2) The script will execute
| but find that it is not supported by the browser environment (so it will
| fail to fully execute (degrade under its own control), or error-out if
| poorly written), and 3) The environment does not support scripting (it
| is unavailable or disabled).
So far you have not invalidated the use of the <noscript> tag. In fact
you have shown why you should use it.

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

Item 3 is where the script will not execute.

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

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

<SCRIPT type="text/tcl">
...some Tcl script to insert data...
</SCRIPT>
<NOSCRIPT>
<P>Access the <A href="http://someplace.com/data">data.</A>
</NOSCRIPT>
--------------
Can you give me an example of where the same thing can be achieved
without the need for the <noscript> tag.
| And there is certainly no point having a NOSCIRPT element telling a user
| that they need to enable javascript in order to view a site unless you
| can guarantee that enabling javascript will facilitate their viewing of
| that site, which is impossible.


Debatable.
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #9
Jeff North wrote:
In the following example, a user agent that executes the SCRIPT will
include some dynamically created data in the document. If the user
agent doesn't support scripts, the user may still retrieve the data
through a link.
<SCRIPT type="text/tcl">
...some Tcl script to insert data...
</SCRIPT>
<NOSCRIPT>
<P>Access the <A href="http://someplace.com/data">data.</A>
</NOSCRIPT>


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

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 23 '05 #10
Jeff North wrote:
Richard Cornford wrote: <snip>
| One thing that is apparent form searching the
| comp.lang.javascript archives for NOSCRIPT is that
| its use is very rarely proposed (at least in the
| current century), and almost never by the more
| experienced contributors.


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


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

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

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

<snip> So far you have not invalidated the use of the <noscript>
tag. In fact you have shown why you should use it.
How have I shown that 'you should use it'? Why would I promote a
situation where a proportion of users are denied access to content
because of the browser they choose to use in an Internet context?
As you point out below, items 1 and 2 are where the script will be
executed. The handling of the scripts compatability etc should be
programmed by the programmer, within the executable script.

Item 3 is where the script will not execute.

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

So there are still 3 outcomes, with one outcome in a script supporting
browser being identical to the outcome in a script incapable/disabled
browser.
| The middle option, of a script that is executed but cannot do what
| it intended in the environment in which it finds itself, is where
| the art of browser script design expresses itself. The concepts of
| scripted enhancement (that are not harmful/problematic when they
| cannot act) and clean degradation to fully viable underlying HTML
| (and server-side alternatives) are employed to make sense of this
| middle option. These are script design considerations that will
| feature in any quality Internet browser script. <snip>
Tell that to the W3C consortium.
http://www.w3.org/TR/html4/interact/....html#h-18.3.1
A description of the intended purpose of the NOSCRIPT element has no
baring on its inability to satisfy that purpose.
In the following example, a user agent that executes the SCRIPT will
include some dynamically created data in the document. If the user
agent doesn't support scripts, the user may still retrieve the data
through a link.

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


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

- No need for NOSCRIPT elements, and all script failure scenarios result
in the user having the options that your approach only provides when
scripting is completely unavailable on the client, leaving the user's of
less dynamic, but scriptable browsers, without any means of accessing
the 'data'.
| And there is certainly no point having a NOSCIRPT element
| telling a user that they need to enable javascript in order
| to view a site unless you can guarantee that enabling
| javascript will facilitate their viewing of that site, which
| is impossible.


Debatable.


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

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

Richard.
Jul 23 '05 #11
JRS: In article <d8*******************@news.demon.co.uk>, dated Thu, 16
Jun 2005 12:51:06, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :
Whatever made sense in the context of a script that found
that it could achieve nothing in a scriptable environment that did not
support the features/actions that it wanted to perform makes just as
much sense in an environment where scripting is disabled/unavailable (so
the script never could achieve anything). Thus a quality Internet
browser script needs no NOSCRIPT element by design.
Incorrect.

If a page is specifically designed to provide javascript executed at the
client, and to do nothing useful otherwise, then a NOSCRIPT can inform a
user whose browser is not executing script of the situation, without
bothering those whose browsers do execute script.
And there is certainly no point having a NOSCIRPT element telling a user
that they need to enable javascript in order to view a site unless you
can guarantee that enabling javascript will facilitate their viewing of
that site, which is impossible.


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

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #12
Dr John Stockton wrote:
Richard Cornford wrote:
Whatever made sense in the context of a script that found
that it could achieve nothing in a scriptable environment
that did not support the features/actions that it wanted
to perform makes just as much sense in an environment
where scripting is disabled/unavailable (so the script
never could achieve anything). Thus a quality Internet
browser script needs no NOSCRIPT element by design.
Incorrect.

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


A page cannot be designed to be dependent on javascript alone. It must
be dependent on scripting _and_ a certain group of host-provided
facilities and features. It must require _both_ before it can do
anything useful.
then a NOSCRIPT can inform a user whose browser is
not executing script of the situation, without
bothering those whose browsers do execute script.


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

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

If it is important to explain/justify the failure it should be important
to justify all such failures.
And there is certainly no point having a NOSCIRPT element
telling a user that they need to enable javascript in order
to view a site unless you can guarantee that enabling
javascript will facilitate their viewing of that site, which
is impossible.


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


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

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

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

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

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


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

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

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 23 '05 #14
On Thu, 16 Jun 2005 08:41:07 -0500, in comp.lang.javascript "Matt
Kruse" <ne********@mattkruse.com> wrote:
| Jeff North wrote:
| > In the following example, a user agent that executes the SCRIPT will
| > include some dynamically created data in the document. If the user
| > agent doesn't support scripts, the user may still retrieve the data
| > through a link.
| > <SCRIPT type="text/tcl">
| > ...some Tcl script to insert data...
| > </SCRIPT>
| > <NOSCRIPT>
| > <P>Access the <A href="http://someplace.com/data">data.</A>
| > </NOSCRIPT>
|
| This is a good illustration of the problem.
| My browser shows nothing at all, because it doesn't understand text/tcl
| script, yet it is script enabled so it doesn't show the <noscript> content
| either.


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

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

(Please note the title of the thread).
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #15
Matt Kruse wrote:
Richard Cornford wrote:
a script the attempted to employ little more than -
document.write - might have the 'noscript' content contained
in suitably CSS classed elements within the HTML and write out
a style element that assigned - display:none; - to those
elements (which would need to be suitably worded to take
account of browsers that support scripting but where CSS was
disabled/unavailable). And a script that depended upon -
innerHTML - could use that facility to remove such elements
from a page.


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

<snip>

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

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

Richard.
Jul 23 '05 #16
On Thu, 16 Jun 2005 15:22:21 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> wrote:
| Jeff North wrote:
| > Richard Cornford wrote:
| <snip>
| >>| One thing that is apparent form searching the
| >>| comp.lang.javascript archives for NOSCRIPT is that
| >>| its use is very rarely proposed (at least in the
| >>| current century), and almost never by the more
| >>| experienced contributors.
| >
| > Really?
| > I'm sure the WAI consortium would be interested in why
| > they are wasting their time, and effort, in invalidating
| > sites that do not have the <noscript> tag defined where
| > any scripting language appears on a page.
|
| When did the WAI 'consortium' (working group?) start 'invalidating' web
| sites?
Oh you know, Bobby, Tidy et al.
| But the WAI know that their current advice is (or may be superficially
| interpreted as) bad, because Jim keeps telling them. My impression is
| that they don't/won't change their advice because they don't understand
| browser scripting well enough (as individuals) and would prefer to be
| rid of it entirely.
Until they do 'get rid of it' the specification remains.
People like me, who do not have direct access to the people within the
consortium, must rely on what is published.
| However, the notion that for every SCRIPT there must be a NOSCRIPT is
| not WIA advice, it is more the product of inadequate mechanical
| accessibility testing. For many scripted actions there would be no
| meaningful NOSCRIPT content to provide. Client-side pre-submit form
| validation being one very common and obvious example.
|
| <snip>
| > So far you have not invalidated the use of the <noscript>
| > tag. In fact you have shown why you should use it.
|
| How have I shown that 'you should use it'? Why would I promote a
| situation where a proportion of users are denied access to content
| because of the browser they choose to use in an Internet context?
|
| > As you point out below, items 1 and 2 are where the script will be
| > executed. The handling of the scripts compatability etc should be
| > programmed by the programmer, within the executable script.
| >
| > Item 3 is where the script will not execute.
| >
| > So you still have the binary option of the script executing or not.
|
| A script may execute but be unable to act, due to the environment not
| providing the features that it need in order to act.
Please note the title of the thread.

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

If scripting is disabled then the browser will ignore any script tags
and jump to the noscript tag, if one is included.
| Indeed there do not
| appear to be many non-trivial actions that a script could attempt to
| undertake that will not fail on at least one known browser (and there
| are always many browsers that are unknown to each individual script
| author).
But that is up to the programmer to ensure that the script will
execute, or degrade gracefully, IF SCRIPTING IS ENABLED.

If scripting is disabled then the code will not be executed no matter
how well crafted it is. By using the noscript tag you can inform the
user of loss of functionality on the page. Hey you can even use
<noscript></noscript>.
| So there are still 3 outcomes, with one outcome in a script supporting
| browser being identical to the outcome in a script incapable/disabled
| browser.
incapable != disabled.
| >>| The middle option, of a script that is executed but cannot do what
| >>| it intended in the environment in which it finds itself, is where
| >>| the art of browser script design expresses itself. The concepts of
| >>| scripted enhancement (that are not harmful/problematic when they
| >>| cannot act) and clean degradation to fully viable underlying HTML
| >>| (and server-side alternatives) are employed to make sense of this
| >>| middle option. These are script design considerations that will
| >>| feature in any quality Internet browser script.
| <snip>
|
| > Tell that to the W3C consortium.
| > http://www.w3.org/TR/html4/interact/....html#h-18.3.1
|
| A description of the intended purpose of the NOSCRIPT element has no
| baring on its inability to satisfy that purpose.
|
| > In the following example, a user agent that executes the SCRIPT will
| > include some dynamically created data in the document. If the user
| > agent doesn't support scripts, the user may still retrieve the data
| > through a link.
| >
| > <SCRIPT type="text/tcl">
| > ...some Tcl script to insert data...
| > </SCRIPT>
| > <NOSCRIPT>
| > <P>Access the <A href="http://someplace.com/data">data.</A>
| > </NOSCRIPT>
| > --------------
| > Can you give me an example of where the same thing can
| > be achieved without the need for the <noscript> tag.
|
| <P id="scirptTarget">
| Access the <A href="http://someplace.com/data">data.</A>
| </P>
| <scirpt type="text/javascirpt">
| if(
| // Test to see if this browser supports the dynamic features
| // that would be required for the insertion of this 'data':
| // the replacing of the contents of an IDed P element with
| // alternative content
| ){
| // Locate the IDed P element in the DOM and replace its
| // contents with the 'data'. Or, possibly remove the P
| // element from the DOM and inset the 'data' elsewhere,
| // having tested for that facility instead.
| }
| </scirpt>
Oh I see, 20+ lines of cross browser compatible code to do what a
<noscript><a href...</noscript> section can do - right.

BTW it is script not scirpt. The fact that this appears multiple times
shows that it is not a typo (which I normally do not comment on).
| - No need for NOSCRIPT elements, and all script failure scenarios result
| in the user having the options that your approach only provides when
| scripting is completely unavailable on the client, leaving the user's of
| less dynamic, but scriptable browsers, without any means of accessing
| the 'data'.
|
| >>| And there is certainly no point having a NOSCIRPT element
| >>| telling a user that they need to enable javascript in order
| >>| to view a site unless you can guarantee that enabling
| >>| javascript will facilitate their viewing of that site, which
| >>| is impossible.
| >
| > Debatable.
|
| Only by people who are happy to tell lies to their users. Or do you mean
| that it is debatable whether it is impossible to write a non-trivial
| script that will successfully execute in all browser environments?
Obviously you have not heard of, or used, DHTML.
| In the latter case no debate is necessary as the question can be
| empirically resolved through the creation of one example non-trivial
| script that could not be shown to fail in at lest one environment. No
| such script has yet been created, and as more browsers come into
| existence the chances of it happening are diminishing.
|
| Richard.
|


---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #17
Jeff North wrote:
Richard Cornford wrote: <snip>
| > Really?
| > I'm sure the WAI consortium would be interested in why
| > they are wasting their time, and effort, in invalidating
| > sites that do not have the <noscript> tag defined where
| > any scripting language appears on a page.
|
| When did the WAI 'consortium' (working group?) start
| 'invalidating' web sites?


Oh you know, Bobby, Tidy et al.


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


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


The WAI has produced no specifications. They produce guidelines, that
require intelligent interpretation, which is why automated accessibility
testing is as likely to do more harm than good if used as the only
criteria for accessibility.
People like me, who do not have direct access to the
people within the consortium,
It is still a working group, and you can offer them your opinions if you
feel like it.
must rely on what is published.
You might then try actually reading what they publish. WCAG 1.0 only
features one occurrence of the string 'NOSCIRPT' and it appears in an
example not in one of the actual checkpoints. It is an example for
checkpoint 6.3, which reads:-

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

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

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

<snip>
| > So you still have the binary option of the script
| > executing or not.
|
| A script may execute but be unable to act, due to the environment
| not providing the features that it need in order to act.


Please note the title of the thread.


It is a subject not a title.
If scripting is enabled then the browser will try to
execute the script - right.
If it has an interpreter for the specified script type, otherwise, as
Matt Kruse pointed out, it won't be able to comprehend the source code.
Whether or not it can is another story and it is up to
the programmer to catch this 'problem' - yes.
Yes it is up to the programmer (or, more reasonably, the script designer
as it is a design issue not an implementation issue) to take account of
the possibility that a browser may support scripting but not provide the
environment that the script needs. The point of my comments is that once
the programmes has designed for that possibility (the possibility that
the script will not be able to act at all) they have already done
everything that they need to do in order to accommodate browsers where
scripting is unavailable.
If scripting is disabled then the browser will ignore any script
tags and jump to the noscript tag, if one is included.
Explain "jump to", that doesn't sound like an HTML thing at all.
| Indeed there do not appear to be many non-trivial actions
| that a script could attempt to undertake that will not
| fail on at least one known browser (and there are
| always many browsers that are unknown to each individual
| script author).


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


When a script degrades gracefully in the face of its inability to act it
will have done everything that would need to be done when scripting is
unavailable. That is what clean degradation is.
If scripting is disabled then the code will not be executed
no matter how well crafted it is.
But it won't be any more 'not executed' when scripting is unavailable as
it would be 'not executed' in an environment that does not facilitate
its execution.
By using the noscript tag you can inform the
user of loss of functionality on the page.
And by not using the NOSCRIPT _element_ you can inform the user of the
loss of functionality, except that without the NOSCRIPT element you can
inform them of the loss of functionality whenever they don't have that
functionality, instead of just when they don't have client-side
scripting available.

Not that there is much to be gained by bothering the user with that type
of technical detail.
Hey you can even use
<noscript></noscript>.
What possible good does that do anyone?
| So there are still 3 outcomes, with one outcome in a script
| supporting browser being identical to the outcome in a script
| incapable/disabled browser.


incapable != disabled.


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.

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


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


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

And no it doesn't do what NOSCRIPT elements would do, it does more. it
covers both the possibility that scripting is unavailable and the
possibility that the browser environment does not support the features
required by the script. It reduces the possible outcomes form three back
down to two, mutually exclusive, possibilities. Thus it completely
addresses the reality of browser scripting and does not leave users
falling through the cracks in the way that NOSCRIPT elements do.
BTW it is script not scirpt. The fact that this appears
multiple times shows that it is not a typo (which I
normally do not comment on).


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

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

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

Richard.
Jul 23 '05 #18
On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> 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 ......

<snip>
| > Until they do 'get rid of it' the specification remains.
|
| The WAI has produced no specifications. They produce guidelines, that
| require intelligent interpretation, which is why automated accessibility
| testing is as likely to do more harm than good if used as the only
| criteria for accessibility.
What other criteria is available for accessiblity testing?
| > People like me, who do not have direct access to the
| > people within the consortium,
|
| It is still a working group, and you can offer them your opinions if you
| feel like it.
|
| > must rely on what is published.
|
| You might then try actually reading what they publish. WCAG 1.0 only
| features one occurrence of the string 'NOSCIRPT' and it appears in an
| example not in one of the actual checkpoints. It is an example for
| checkpoint 6.3, which reads:-
You might want to look at 'guideline 1.1' before making any further
comments.

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

<snip>
| >>| > So you still have the binary option of the script
| >>| > executing or not.
| >>|
| >>| A script may execute but be unable to act, due to the environment
| >>| not providing the features that it need in order to act.
| >
| > Please note the title of the thread.
|
| It is a subject not a title.
Picky, pick, picky.
| > If scripting is enabled then the browser will try to
| > execute the script - right.
|
| If it has an interpreter for the specified script type, otherwise, as
| Matt Kruse pointed out, it won't be able to comprehend the source code.
You missed a few words from what I posted:
http://www.w3.org/TR/html401/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.

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

<snip>
| > 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 :-)

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

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

<snip irrelevant typo discussion>
| >>| Only by people who are happy to tell lies to their users.
| >>| Or do you mean that it is debatable whether it is impossible
| >>| to write a non-trivial script that will successfully execute
| >>| in all browser environments?
| >
| > Obviously you have not heard of, or used, DHTML.
| <snip>
|
| I beg your pardon?
Right comment, wrong area. So bite me.
| But what is this comment supposed to be about? Are you suggesting that
| it is possible to write DHTML that will successfully execute on all
| (script capable) browsers? If so feel free to demonstrate.


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

---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #19
Jeff North wrote:
The browser DID support scripts (scripting enabled), it just didn't
support the TCL script. Therefore it is up to the programmer to ensure
that the browser supported such scripts. It is not the browsers
responsibility.


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

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

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 23 '05 #20
On 18/06/2005 02:31, Jeff North wrote:
On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> 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.
Jul 23 '05 #21
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.
Jul 23 '05 #22
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.
Jul 23 '05 #23
On Sat, 18 Jun 2005 02:44:32 GMT, in comp.lang.javascript Michael
Winter <m.******@blueyonder.co.invalid> 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" <Ri*****@litotes.demon.co.uk> 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 jr*****@rouyerdesign.com

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

---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #24
On Sat, 18 Jun 2005 15:30:38 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> 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.
|


---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #25
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
Jul 23 '05 #26
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.
Jul 23 '05 #27
Jeff North wrote:
On Sat, 18 Jun 2005 15:30:38 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> 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
Jul 23 '05 #28
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.
Jul 23 '05 #29
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.
Jul 23 '05 #30
Michael Winter wrote:
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:


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


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.
Jul 23 '05 #31
On Sat, 18 Jun 2005 23:36:13 GMT, in comp.lang.javascript Michael
Winter <m.******@blueyonder.co.invalid> wrote:
| 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>
---------------------------

---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #32
Jeff North wrote:
On Sat, 18 Jun 2005 23:36:13 GMT, in comp.lang.javascript Michael
Winter <m.******@blueyonder.co.invalid> wrote:

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

--
Rob
Jul 23 '05 #33
On Sat, 18 Jun 2005 23:06:13 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> 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?
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]
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #34
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.

Richard.
Jul 23 '05 #35
On Sun, 19 Jun 2005 12:55:38 +0100, in comp.lang.javascript "Richard
Cornford" <Ri*****@litotes.demon.co.uk> wrote:
| 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]
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #36
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 ;-)

Richard.
Jul 23 '05 #37
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Jul 23 '05 #38
On Sun, 19 Jun 2005 21:27:08 -0400, in comp.lang.javascript Randy Webb
<Hi************@aol.com> wrote:
| 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/co...2888d9ad?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.

---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #39
Jeff North wrote:
<snip>
Why waste time with trolls such as Richard Cornford. <snip> 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.
Jul 23 '05 #40
Jeff North wrote:
On Sun, 19 Jun 2005 21:27:08 -0400, in comp.lang.javascript Randy Webb
<Hi************@aol.com> wrote:

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


If your impression of Richard is that he is a troll, then your
impression of Richard is not very well. I don't always agree with what
he says. I read it with an open mind but he tends to be more theoretical
than I care to be about scripting. But he is far from being a troll.
http://groups.google.com.au/group/co...2888d9ad?hl=en
I have actually read every article in this thread, and even some of them
twice.
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.


That is one thing I totally agree with. The pedantic issue aside that
you can't write a lot of dHTML scripts to work in "all" browsers because
it's impossible - some browsers just don't have the mechanism to do it.
But, I don't post here in the attempt to make my scripts work in all
browsers. I post (and read) here in an effort to do two things:

1) Share what I do know so that other people can hopefully gain from my
headaches of beating my head against the wall to get something to
"work". The site it references is no longer up but there is an old
thread in c.l.j along the lines of "dynamically loading js files" where
I was attempting to load a .js file on the fly.

http://groups-beta.google.com/group/...4847caed57098a

Geez what a URL.....

In the end, I knew I couldn't make it work on "all browsers" but maybe
the attempt helped someone else.

2) To learn. There are still things about this language that I don't
know/understand but I read/post here in the attempts to learn more. Its
all about the learning process to me (mostly anyway).

<OT>
Can anybody tell me how to find out who I registered the DNS with for
www.hikksworld.com so I can change it to point to my new IP Address? In
my infinite wisdom, all of my records were on a PC that crashed when I
moved.
</OT>

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Jul 23 '05 #41
On Mon, 20 Jun 2005 21:26:32 -0400, in comp.lang.javascript Randy Webb
<Hi************@aol.com> wrote:
| <OT>
| Can anybody tell me how to find out who I registered the DNS with for
| www.hikksworld.com so I can change it to point to my new IP Address? In
| my infinite wisdom, all of my records were on a PC that crashed when I
| moved.
| </OT>


I've checked on:
http://ws.arin.net/cgi-bin/whois.pl
http://www.networksolutions.com
http://www.betterwhois.com
http://www.regdiscount.com/
http://www.whois.sc/hikksworld.com

and all state that this name is available (presumably meaning not
registered).

You might find something of use on this page:
http://www.dnsstuff.com/

---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #42
On Mon, 20 Jun 2005 21:26:32 -0400, in comp.lang.javascript Randy Webb
<Hi************@aol.com> wrote:
| Jeff North wrote:
[snip]
| > 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.
|
| That is one thing I totally agree with. The pedantic issue aside that
| you can't write a lot of dHTML scripts to work in "all" browsers because
| it's impossible - some browsers just don't have the mechanism to do it.
That is why I wrote "One can only aspire to"
http://www.m-w.com
Main Entry: as·pire
1 : to seek to attain or accomplish a particular goal

In the sense of "to seek to attain".

Main Entry: seek
2 a : to go in search of : look for b : to try to discover
5 : to make an attempt

Sorry about all the dictionary definitions but I just don't want my
meaning to be miscontrued.
| But, I don't post here in the attempt to make my scripts work in all
| browsers. I post (and read) here in an effort to do two things:
|
| 1) Share what I do know so that other people can hopefully gain from my
| headaches of beating my head against the wall to get something to
| "work".
[snip]
| 2) To learn. There are still things about this language that I don't
| know/understand but I read/post here in the attempts to learn more. Its
| all about the learning process to me (mostly anyway).


My philosophy is: the day you stop learning is the day you stop being
alive.
---------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
---------------------------------------------------------------
Jul 23 '05 #43
On 21/06/2005 02:26, Randy Webb wrote:

[snip]
Can anybody tell me how to find out who I registered the DNS with for
www.hikksworld.com so I can change it to point to my new IP Address?


VeriSign is the exclusive registry for .com domains until late 2007. A
WHOIS query to whois.verisign-grs.com should point you to your
registrar, but it seems that the domain name has expired.

<URL:http://registrar.verisign-grs.com/cgi-bin/whois?whois_nic=hikksworld.com&type=domain>

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #44
Jeff North wrote:
Randy Webb wrote:
| Jeff North wrote:
|> 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.
|
| That is one thing I totally agree with. The pedantic issue
| aside that you can't write a lot of dHTML scripts to work
| in "all" browsers because it's impossible - some browsers
| just don't have the mechanism to do it.


That is why I wrote "One can only aspire to"
http://www.m-w.com
Main Entry: as·pire
1 : to seek to attain or accomplish a particular goal

In the sense of "to seek to attain".

Main Entry: seek
2 a : to go in search of : look for b : to try to discover
5 : to make an attempt

Sorry about all the dictionary definitions but I just don't
want my meaning to be miscontrued.

<snip>

It is ironic that a thread containing so many unanswered requests for
clarification of meaning should feature a dictionary definition of a
word that very few would misunderstand.

However, the subject of an aspiration deserves some evaluation of its
worth. For a human, aspiring to unpowered flight through the flapping or
whirling of the arms would be folly, while for most, aspiring to bipedal
locomotion would be superfluous.

It remains the definition of 'works', as used in this context, that
determines the value of the aspiration.

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


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


To make that sound reasonable, you have yet to show a user agent that
does support the (standardized) `script' element but does not support
JavaScript 1.0 or an ECMAScript implementation. There is certainly use
for the `noscript' element which is why it is still included in recent
specifications, even in the XHTML 1.1 Scripting Module; to say that a
quality Web document should not contain it is simply ... short-sighted
reasoning.
PointedEars
Jul 23 '05 #46
Thomas 'PointedEars' Lahn wrote:
Matt Kruse wrote:
Jeff North wrote:
In the following example, a user agent that executes the
SCRIPT will include some dynamically created data in the
document. If the user agent doesn't support scripts, the
user may still retrieve the data through a link.
<SCRIPT type="text/tcl">
...some Tcl script to insert data...
</SCRIPT>
<NOSCRIPT>
<P>Access the <A href="http://someplace.com/data">data.</A>
</NOSCRIPT>
This is a good illustration of the problem.
My browser shows nothing at all, because it doesn't
understand text/tcl script, yet it is script enabled so
it doesn't show the <noscript> content either.


To make that sound reasonable, you have yet to show a user
agent that does support the (standardized) `script' element
but does not support JavaScript 1.0 or an ECMAScript
implementation.


It may be of little practical importance that NOSCRIPT elements would
behave disastrously badly on most browsers encountering the above HTML,
because nobody in their right mind would be attempting to script a web
browser with text/tcl, the extremely unsatisfactory results achieved
with the example HTML on script enabled browsers does illustrate one way
in which NOSCRIPT elements are completely inadequate for their intended
purpose.
There is certainly use for the `noscript' element
Are you in a position to suggest one where _all_ outcomes, scripted or
not, are satisfactory and noscript elements are actually necessary?
which is why it is still included in recent
specifications, even in the XHTML 1.1 Scripting Module;
Don't expect the authors of the XHTML specs to understand browser
scripting. They are quite capable of repeating the errors of the past.
to say that a quality Web document should not
contain it is simply ... short-sighted reasoning.


No, it is an appreciation that anything that needs to be presented when
scripting is unavailable will also need to be presented when scripting
is available but the browser doesn't support the features required by
the script. And the actions taken to cover that possibility will
inevitably satisfy the situation where scripting is unavailable. This
renders the NOSCRIPT element redundant.

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

This is a good illustration of the problem.
My browser shows nothing at all, because it doesn't
understand text/tcl script, yet it is script enabled so
it doesn't show the <noscript> content either.
To make that sound reasonable, you have yet to show a user
agent that does support the (standardized) `script' element
but does not support JavaScript 1.0 or an ECMAScript
implementation.


It may be of little practical importance that NOSCRIPT elements would
behave disastrously badly on most browsers encountering the above HTML,
because nobody in their right mind would be attempting to script a web
browser with text/tcl,


Correct. See?
the extremely unsatisfactory results achieved with the example HTML on
script enabled browsers does illustrate one way in which NOSCRIPT
elements are completely inadequate for their intended purpose.
The example attempts to prove the inadequacy of the `noscript' element,
but, due to its design, it fails to do that. The example is bogus since,
as you correctly stated, it is highly improbable that such a script
element using text/tcl or another non-JavaScript/JScript/ECMAScript (in
the following: JS) client-side scripting language will be contained in
an (X)HTML document; on the other hand, it is highly probable (just because
of historical events) and there exist numerous examples that JS is the
default and, equally probable and existing (see Mozilla/4.0+ without
plugin or extension for example), the *only* supported client-side
scripting language.

Thus, so far the `noscript' element has only been proven to be inadequate
when used with another script language than the default scripting language
-- dare I say JS? -- of the used UA.
There is certainly use for the `noscript' element


Are you in a position to suggest one where _all_ outcomes, scripted or
not, are satisfactory and noscript elements are actually necessary?


I'm glad you ask. Yes, I do think I am:

<http://www.stud.tu-ilmenau.de/~thla-in/ufpdb/individu/data.htm>

(This URI will probably become unusable in the future; then
use <http://pointedears.de/ufpdb/individu/data.htm> instead.
Don't mind minimum feature tests and some deprecated code,
I wrote that at a previous stage of knowledge.)

- With client-side script support enabled, the script detects whether
the document is displayed within a frameset; if yes, it is attempted
to change the Banner Frame so that it contains the correct headings
for the current document in the Content Frame; if no, the headings
are written dynamically into the Content Frame document via scripting.

- With client-side script support disabled or not present, it is not
possible to determine whether the document is displayed within a
frameset or not; however, it requires headings that (obviously)
could not be included before, and so they are contained in the
block-level `noscript' element.

Not using the `noscript' element would have resulted in including
duplicate headings.
which is why it is still included in recent
specifications, even in the XHTML 1.1 Scripting Module;


Don't expect the authors of the XHTML specs to understand browser
scripting. They are quite capable of repeating the errors of the past.
to say that a quality Web document should not
contain it is simply ... short-sighted reasoning.


No, it is an appreciation that anything that needs to be presented when
scripting is unavailable will also need to be presented when scripting
is available


Not anything and not always. This absolutism is the core flaw of your
argument.
but the browser doesn't support the features required by the script. And
the actions taken to cover that possibility will inevitably satisfy the
situation where scripting is unavailable.
See above.
This renders the NOSCRIPT element redundant.


No, it is not.
PointedEars
Jul 23 '05 #48
Thomas 'PointedEars' Lahn wrote:
Richard Cornford wrote:
Thomas 'PointedEars' Lahn wrote:
Matt Kruse wrote: <snip> This is a good illustration of the problem.
My browser shows nothing at all, because it doesn't
understand text/tcl script, yet it is script enabled so
it doesn't show the <noscript> content either.

To make that sound reasonable, you have yet to show a user
agent that does support the (standardized) `script' element
but does not support JavaScript 1.0 or an ECMAScript
implementation.
It may be of little practical importance that NOSCRIPT elements
would behave disastrously badly on most browsers encountering
the above HTML, because nobody in their right mind would be
attempting to script a web browser with text/tcl,


Correct. See?


The practical aspects of the situation do not diminish the worth of
Matt's comment. The HTML as proposed demonstrates a serious flaw in the
design of the NOSCRIPT element. And your browser that does not support
javascript but does understand and execute scripts is IE, with the
JScritp dll removed from the system and the VBScritp dll (or an
alternative) still available. maybe not a common configuration but a
possible one.
the extremely unsatisfactory results achieved with the
example HTML on script enabled browsers does illustrate
one way in which NOSCRIPT elements are completely
inadequate for their intended purpose.


The example attempts to prove the inadequacy of the
`noscript' element,


It does no such thing. That example is straight from the HTML spec. It
attempts to illustrate the use of the NOSCRIPT element (and since it is
from the spec it is theoretically the correct use of the NOSCRIPT
element that it attempts to illustrate).
but, due to its design, it fails to do that.
It certainly does fail, but it reveals a design flaw in the NOSCRIPT
element.
The example is bogus since, as you correctly stated,
it is highly improbable that such a script element
using text/tcl or another non-JavaScript/JScript/ECMAScript
(in the following: JS) client-side scripting language will
be contained in an (X)HTML document;
The W3C have never mandated that ECMAScript is to be the only scripting
language to be supported in Internet UAs. If they did there would be no
point in having TYPE attributes on SCRIPT elements, or specifying a
default language for intrinsic events. From their point of view it makes
perfect sense to produce examples that use various scripting languages.
It is just a pity that they seem to have overlooked the consequences of
this policy then it comes to NOSCRIPT elements.

<snip> Thus, so far the `noscript' element has only been proven
to be inadequate when used with another script language
than the default scripting language -- dare I say JS?
-- of the used UA.
No, it has been pointed out that NOSCRIPT elements contribute nothing
when scripting is enabled but the browser's environment does not support
the features required by the script. It is that consideration that has
the real practical implications.
There is certainly use for the `noscript' element


Are you in a position to suggest one where _all_ outcomes,
scripted or not, are satisfactory and noscript elements are
actually necessary?


I'm glad you ask. Yes, I do think I am:

<http://www.stud.tu-ilmenau.de/~thla-in/ufpdb/individu/data.htm>

<snip>

| <script type="text/javascript">
| <!--
| if ((parent.frames.length == 0) || OP) {
| document.write(
| "<h2>STARFLEET PERSONNEL FILE<\/h2>",
| "<h3>DATA<\/h3>"
| );
| } else if(parent.frames.ufpdb_banner)
| parent.frames.ufpdb_banner.RotateUFPLogo(true);
| //-->
| </script>
| <noscript>
| <h2>STARFLEET PERSONNEL FILE</h2>
| <h3>DATA</h3>
| </noscript>

Runtime Error: "parent.frames is not an object" Line 24.

The script errors-out so the document.write is never executed and
because scripting is enabled the NOSCRIPT element is never used.

That does not qualify as a satisfactory outcome by your own standards.

And, yes there are scriptable browsers that do not support frames, and
so have no reason to implement a - frames - collection (indeed, not
implementing that object is a good suggestion to the script author that
the browser does not support frames).

And so, as I have been saying all along, when scripting is supported but
the browser does not support the features required by the scrip the
NOSCRIPT element is not sufficient to address the problems and instead
it is necessary do carry out proper feature detection and design for
clean degradation.
Not using the `noscript' element would have resulted
in including duplicate headings.


In what sense are the two sets of H2 and H3 elements (plus whatever
would have been in the other frame) not duplicate headings?

<snip>
No, it is an appreciation that anything that needs to
be presented when scripting is unavailable will also need
to be presented when scripting is available


Not anything and not always. This absolutism is the core
flaw of your argument.


(Pot - Kettle)

I have asked for examples of non-trivial scripts that demonstrate value
in the NOSCRIPT element. They are not forthcoming. And your example was
pretty trivial in attempting nothing more than document.write, yet it
still stuffed up and made my point for me instead.
but the browser doesn't support the features required by
the script. And the actions taken to cover that possibility
will inevitably satisfy the situation where scripting is
unavailable.


See above.


What I saw was an illustration of the point I was making.
This renders the NOSCRIPT element redundant.


No, it is not.


:)

Richard.
Jul 23 '05 #49
Thomas 'PointedEars' Lahn wrote:
The example attempts to prove the inadequacy of the `noscript'
element, but, due to its design, it fails to do that. The example is
bogus since, as you correctly stated, it is highly improbable that
such a script element using text/tcl or another
non-JavaScript/JScript/ECMAScript (in the following: JS) client-side
scripting language will be contained in
an (X)HTML document;


Granted, the argument is about theory more than practice.

Speaking from a logical and conceptual standpoint, the example illustrates
that the evaluation of <noscript> content is a binary condition, and the
ability of a browser to execute a <script> tag on the same page is not
necessarily the opposite of that condition.

In every browser I can think of, content of a <script
type="text/javascript"> tag and content of a <noscript> tag will always be
mutually exclusive. However, in theory, that doesn't necessary need to be
the case. For example, if <script type="text/vbscript"> is included in the
page, IE will show the script, and other browsers will show nothing at all.

Since there is a way to develop a page such that non-script content is only
shown if the browser lacks the ability to execute the exact script written,
that's preferred. Even if <noscript> would work in all the practical cases
you can think of.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 23 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Pedro Fonseca | last post by:
Greetings everyone! I'm porting my applications to PHP5 and I've stumbled on yet another problem. I'll try to simplify things a bit. I have a main script that is being executed (index.php, PHP5...
3
by: Simon Wigzell | last post by:
My client has many forms on his Business website. They all use the "onsubmit" verification method e.g. <form ......... onsubmit="return FormValidator(this);"> <script> function...
8
by: John Welch | last post by:
I have a command button with the following code: DoCmd.OpenForm "frmSearchAssignments", , , "SearchAssignmentID = 1" (SearchAssignmentID is the PK, auto number) When it runs, the form opens but...
5
by: Dan Smith | last post by:
When I try to create a new C# Web Reference in Visual Studio 2003, I get an error message "The proxy settings on this computer are not configured correctly for web discovery. ..." This web...
1
by: Daniel Passwater via DotNetMonster.com | last post by:
I've written an app in C# in the compact framework. I've got a serial connection with a device running embedded C. We are using no flow control. That's not optional at this point. We are talking at...
2
by: Jeff S | last post by:
No question here; just information that anyone running ZoneAlarm on a development machine may find useful as you develop your ASP.NET apps - (or for those of you who are assisting users who may be...
2
by: Chris Newby | last post by:
We are running Win2K / IIS5 in an Active Directory setup. We are running an ASP.NET application that is configured to use Integrated Security (with Anonymous and Basic turned off) and that has...
27
by: CTI | last post by:
I got problems when I want to make a MDE file. The app. got a lack of memory. Bart Access 2003
34
by: Alexnb | last post by:
Gerhard Häring wrote: No, it didn't work, but it gave me some interesting feedback when I ran it in the shell. Heres what it told me: Traceback (most recent call last): File...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.