Problems with JS turned off?

Discussion in 'Javascript' started by drhowarddrfine, Jun 14, 2005.

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

  2. drhowarddrfine

    Jc Guest

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


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

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

  3. "Jc" <> writes:

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


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

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

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


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

    Then about a year ago Yahoo changed their Mail service so it's almost
    totally unusable without JavaScript. I can log in and see a listing of
    how many messages are new in each folder, and I can go to my InBox or
    other folder and see all the messages, but there's no way to see which
    of the messages in a folder are new and which are old so there's no
    reasonable way to visit all the spam so they no longer show as new
    messages in the folder summary page, and there's no way to complain
    about spam because the SPAM button is now JavaScript, and there's no
    way to send outgoing e-mail (either Compose new or Reply to old)
    because that requires JavaScript, and there's no way to move spam
    messages to another folder or delete them to get them out of my InBox
    because both features require JavaScript, and there's no way to move my
    legitimate messages out of InBox to get them away from spam, and
    virtually all the other Yahoo! Mail features ar likewise unusable from
    home because they require JavaScript. I'm totally 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.
    Robert Maas, see http://tinyurl.com/uh3t, Jun 14, 2005
    #4
  5. drhowarddrfine

    drWot Guest

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

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

    So in the head of my pages I load a script that tests for
    document.implementation.hasFeature('html','1.0');
    and if it returns true the serious javascript gets loaded; otherwise, no
    harm done.
    drWot, Jun 14, 2005
    #5
  6. 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.
    drhowarddrfine, Jun 14, 2005
    #6
  7. drhowarddrfine

    Jeff North Guest

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

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


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

    <script type="text/javascript">
    ....
    your scripts
    .....
    </script>
    <noscript>
    ....
    message to user with javascript disabled
    ....
    </noscript>
    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
    Jeff North, Jun 14, 2005
    #7
  8. 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.
    Richard Cornford, Jun 16, 2005
    #8
  9. drhowarddrfine

    Jeff North Guest

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

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


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

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


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

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

    Item 3 is where the script will not execute.

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

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


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

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

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

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


    Debatable.
    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
    Jeff North, Jun 16, 2005
    #9
  10. drhowarddrfine

    Matt Kruse Guest

    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
    Matt Kruse, Jun 16, 2005
    #10
  11. 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/scripts.html#h-18.3.1


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

    > In the following example, a user agent that executes the SCRIPT will
    > include some dynamically created data in the document. If the user
    > agent doesn't support scripts, the user may still retrieve the data
    > through a link.
    >
    > <SCRIPT type="text/tcl">
    > ...some Tcl script to insert data...
    > </SCRIPT>
    > <NOSCRIPT>
    > <P>Access the <A href="http://someplace.com/data">data.</A>
    > </NOSCRIPT>
    > --------------
    > Can you give me an example of where the same thing can
    > be achieved without the need for the <noscript> tag.


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

    - 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.
    Richard Cornford, Jun 16, 2005
    #11
  12. JRS: In article <d8rp3b$bnt$1$>, dated Thu, 16
    Jun 2005 12:51:06, seen in news:comp.lang.javascript, Richard Cornford
    <> 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.
    Dr John Stockton, Jun 16, 2005
    #12
  13. 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.
    Richard Cornford, Jun 17, 2005
    #13
  14. drhowarddrfine

    Matt Kruse Guest

    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
    Matt Kruse, Jun 17, 2005
    #14
  15. drhowarddrfine

    Jeff North Guest

    On Thu, 16 Jun 2005 08:41:07 -0500, in comp.lang.javascript "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.


    .... 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).
    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
    Jeff North, Jun 17, 2005
    #15
  16. 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.
    Richard Cornford, Jun 17, 2005
    #16
  17. drhowarddrfine

    Jeff North Guest

    On Thu, 16 Jun 2005 15:22:21 +0100, in comp.lang.javascript "Richard
    Cornford" <> 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/scripts.html#h-18.3.1
    >|
    >| A description of the intended purpose of the NOSCRIPT element has no
    >| baring on its inability to satisfy that purpose.
    >|
    >| > In the following example, a user agent that executes the SCRIPT will
    >| > include some dynamically created data in the document. If the user
    >| > agent doesn't support scripts, the user may still retrieve the data
    >| > through a link.
    >| >
    >| > <SCRIPT type="text/tcl">
    >| > ...some Tcl script to insert data...
    >| > </SCRIPT>
    >| > <NOSCRIPT>
    >| > <P>Access the <A href="http://someplace.com/data">data.</A>
    >| > </NOSCRIPT>
    >| > --------------
    >| > Can you give me an example of where the same thing can
    >| > be achieved without the need for the <noscript> tag.
    >|
    >| <P id="scirptTarget">
    >| Access the <A href="http://someplace.com/data">data.</A>
    >| </P>
    >| <scirpt type="text/javascirpt">
    >| if(
    >| // Test to see if this browser supports the dynamic features
    >| // that would be required for the insertion of this 'data':
    >| // the replacing of the contents of an IDed P element with
    >| // alternative content
    >| ){
    >| // Locate the IDed P element in the DOM and replace its
    >| // contents with the 'data'. Or, possibly remove the P
    >| // element from the DOM and inset the 'data' elsewhere,
    >| // having tested for that facility instead.
    >| }
    >| </scirpt>


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

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

    >| - No need for NOSCRIPT elements, and all script failure scenarios result
    >| in the user having the options that your approach only provides when
    >| scripting is completely unavailable on the client, leaving the user's of
    >| less dynamic, but scriptable browsers, without any means of accessing
    >| the 'data'.
    >|
    >| >>| And there is certainly no point having a NOSCIRPT element
    >| >>| telling a user that they need to enable javascript in order
    >| >>| to view a site unless you can guarantee that enabling
    >| >>| javascript will facilitate their viewing of that site, which
    >| >>| is impossible.
    >| >
    >| > Debatable.
    >|
    >| Only by people who are happy to tell lies to their users. Or do you mean
    >| that it is debatable whether it is impossible to write a non-trivial
    >| script that will successfully execute in all browser environments?


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

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


    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
    Jeff North, Jun 17, 2005
    #17
  18. 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.
    Richard Cornford, Jun 17, 2005
    #18
  19. drhowarddrfine

    Jeff North Guest

    On Fri, 17 Jun 2005 09:34:10 +0100, in comp.lang.javascript "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 ......

    <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/interact/scripts.html#idx-script-6
    If the user agent doesn't support scripts, .....

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

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

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

    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
    Jeff North, Jun 18, 2005
    #19
  20. drhowarddrfine

    Matt Kruse Guest

    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
    Matt Kruse, Jun 18, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?QnJpYW4gQ2FsbA==?=

    "Access is denied" error with Indexing Service turned off

    =?Utf-8?B?QnJpYW4gQ2FsbA==?=, Jul 13, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    421
    =?Utf-8?B?QnJpYW4gQ2FsbA==?=
    Jul 13, 2004
  2. Will
    Replies:
    1
    Views:
    3,987
  3. mrcakey
    Replies:
    4
    Views:
    305
    freemont
    Sep 5, 2007
  4. Squat'n Dive
    Replies:
    3
    Views:
    278
    Martin v. Löwis
    Jan 17, 2008
  5. Lord Merlin
    Replies:
    0
    Views:
    578
    Lord Merlin
    Apr 11, 2004
Loading...

Share This Page