two dropdown menus

Discussion in 'Javascript' started by Continental Translations, Jun 10, 2004.

  1. Can anybody help me? I am trying to create two drop down menus, where the
    results of the second one vary depending on what was selected in the first
    one. I am using MS Script Editor in MS Front Page to do this.

    In my first menu, I want "English" "German" and "Russian."

    Now if "English" is picked, I want "French" "German" and "Spanish" to
    appear.
    If "German" is picked in the first menu, I want "English" to appear"
    If Russian is picked in the first menu, I want "Dutch" to appear.

    Any advice? I ain't clued up that much on Javascript!

    Thanks all
    Continental Translations, Jun 10, 2004
    #1
    1. Advertising

  2. Continental Translations

    Kien Guest

    Continental Translations wrote:
    > Can anybody help me? I am trying to create two drop down menus, where the
    > results of the second one vary depending on what was selected in the first
    > one. I am using MS Script Editor in MS Front Page to do this.
    >
    > In my first menu, I want "English" "German" and "Russian."
    >
    > Now if "English" is picked, I want "French" "German" and "Spanish" to
    > appear.
    > If "German" is picked in the first menu, I want "English" to appear"
    > If Russian is picked in the first menu, I want "Dutch" to appear.
    >
    > Any advice? I ain't clued up that much on Javascript!
    >
    > Thanks all
    >
    >

    Hi,
    Go here

    http://www.caoxuan.com/cxk/webart/goodies/IndexForms.html

    HTH Kien
    Kien, Jun 10, 2004
    #2
    1. Advertising

  3. Continental Translations

    kaeli Guest

    In article <ca9f5u$apg$>,
    enlightened us with...


    > I am using MS Script Editor in MS Front Page to do this.


    I'm sorry.
    What did you do to deserve that?

    >
    > In my first menu, I want "English" "German" and "Russian."
    >
    > Now if "English" is picked, I want "French" "German" and "Spanish" to
    > appear.
    > If "German" is picked in the first menu, I want "English" to appear"
    > If Russian is picked in the first menu, I want "Dutch" to appear.
    >


    The following works in IE6 and NN7. I didn't check other browsers. Watch
    for word-wrap.

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
    "http://www.w3.org/TR/REC-html40/loose.dtd">
    <html>
    <head>
    <title> Dynamic select boxes </title>
    <script type="text/javascript" language="javascript">
    var firstChoices = new Array(
    "English",
    "German",
    "Russian"
    );

    var secondChoices = new Array();
    secondChoices["English"] = new Array(
    "French",
    "German",
    "Spanish"
    );
    secondChoices["German"] = new Array(
    "English"
    );
    secondChoices["Russian"] = new Array(
    "Dutch"
    );

    function setUp()
    {
    // get form element
    var f = document.getElementById("f1");

    // make first select element
    var s1 = document.createElement("select");
    s1.setAttribute("name","s1");
    s1.setAttribute("id","s1");
    f.appendChild(s1);

    // fill in first select element
    var L = firstChoices.length;
    var i;
    var o;
    o = document.createElement("option");
    o.setAttribute("name","o");
    o.setAttribute("id","o");
    o.setAttribute("value","0");
    o.appendChild(document.createTextNode("--- Choose One ---"));
    s1.appendChild(o);
    for (i=0; i<L; i++)
    {
    o = document.createElement("option");
    o.setAttribute("name","o"+i);
    o.setAttribute("id","o"+i);
    o.setAttribute("value",firstChoices);
    o.appendChild(document.createTextNode(firstChoices));
    s1.appendChild(o);
    }
    // attach onchange event to select
    if (s1.attachEvent)
    {
    s1.attachEvent("onchange",editOptions);
    }
    else if (s1.addEventListener)
    {
    s1.addEventListener("change",editOptions,false);
    }
    }

    function editOptions()
    {
    // make second select depending on value of first
    // if it's already there, remove it and re-create

    // get form element
    var f = document.getElementById("f1");

    if (document.getElementById("s2"))
    f.removeChild(document.getElementById("s2"));


    // get the value of the first select
    var val = f.elements["s1"].options[f.elements
    ["s1"].selectedIndex].value;

    // make second select element
    var s2 = document.createElement("select");
    s2.setAttribute("name","s2");
    s2.setAttribute("id","s2");
    f.appendChild(s2);

    // fill in second select element
    var L = secondChoices[val].length;
    var i;
    var o;
    o = document.createElement("option");
    o.setAttribute("name","o");
    o.setAttribute("id","o");
    o.setAttribute("value","0");
    o.appendChild(document.createTextNode("--- Choose One ---"));
    s2.appendChild(o);
    for (i=0; i<L; i++)
    {
    o = document.createElement("option");
    o.setAttribute("name","o"+i);
    o.setAttribute("id","o"+i);
    o.setAttribute("value",secondChoices[val]);
    o.appendChild(document.createTextNode(secondChoices[val]));
    s2.appendChild(o);
    }
    }
    </script>
    </head>

    <body onLoad="setUp()">
    <form name="f1" id="f1" action="">
    </form>
    </body>
    </html>

    --
    --
    ~kaeli~
    Time flies like an arrow. Fruit flies like a banana.
    http://www.ipwebdesign.net/wildAtHeart
    http://www.ipwebdesign.net/kaelisSpace
    kaeli, Jun 10, 2004
    #3
  4. Continental Translations

    Matt Kruse Guest

    Continental Translations wrote:
    > Can anybody help me? I am trying to create two drop down menus, where
    > the results of the second one vary depending on what was selected in
    > the first one.


    This is a FAQ, and should probaly be addressed in the FAQ!

    There are a number of solutions available. Some are specific to the data and
    screen in question, others are general solutions which can be reused on any
    page where dynamic dropdown menus are needed. my solution falls into the
    latter, and can be found at
    http://www.javascripttoolbox.com/dynamicoptionlist/

    Be aware that these client-side javascript solutions will fail for browsers
    that do not support javascript, and depending on your requirements, you may
    want to include a server-side solution which duplicates the same behavior.

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 10, 2004
    #4
  5. Matt Kruse wrote:
    > Continental Translations wrote:
    >> Can anybody help me? I am trying to create two drop down menus, where
    >> the results of the second one vary depending on what was selected in
    >> the first one.

    >
    > This is a FAQ, and should probaly be addressed in the FAQ!

    <snip>

    It is certainly a regularly asked question, I don't know that it is
    frequently asked in the sense that most other FAQ questions are as it
    seems to come in spates with a couple of months in-between. But maybe it
    is (though you will have to follow FAQ request procedure if you want it
    considered for the next review).

    But what would the FAQ say on the subject: "Don't design this
    requirement into a project as it cannot be satisfactorily implemented."?
    There isn't an implementation that I would recommend, I have only seen
    three that even attempt to address the degradation issue and none of
    them are that usable in their degraded state (Lasse Reichstein Nielsen's
    being about the best, but it sacrifices some (old) browser
    compatibility).

    Richard.
    Richard Cornford, Jun 10, 2004
    #5
  6. Continental Translations

    Matt Kruse Guest

    Richard Cornford wrote:
    > (though you will have to follow FAQ request procedure if you
    > want it considered for the next review).


    Or maybe I'll just create a simple HTML page addressing the issue.
    A lot of the same responses are posted to this group, not just for this
    question, but for many others. It would be helpful to summarize the
    responses into a single HTML page that users could be directed to. Even if
    it's not in the official FAQ.

    > But what would the FAQ say on the subject: "Don't design this
    > requirement into a project as it cannot be satisfactorily
    > implemented."?


    No, it would point out a number of resources which solve the problem, both
    with simple examples (storing options in arrays and simply creating new
    Option objects) and complex solutions (like my library and others).

    It would also point out that there are potential problems with relying on
    this functionality, explain why, and gives examples of situations where this
    must be taken into consideration and situations where it's not a concern.

    > There isn't an implementation that I would recommend


    That's because you try to fit everything into a box that you are comfortable
    with :)

    > I have only seen three that even attempt to address the degradation
    > issue


    Of course, the degradation issues doesn't always need to be addressed. If a
    summary of the issue pointed out that for environments where browsers are
    fixed, or javascript is required, or degrading gracefully is not important,
    then the user could simply select which pre-existing solution fitted their
    needs the best.

    > and none of them are that usable in their degraded state (Lasse
    > Reichstein Nielsen's being about the best, but it sacrifices some
    > (old) browser compatibility).


    When I get time to play with it, I'll build an example that degrades nicely
    for you, using my library.
    In short, it works like this:
    ------------------------------------------------------------------------
    <select name="first" onchange="if (browser has enough capabilities) { call
    dynamic population code }">
    <noscript>
    <submit><!-- Go back to server to re-draw page with second option-->
    </noscript>
    <script>
    if (browser has enough capabilities) {
    document.write(other select elements)
    }
    else {
    document.write(submit button)
    }
    </script>
    ------------------------------------------------------------------------

    Do you see any problems with such a solution?

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 10, 2004
    #6
  7. Matt Kruse wrote:
    > Richard Cornford wrote:
    >> (though you will have to follow FAQ request procedure if you
    >> want it considered for the next review).

    >
    > Or maybe I'll just create a simple HTML page addressing the issue.
    > A lot of the same responses are posted to this group, not just for
    > this question, but for many others. It would be helpful to summarize
    > the responses into a single HTML page that users could be directed
    > to. Even if it's not in the official FAQ.


    You (and indeed anyone else who feels like it) are at liberty to create
    HTML pages for inclusion in the FAQ notes. Obviously the results would
    have to be subject to public review for accuracy, completeness and
    general suitability for inclusion (and subject to future editing if that
    was considered necessary as circumstances change).

    >> But what would the FAQ say on the subject: "Don't design this
    >> requirement into a project as it cannot be satisfactorily
    >> implemented."?

    >
    > No, it would point out a number of resources which solve the problem,


    If you could find such resources. But you define 'solution' as only
    relating to the mechanics of doing what can be done where it can be done
    with client-side scripting, while I think 'solution' includes the script
    design issues.

    > both with simple examples (storing options in arrays and simply
    > creating new Option objects) and complex solutions (like my library
    > and others).


    There is quite a lot of writing in that :)

    > It would also point out that there are potential problems with
    > relying on this functionality, explain why, and gives examples of
    > situations where this must be taken into consideration and situations
    > where it's not a concern.


    But are you in a position to give that information, even asses the
    criteria? It isn't a couple of weeks since you stated that you didn't
    think that the ADA applied to public commercial web sites in the US (and
    I don't really know if it does), but in a thread where the OP posted
    through a UK ISP it is the British DDA that is probably applicable.

    It is difficult to judge the scope of the DDA as currently there is none
    of the required legal precedents as the cases that have been brought to
    date have all been settled out of court (with the web site owners paying
    damages, but not admitting liability). And it will probably take the
    full appeals procedure to be applied (all the way to the European court)
    before anyone can be certain where accessibility is required from web
    sites. But the DDA has the potential (if enough judges eventually rule
    that way) to be as draconian as the Australian DDA, where I gather that
    every public web site is required to be accessible and so needlessly
    introducing javascript dependencies is actually likely to result in a
    fine for anyone (and a big fine for commercial enterprises). Making it
    an issue that Australian posters need to here about up front.

    And then there is the Internet/Intranet question. Over on alt.html at
    the moment there is a discussion started by an Australian developer who
    has used a javascript menu implementation in an Intranet project that
    inhibits the scaling of fonts (a common, but completely avoidable,
    feature of javascript menus). The problem is that an existing employee
    is 80% blind and cannot use the menu without scaling the fonts up (which
    the menu will not allow). The other Australian developers contributing
    to the thread are convinced their DDA does apply to that (and presumably
    other) Intranet project(s), at lest in part because it forbids an
    employer form discriminating against current and potential future
    employees on the grounds of disability. (The British DDA makes a
    similar requirement of employers, with some exceptions.)

    This seems to make determining the extent to which the introduction of a
    javascript dependency can be considered acceptable quite difficult to
    judge, with regional variations such that an Australian developer wants
    to avoid them, a British developer would be well advised to err on the
    side of caution (at least for the time being) and maybe US developers
    really don't have to think about it (beyond their personal morality).
    And then there is the rest of the world, where any country may have, or
    introduce, its own legislation on the subject.

    <snip>
    > When I get time to play with it, I'll build an example that degrades
    > nicely for you, using my library.
    > In short, it works like this:
    > ----------------------------------------------------------------------

    --
    > <select name="first" onchange="if (browser has enough capabilities) {
    > call dynamic population code }">
    > <noscript>
    > <submit><!-- Go back to server to re-draw page with second
    > option--> </noscript>
    > <script>
    > if (browser has enough capabilities) {
    > document.write(other select elements)
    > }
    > else {
    > document.write(submit button)
    > }
    > </script>
    > ----------------------------------------------------------------------

    --
    >
    > Do you see any problems with such a solution?


    NOSCRIPT is a block element so it cannot necessarily be inserted in any
    context without an impact on the resulting page flow.

    The second script element will probably not be in a position to properly
    test whether the browser is sufficiently dynamic to facilitate the
    client-side manipulation of the OPTIONs as that is only achievable by
    trying it and testing the results to see if it worked. Attempting that
    as the page loads will error, and even crash, some browser, from which
    there is no ability to recover and write the now needed submit button.

    This implementation would impose extra work on whoever was writing the
    server-side scripts as they not only have to populate your javascript
    data structures for the select list, but they also have to implement the
    server-side fall back (and ensure that the two interface styles make
    sense to the server-side code).

    Richard.
    Richard Cornford, Jun 10, 2004
    #7
  8. Continental Translations

    Matt Kruse Guest

    Richard Cornford wrote:
    >> No, it would point out a number of resources which solve the problem,

    > If you could find such resources. But you define 'solution' as only
    > relating to the mechanics of doing what can be done where it can be
    > done with client-side scripting, while I think 'solution' includes
    > the script design issues.


    You can't make everyone's decisions for them. If someone is looking for a
    technical solution, you provide them with a technical solution. It's up to
    them to decide if it fits. If they want consulting to know whether it's the
    best option, or if there are better ways to deliver content, then that's a
    different issue.

    When I go in to get a new muffler for my car, for example, I don't expect to
    have the salesman tell me why my car is a bad choice, and why I should be
    driving something else instead. That's outside the scope of the discussion.
    His job isn't to provide advice to me on whether or not I'm driving the
    right car. His job is to help me pick a muffler, make sure it works for my
    car, and put it on.

    Likewise, a provider of technical solutions should help pick the best
    solution, make sure it works, and provide implementation details. If the
    user's requirements are "this should work in all browsers anywhere" then
    that certainly changes the situation. If the user says "it only needs to
    work on IE6" then that may affect the solution selected.

    If you want to function as a consultant and tell people when various
    technologies should be used, and the good and bad of various design
    decisions, that's cool. There's a need for that. I'd rather focusing on
    providing technical solutions that can be implemented by people who have
    already decided that it's what they need. It's more fun. IMO.

    >> It would also point out that there are potential problems with
    >> relying on this functionality, explain why, and gives examples of
    >> situations where this must be taken into consideration and situations
    >> where it's not a concern.

    > But are you in a position to give that information, even asses the
    > criteria?


    Certainly.
    If your requirement is to support all browsers, even without javascript
    enabled, then you should do X.
    If only certain browsers are required to be supported, then you should do Y.
    If you require backwards-compatability, then you should do Z.

    It's up to the person implementing the site to determine what the
    requirements are. If they have to comply with some ADA or DDA rules, then
    they need to know that, and understand what restrictions that places on
    their choices. Then, armed with that knowledge, they can build their
    requirements and select the right tool.

    I'll never concern myself with what the ADA says or what the DDA says. I
    will simply say, "these are the limitations of this solution. If these
    aren't acceptable to you, then find a different solution."

    > And then there is the Internet/Intranet question. Over on alt.html at
    > the moment there is a discussion started by an Australian developer
    > who has used a javascript menu implementation in an Intranet project
    > that inhibits the scaling of fonts (a common, but completely
    > avoidable, feature of javascript menus).


    Then it's that web developer's fault for not understanding their true
    requirements, and finding a solution which fit them.
    It's certainly not the script author's fault for implementing something that
    doesn't fit someone else's requirements.

    > NOSCRIPT is a block element so it cannot necessarily be inserted in
    > any context without an impact on the resulting page flow.


    <style>
    noscript { display:inline; margin:0px; }
    </style>

    Even without css, so what?
    If a person has javascript disabled, they won't see as "pretty" of a page,
    but the functionality will still be there. That's what matters, right? The
    developer can decide how to design around such issues.

    > The second script element will probably not be in a position to
    > properly test whether the browser is sufficiently dynamic to
    > facilitate the client-side manipulation of the OPTIONs as that is
    > only achievable by trying it and testing the results to see if it
    > worked.


    Hmm.... if window.Option exists, and a call to it works, then an Option
    object can be created. In every browser that I know of, if I can create an
    Option object, I can add it to a select list. Except for Opera 5.? which has
    a bug. That could be checked as a special case with browser sniffing. By
    default, in case of any errors at all, the javascript mode could be turned
    off.

    Do you propose to _never_ add options to select lists? Because even
    attempting to do so and seeing if it works will fail in some browsers in
    some situations, in a way that cannot be trapped. You can't code for _every_
    situation. Buggy browsers should not be supported.

    > This implementation would impose extra work on whoever was writing the
    > server-side scripts as they not only have to populate your javascript
    > data structures for the select list, but they also have to implement
    > the server-side fall back (and ensure that the two interface styles
    > make sense to the server-side code).


    Now you're really reaching, Richard :)

    Sure, it may be more work, but your argument was that it's not possible -
    not that it was easy and quick.
    Lots of cool things are extra work. If a person wants this functionality on
    both server-side and client-side, then they can do the work.
    Besides, both client-side code and server-side code would surely work off
    the same back-end logic, so outputing the requirement script calls surely
    would not be as much work as you would make it seem.

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 10, 2004
    #8
  9. Matt Kruse wrote:
    > Richard Cornford wrote:
    >>> No, it would point out a number of resources which solve the
    >>> problem,

    >> If you could find such resources. But you define 'solution' as only
    >> relating to the mechanics of doing what can be done where it can be
    >> done with client-side scripting, while I think 'solution' includes
    >> the script design issues.

    >
    > You can't make everyone's decisions for them.


    I don't even try to make peoples decisions for them. But I do try to
    encourage the making of informed decisions.

    > If someone is looking for a technical solution,
    > you provide them with a technical solution.


    If someone is paying me for a technical solution then I do try to create
    the best technical solution that I am capable of, otherwise I would not
    be able to take any pride in my work.

    > It's up to them to decide if it fits.


    No, I would have said that it was up to them to come up with a
    specification first (though not necessarily on their own).

    > If they want consulting to know whether it's the best option,
    > or if there are better ways to deliver content, then that's a
    > different issue.


    Getting opinions on the best way of doing anything is an inevitable
    consequence of using Usenet. If people don't want that then they need to
    employ developers directly.

    But have you thought about how this notion sits with your suggestion
    that the individuals that employ javascript on their web sites should
    not be expected to have more than a rudimentary knowledge of javascript?
    How can someone with little knowledge of javascript make an informed
    decision about the relative quality and suitability of javascript
    implementations for any given context unless someone who has that
    knowledge tells them what needs to be considered?

    <snip>
    > His job is to help me pick
    > a muffler, make sure it works for my car, and put it on.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^
    See, you actually want a lot more than the abiity to demand something
    and just have it handed over regardless. You want the people who have
    technical skills to to bring them to the table if you don't have
    them.

    > Likewise, a provider of technical solutions should
    > help pick the best solution, make sure it works,
    > and provide implementation details.


    I don't have a problem with that in general, but helping to pick the
    best solution certainly should include things like advising on the
    appropriateness of the criteria.

    > If the user's requirements are "this should work in all
    > browsers anywhere" then that certainly changes the situation.


    There is a running theme in your posts where you describe the people who
    employ your javascript as "users". Given what you write I can see how,
    from your perspective, they are users; your users at least. But they are
    not users they are developers, designers, web site owners, and
    ultimately clients. The user is the person sitting in front of their
    browsers looking at the resulting web site. Making life easy for the
    clients you consider your users isn't necessarily doing any good for the
    real users.

    When you say that this "changes the situation" you are implying that a
    web site should not be expected to be functional on the Internet by
    default. I would have thought that would be the reverse of the normal
    client's expectations. My starting point would be to assume that a
    public web site was expected to operate to normal Internet
    interoperability standards by default and then examine the validity of
    any reasoning that suggested detracting from that. It should be the
    things that do introduce a dependency of some sort, such as data binding
    or socket communication through applets or ActiveX that change the
    situation.

    But no client would specify every web browser anywhere, and no sane
    developer would accept the requirement, because neither is capable of
    being aware what every web browser anywhere means. There would be no way
    to know if the result met that requirement and so no way of deciding if
    and when the job was finished (for either party).

    A specification of a list of browsers with which a commission will
    function can be looked upon as a specification of test criteria that can
    be used to determine that the delivered end result confirms with the
    specification. But the Internet was designed around interoperability and
    normal authoring principles, the application of suitable standard and
    appropriate design can deliver a result that works (and should be
    expected to work, even if that could not be made a specified
    requirement) with browsers outside of the test set.

    > If the user says "it only needs to work on IE6" then
    > that may affect the solution selected.


    When a specification says that something only needs to work on IE 6 it
    means that it only needs to be demonstrated to be working on IE 6, it
    doesn't mean that it must not work on any other browser, and it does not
    mean that it only has to work on javascript enabled default
    configurations of IE 6 either.

    Anything that will cope with all configuration
    permutations of IE 6 could be implemented in a way
    that would work pretty much the same on all dynamic standards
    compliant browsers (at minimum) for no additional effort in
    script creation. Under those circumstances, and given a non-Intranet
    application, it looks like the initial specification was not well
    informed, or it was chosen for convenience in testing.

    > If you want to function as a consultant and tell people when
    > various technologies should be used, and the good and bad of
    > various design decisions, that's cool. There's a need for that.


    There is a need for that.

    > I'd rather focusing on providing technical solutions that
    > can be implemented by people who have already decided that it's
    > what they need. It's more fun. IMO.


    I could churn out javascript dependent half-ass hacks till the cows come
    home, any fool could. But to implement a script such that it meets the
    strictest design criteria, addresses and handles all of the issues,
    exhibits planned behaviour in the face of every permutation of browser
    environment and do so on a time scale equivalent to any less complete
    'solution', that is a challenge. And for me a challenge is more fun.

    Not to mention that you learn more from being challenged than from going
    over the same ground time and again. Two years ago I was writing scripts
    much like you write now, and I thought I know what I was doing, but at
    least when I was introduced to the issues in browser scripting I was
    willing to recognise them an learn to handle them. Your complacency is
    going to mean that in two years time you are going to still be writing
    scripts much as you do now, and continuing to contribute towards making
    the Internet a worse place than it has to be.

    >>> It would also point out that there are potential problems with
    >>> relying on this functionality, explain why, and gives examples of
    >>> situations where this must be taken into consideration and
    >>> situations where it's not a concern.

    >> But are you in a position to give that information, even asses the
    >> criteria?

    >
    > Certainly.
    > If your requirement is to support all browsers, even without
    > javascript enabled, then you should do X.
    > If only certain browsers are required to be supported, then you
    > should do Y. If you require backwards-compatability, then you should
    > do Z.


    And you accuse me of trying to fit everything into a box that I am
    comfortable with. This is hardly a comprehensive list of web site design
    requirements, but if X is normal internet authoring with
    interoperability as the goal it must also satisfy Y under most
    circumstances and Z much of the time.

    > It's up to the person implementing the site to determine what the
    > requirements are.


    Who is the "person implementing the site"? The owner of the site, their
    business managers, the project manager, the designer, the developers?
    Aren't the requirements going to be hierarchical? Is a business manager
    expected to comprehend the distinction between an unnecessary dependency
    and an unavoidable one, or a designer the best person to be choosing a
    menu implementation (rather than just deciding what it should look like
    when implemented)? Shouldn't design be a collaborative process moving
    through stages from the general to the specific, with the input form the
    top of the decision making hierarchy maybe diminishing and the input
    from the bottom end increasing as the process moves toward completion?

    <snip>
    >> And then there is the Internet/Intranet question. Over on alt.html at
    >> the moment there is a discussion started by an Australian developer
    >> who has used a javascript menu implementation in an Intranet project
    >> that inhibits the scaling of fonts (a common, but completely
    >> avoidable, feature of javascript menus).

    >
    > Then it's that web developer's fault for not understanding their
    > true requirements, and finding a solution which fit them.


    The web developer certainly could have done better in that area. But
    there is your problem again, web developers don't necessarily have the
    skills to judge every aspect of what they are asked to do. They may know
    everything that can be known about their own specialisation and next to
    nothing about another. This individual seemed mostly concerned with
    server-side scripting, but that wouldn't equip him to judge a javascript
    implementation or comprehend the impact on accessibility that followed
    from the HTML/CSS employed by that script.

    > It's certainly not the script author's fault for implementing
    > something that doesn't fit someone else's requirements.


    But the script author was utterly misguided in creating a script for use
    in a browser environment that detracted from the usability of that
    browser for no apparent reason. Though in practice I have no doubt that
    the actual reason was an ignorance of how to do any better.

    Browsers have characteristics and scripts for use in browsers should
    take those into account. Fonts can be scaled to suite the user, that
    isn't a secret it is right there in the menus for anyone to see.

    Then again the script author may have known that the menu could be
    implemented flexibly but didn't care to learn to do any better and just
    offered the script up on a take it or leave it basis, and the developer,
    not knowing what criteria to apply to the choice of menu script, used it
    because it was there.

    That happens a lot, people who don't know any better lumber themselves
    with problems by choosing inappropriate scripts because those scripts
    are easy to find. Not knowing what they have done until a problem
    manifests itself and then not knowing what to do about it. Assuming the
    consequence of the use of a poor script has an observable manifestation,
    which might not be the case when, say, a needless javascript dependency
    is reducing turnover for a small business site as there will be not
    turnover figures without the dependency against which a comparison could
    be made.

    <snip>
    > Hmm.... if window.Option exists, and a call to it works, then an
    > Option object can be created. In every browser that I know of, if I
    > can create an Option object, I can add it to a select list. Except
    > for Opera 5.? which has a bug. That could be checked as a special
    > case with browser sniffing. By default, in case of any errors at all,
    > the javascript mode could be turned off.
    >
    > Do you propose to _never_ add options to select lists? Because even
    > attempting to do so and seeing if it works will fail in some browsers
    > in some situations, in a way that cannot be trapped.


    I have told you before, you start off with the OPTIONs defined in the
    HTML and you test the dynamism of the browser by trying to remove them.
    Then a worst case failure leaves those OPTIONs available to the user.
    The same goes for the submit button, define it in the HTML and
    conceal/remove it with a script and the whole implementation is much
    simpler and no longer has any path that will leave the user without the
    ability to use the form.

    It is defining data/content for a script in any place other than
    on the HTML page that is directly responsible for *needlessly*
    introducing javascript dependency in the vast majority of scripts
    that suffer from it. And it is a design decision, not something that
    follows from the use of javascript as such.

    > You can't code for _every_ situation.


    I can try.

    > Buggy browsers should not be supported.


    Is there (or has there ever been) a single web browser that does not
    have a bug?

    All you are saying is that if a bug cannot be handled by your scripts as
    you design them then it is the browser's fault, bugs your scripts can
    cope with you don't consider a problem but that does not mean they are
    not there (or are not bugs).

    >> This implementation would impose extra work on whoever was writing
    >> the server-side scripts as they not only have to populate your
    >> javascript data structures for the select list, but they also have
    >> to implement the server-side fall back (and ensure that the two
    >> interface styles make sense to the server-side code).

    >
    > Now you're really reaching, Richard :)
    >
    > Sure, it may be more work, but your argument was that it's not
    > possible - not that it was easy and quick.


    No, I think you will find that I said "it cannot be satisfactorily
    implemented", which is not the same as impossible, and certainly does
    include a consideration of how many hoops have to be jumped through in
    order to implement it.

    > Lots of cool things are extra work. If a person wants this
    > functionality on both server-side and client-side,
    > then they can do the work.


    Which was my point. If they do it exclusively on the server these is no
    extra work, and if they use a client-side implementation that degrades
    there is no extra work (even if the degraded interface is not that
    usable in this instance), but if they use a javascript dependent
    implementation, and want reliability, they have to put work in to
    compensate for the script.

    A design that lumbers someone else with extra work to compensate for its
    shortcoming is not a good design. In a team context designing scripts to
    minimise the effort needed for their employment by server-scripting
    colleagues is the best plan. And that is easiest achieved by having the
    scripts manipulate the HTML (and get their date from the HTML) because
    server scripting is optimised for the creation of HTML and the people
    doing it know how to understand and write out HTML. While presenting
    them with new and complex javascript data structures to learn and
    assemble on the server is unpopular, error prone and a sure way of
    needlessly introducing javascript dependencies.

    Designs based around the manipulation of HTML page content also offer
    easy paths of clean degradation, and consequentially facilitate
    reliability in the face of any browser environment.

    > Besides, both client-side code and server-side code would surely work
    > off the same back-end logic, so outputing the requirement script
    > calls surely would not be as much work as you would make it seem.


    Above a certain level they are the same, but the specific form input
    handling is very different. In a standard form handling script the input
    from the HTTP request is validated and if it validates it is processed
    and some sort of result response is generated, and if invalid it is
    returned to the user for correction. You plan adding the handling of
    partly completed form data and the construction of incremental stages in
    the multiple selection.

    The handler still has to do what it would have done otherwise but now it
    is also interested in the user's current stage in the selection process
    and re-assembling the party completed form to be returned to the user,
    and it has to know at which point the form is finished so it can do the
    validation instead. And if the form doesn't validate it is going to have
    to handle the possibility that the user may want to change the
    selection.

    It is trivial to implement a progressive selection as a wizard style
    interface with back and forward options but doing it all in one big
    handler for a form introduces quite a lot that needs additional thought.
    Plus the turnaround on the server would be slower if the whole form was
    going back and forth each time.

    Richard.
    Richard Cornford, Jun 11, 2004
    #9
  10. Continental Translations

    Matt Kruse Guest

    Richard Cornford wrote:
    > Two years ago I was
    > writing scripts much like you write now


    (first of all, much of the content of my site is not what I'm writing "now",
    but has been there for a while... the latest addition was the DHTML tree,
    which surely follows your design ideals)

    > but at least when I was introduced to the issues in
    > browser scripting I was willing to recognise them an learn to handle
    > them. Your complacency is going to mean that in two years time you
    > are going to still be writing scripts much as you do now, and
    > continuing to contribute towards making the Internet a worse place
    > than it has to be.


    Oh blah, Richard, your mantra bores me.
    Considering that some of my code has been used by smany very major web sites
    around the world, and my libraries have been useful to literally thousands
    of web sites and saved the butts of many behind-schedule web developers, I
    think you're being over-dramatic.

    As with anything a person does over time, my skills have developed and I
    could certainly now develop anything that you or anyone else could. I just
    implemented a very slick UI using all DOM stuff that works beautifully in
    all current browsers and even degrades nicely back to NN4. You'd be proud!
    But unfortunately it's for a private webapp. :)
    When I finish putting up content at http://www.javascripttoolbox.com/ then
    I'll welcome your revised comments, because the code there will be more
    representative of my current skills, and most certainly more in line with
    your ideals. But as with most people with a family and kids, it's tough to
    find time to even keep a web site current with new and better ways of doing
    things! I know some problems in the scripts that are on my site, and I know
    how to make them better and more robust, but I just don't have the time to
    do so. Yet.

    So quit the condescending crap. If you were offering up a bunch of solutions
    for thousands of developers around the world to use and benefit from, and it
    was always up-to-date and representative of the best coding ideals, then you
    might be able to criticize. Offering theory - as you usually do - is much
    _much_ _MUCH_ easier than maintaining a web site of examples, code, support,
    and documentation.

    > That happens a lot, people who don't know any better lumber themselves
    > with problems by choosing inappropriate scripts because those scripts
    > are easy to find.


    Would it not make sense for you to then offer "better" solutions so that
    they can become popular and used everywhere?
    I'm not sure you should be condemning users who offer solutions (and opening
    themselves up to criticism) when you aren't prepared to offer any better
    replacements. Telling the world that they are doing something wrong doesn't
    carry much weight when you don't supply something better.

    > I have told you before, you start off with the OPTIONs defined in the
    > HTML and you test the dynamism of the browser by trying to remove
    > them.


    a) This will not always work. I would _love_ for you to demonstrate this in
    a cross-browser way that degrades nicely and doesn't break in any browsers.

    b) The concept of "draw plain html and then go back and make it into fancy
    dhtml" is good in theory, but not always in reality. I've had a number of
    users complain that the screen is drawn, then "snaps" into place with a
    better interface. "Why does the screen jump like that? Can you fix it?".
    Things like changing a <ul> into a dhtml tree is different, because the same
    structure is there. The page contents don't change drastically.

    >> You can't code for _every_ situation.

    > I can try.


    Good luck!

    >> Buggy browsers should not be supported.

    > Is there (or has there ever been) a single web browser that does not
    > have a bug?


    No, of course not.
    But if you're coding for dynamic select lists, and you know that Opera 5.02
    can create Option objects but not add them to select lists, then that's a
    very specific bug. Users of that browser should see things break, because
    that's a big problem that cannot be reasonably tested for. In those
    situations, I think it's better to inform the user that their browser sucks
    then to change the whole way that a script functions to support the broken
    browser.

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 11, 2004
    #10
  11. Continental Translations

    Grant Wagner Guest

    Matt Kruse wrote:

    > Richard Cornford wrote:
    >
    > > but at least when I was introduced to the issues in
    > > browser scripting I was willing to recognise them an learn to handle
    > > them. Your complacency is going to mean that in two years time you
    > > are going to still be writing scripts much as you do now, and
    > > continuing to contribute towards making the Internet a worse place
    > > than it has to be.

    >
    > Oh blah, Richard, your mantra bores me.
    > Considering that some of my code has been used by smany very major web sites
    > around the world, and my libraries have been useful to literally thousands
    > of web sites and saved the butts of many behind-schedule web developers, I
    > think you're being over-dramatic.


    And I've gotten a bit bored of your on-going desire to get the upperhand on
    Richard. It's not going to happen, he is much more level-headed and presents
    better arguments in a more informed manner. He does not resort to hyperbole
    about "thousands of developers world-wide". Millions of people world-wide smoke
    cigarettes too, it doesn't mean it's a good idea.

    Even if you could provide audited logs proving your case, it would say nothing
    about the quality of your work.

    You've presented your code examples, you've made your opinions clear, you've
    lost, move on.

    --
    | Grant Wagner <>

    * Client-side Javascript and Netscape 4 DOM Reference available at:
    *
    http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

    * Internet Explorer DOM Reference available at:
    *
    http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

    * Netscape 6/7 DOM Reference available at:
    * http://www.mozilla.org/docs/dom/domref/
    * Tips for upgrading JavaScript for Netscape 7 / Mozilla
    * http://www.mozilla.org/docs/web-developer/upgrade_2.html
    Grant Wagner, Jun 11, 2004
    #11
  12. JRS: In article <caadvu$7hl$1$>, seen in
    news:comp.lang.javascript, Richard Cornford
    <> posted at Thu, 10 Jun 2004 20:49:16 :

    >It is difficult to judge the scope of the DDA as currently there is none
    >of the required legal precedents as the cases that have been brought to
    > ...
    >And then there is the rest of the world, where any country may have, or
    >introduce, its own legislation on the subject.


    That's all rather legalistic.

    By DAA, ADA, etc., Governments have formally recognised that those with
    disabilities should not be disadvantaged where that can reasonably be
    avoided.

    But this has been known since Man's ancestors first became near-human;
    although not always implemented.

    The legal requirements should be considered as indicating a bare minimum
    standard - though they also provide a tool that should be usable in
    reasonable safety when attempting to persuade an obdurate
    employer/client of the errors of his wishes - and authors/designers
    should endeavour to provide a maximum of accessibility to all of the
    target readership, whether or not they are formally recognised as
    disabled.


    Perhaps interested organisations should provide - and advertise - a
    defaults-test page.

    This page would be free of CSS (but should have <big> <small> <pre> and
    default of each of the prime families of fonts, e.g. monospace), and
    should strongly assert that :-

    * it should be comfortably readable to most people using a normally set-
    up browser on default or medium settings,
    * people with minor disabilities should adjust their browser defaults to
    make it comfortably readable,
    * other people should seek browsers or other assistance appropriate to
    their condition, in order to make the material as accessible as
    possible;

    and that, the above having been done, all material on the Web ought to
    be accessible to them (except as unavoidably prevented by their
    condition), and that if it is not the blame lies squarely with the page
    provider.


    The above doubtless needs adjustment; but it should give the general
    idea.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://jibbering.com/faq/> Jim Ley's FAQ for 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 11, 2004
    #12
  13. Continental Translations

    Matt Kruse Guest

    Grant Wagner wrote:
    > And I've gotten a bit bored of your on-going desire to get the
    > upperhand on Richard. It's not going to happen, he is much more
    > level-headed and presents better arguments in a more informed manner.


    Well, I disagree, because he _consistantly_ fails to provide examples of his
    ideas in action (all theory, no code).
    He consistantly refuses to discuss specific things he finds wrong in any of
    my code.
    He consistantly ignores the fact that not everyone is designing in an
    internet mode, supporting a wide scope of browsers.

    And seriously, if he thinks he is correct in his opinions on the useage of
    javascript on public web sites, I think he needs to look around the web a
    bit. Some hugely popular sites employing many people who are surely at least
    as intelligent as Richard have chosen to do things that conflict with his
    design ideals. The world is not black-and-white. Just because someone
    disagrees with his ideas does not mean they are wrong or less intelligent.

    I'm tired of his continued posts saying things are not done correctly, when
    he offers no technical criticisms at all. When asked to do so, he refuses.
    He's all talk.

    > He does not resort to hyperbole about "thousands of developers
    > world-wide". Millions of people world-wide smoke cigarettes too, it
    > doesn't mean it's a good idea.


    That's completely unrelated. And not a hyperbole at all.

    It's similar to the linux-freaks who bash microsoft on a regular basis,
    pointing out how badly Windows handles a lot of things. In many cases,
    they're right. But so what? Millions of people use Windows every day and it
    fits their needs perfectly and enables them to work better. Just because
    Windows isn't perfect doesn't mean it has no value, or that its use should
    be discouraged. Quite the opposite.

    Similarly, my point is this - if some of my libraries are used by thousands
    of developers, and they find value in them, and there are a couple of people
    who say "yeah, but that's not the ideal way to do it!"... so what? Are those
    nay sayers adding the same value in ways that they find to be correct, or
    are they just whining?

    > Even if you could provide audited logs proving your case, it would
    > say nothing about the quality of your work.


    My point is, it's peer-reviewed. Lots of web developers use the code, and it
    solves their problems. Nothing is perfect, and I don't claim that anything
    of mine is. Obviously, not _every_ peer agrees with it.

    But I don't put much weight in theories and opinions expressed by an
    extremely negative guy whose goal in life seems to be to tell people why
    they are stupid and doing things the wrong way, yet not providing his "good"
    solutions up for the world to use, review, and criticize. If there are
    better ways to do what my code does, then by all means DEMONSTRATE IT.

    But the response to that often is, "well, you shouldn't be doing that at
    all." Which is a view from Utopia. I'm sure there are countless developers a
    day who receive the requirement of "there should be a popup calendar to pick
    a date". You or Richard may say that's a stupid requirement that shouldn't
    be implemented, but that doesn't change the fact that there are lots of
    people who WILL implement it because they DO need it. If I supply a great
    solution that they can plug in without spending hours of work developing it
    from scratch, I've added value. And that's bad?

    > You've presented your code examples, you've made your opinions clear,
    > you've lost, move on.


    heh, you can have that opinion, that's fine... but the emails I get, the
    places I see my code used, and the daily donations I receive lead me to a
    different conclusion ;)

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 11, 2004
    #13
  14. Matt Kruse wrote:

    Hi,

    > Well, I disagree, because he _consistantly_ fails to provide examples of his
    > ideas in action (all theory, no code).


    If you want to see some of his scripts, try looking at the website he's
    posting from, or search his posts in the comp.lang.javascript archives
    (there are many lengthty interesting pieces of code).

    > And seriously, if he thinks he is correct in his opinions on the useage of
    > javascript on public web sites, I think he needs to look around the web a
    > bit. Some hugely popular sites employing many people who are surely at least
    > as intelligent as Richard have chosen to do things that conflict with his
    > design ideals.


    That's unfortunately true, but did they really have the choice? IMHO
    they just didn't know any better, web scripting has never been
    considered a serious matter and they've never taken the time to
    understand the context or the language.

    Since you're in contact with many professionals, test by yourself: how
    many have read and understood the ECMA-262v3 specification? How many are
    aware of functional programming in javascript (closures)? How many are
    able to use advanced javascript OO-based patterns (using private static
    members for instance)? How many have read and understood the relevant
    W3C specs (DOM Core, DOM Events, DOM Traversal & Ranges, HTML4.0,
    CSS2.1)? Have they read and experienced accessibility guidelines?


    You're posting in comp.lang.javascript, with regulars who have spent
    countless hours on the specs, who have written thousands (and probably
    millions) lines of javascript, testing, twisting the language,
    elaborating and applying endlessly design patterns - people who love
    javascript and therefore have the highest expectations. Now it's
    certainly true that some of the opinions expressed here are "black or
    white", but that's because they take into account every aspect to build
    the _best_ application - there's no toning down quality for bad reasons.

    Richard's teasing on your posts has probably the only goal to have you,
    a definitely skilled programmer, reach the highest levels.


    Regards,
    Yep.
    Yann-Erwan Perio, Jun 12, 2004
    #14
  15. Matt Kruse wrote:
    > Richard Cornford wrote:
    >> Two years ago I was
    >> writing scripts much like you write now

    >
    > (first of all, much of the content of my site is not what I'm writing
    > "now", but has been there for a while... the latest addition was the
    > DHTML tree, which surely follows your design ideals)


    I had assumed that the in-window pop-up code that you recently posted
    the URL of was contemporary, as your comments and its appalling
    behaviour on Opera 7 gave it the air of a work in progress. I did think
    that not taking the opportunity to define the contents of the pop-ups
    (at least the non-IFRAME ones) in the HTML on the page was retrograde
    after your DHTML tree, but as you have repeatedly express a belief that
    needlessly introducing javascript dependencies has no significance that
    didn't strike me as out of character.

    <snip>
    > Considering that some of my code has been used by smany very major
    > web sites around the world, and my libraries have been useful to
    > literally thousands of web sites and saved the butts of many
    > behind-schedule web developers, I think you're being over-dramatic.


    As you have decided to raise this weight of numbers/deployed on real web
    sites thing again (when I thought that the reason you did not pursue the
    argument last time was that you had spotted how hollow it was) it is
    probably worth examining its merits.

    The implications of the argument are:-

    1. The act of deploying a script on a web site (and/or the
    fact that it has been chosen by someone for deployment),
    in itself, imbues that script with some additional "worth"
    (value, measure of standard/quality or whatever).

    2. That additional "worth" is proportional to the number of
    instances of the deployment of that script (possibly
    weighted by the size, importance, popularity, profitability,
    or whatever, or the web sites on which it is used).

    It doesn't take much examining of web sites, or knowledge of web site
    development, to realise that there is one clear contender for the most
    widely used scripts; from the smallest web sites to the largest, by at
    least an order of magnitude, the most popular deployed scripts worldwide
    are the javascript functions output by Macromedia Dreamweaver.
    Dreamweaver functions are so popular that you will often see the same
    one defined two or three times on the same page.

    So by this measure of quality MM_findObj, MM_swapImage,
    MM_swapImgRestore and their friends, are the pinnacle of browser
    scripting.

    However, the opinion of the Dreamweaver functions most widely expressed
    on this group is that they are among the worst scripts ever written and
    would be best used to illustrate how not the write javascript. Indeed I
    have only ever seen one comment in favour of the Dreamweaver functions
    and that stressed nothing but how general they are. A characteristic
    that directly results in them being inefficient, which invariably
    features in the list of arguments against them.

    When a measure of "worth" ranks scripts that informed opinion denigrates
    so heavily above all others that criteria cannot be a measurement of
    script quality.

    <snip>
    > So quit the condescending crap. If you were offering up a bunch of
    > solutions for thousands of developers around the world to use and
    > benefit from, and it was always up-to-date and representative of the
    > best coding ideals, then you might be able to criticize.


    By which you are saying that my opinion has no value unless I adopt your
    approach to javascript authoring and start doing what you have chosen to
    do. But my opinion is that your approach is misguided, so I could not be
    expected to adopt it.

    To only accept criticism about your approach from people who follow your
    approach is one way of disregarding criticism, but it lacks any
    reasonable foundation.

    > Offering theory - as you usually do - is much _much_
    > _MUCH_ easier than maintaining a web site of examples,
    > code, support, and documentation.


    What you see as theory I regard as explanation. I don't see the
    distribution of even the very best generalised javascript libraries as
    the solution to the lamentable current state of Internet browser
    scripting. I perceive promoting an understanding of browser scripting as
    a practice, its issues and javascript as a language as much more likely
    to have a positive impact in that area. Understanding is best promoted
    through explanation.

    If you see an explanation of the possibilities as theory then that is a
    matter of perception. It doesn't matter that you do; theories can be
    refuted if they are wrong, so feel free to refute if you can. Though
    bare in mind that if I really am posting speculative nonsense with no
    hope of implementation then the fact that I am posting it on Usenet
    would normally mean that someone would nave noticed and publicly
    criticised me for it (that is what happens on Usenet, as you must have
    observed given that you have complained about it).

    >> That happens a lot, people who don't know any better lumber
    >> themselves with problems by choosing inappropriate scripts
    >> because those scripts are easy to find.

    >
    > Would it not make sense for you to then offer "better" solutions
    > so that they can become popular and used everywhere?


    That wouldn't help much as giving someone who doesn't know what criteria
    to apply to the choice something else to choose from only fractionally
    increases the chances of an appropriate outcome (assuming it is a
    "better" choice). While making them aware of the criteria they should be
    applying to that choice significantly increases their chances of making
    the right one.

    > I'm not sure you should be condemning users who offer solutions


    "Users who offer solutions"? You mean developers?

    > (and opening themselves up to criticism) when you aren't
    > prepared to offer any better replacements. Telling the
    > world that they are doing something wrong doesn't carry much
    > weight when you don't supply something better.


    When public script collection copy-n-paste is so bad, and bloated
    generalised libraries little better, being supplied "something better"
    is a matter of employing someone who knows what they are doing to work
    on a specific problem. I cannot work on everyone's specific problems,
    but I can try to increase the chances that whoever does knows what they
    are doing.

    >> I have told you before, you start off with the OPTIONs defined in
    >> the HTML and you test the dynamism of the browser by trying to
    >> remove them.

    >
    > a) This will not always work.


    Whether it will always work isn't practical to judge, but the mere fact
    that the OPTIONs start off in the SELECT elements on the page massively
    increases the chances that they will be available to the user in the
    event of script failure or lack of browser support over any
    implementation that defines the data for the OPTIONs in a javascript
    data structure.

    > I would _love_ for you to demonstrate
    > this in a cross-browser way that degrades nicely and
    > doesn't break in any browsers.


    You found a browser on which the version of mine that you have seen
    didn't display its degraded interface when it failed act dynamically?

    > b) The concept of "draw plain html and then go back and make it into
    > fancy dhtml" is good in theory, but not always in reality. I've had a
    > number of users complain that the screen is drawn, then "snaps" into
    > place with a better interface. "Why does the screen jump like that?
    > Can you fix it?". Things like changing a <ul> into a dhtml tree is
    > different, because the same structure is there. The page contents
    > don't change drastically.


    A browser that tries to render progressively can do that with pure
    HTML/CSS (particularly when float:right|left are used). It is a long way
    form being unaddressable.

    <snip>
    >>> Buggy browsers should not be supported.


    >> Is there (or has there ever been) a single web browser that does not
    >> have a bug?

    >
    > No, of course not.


    So no browser should be supported? (that will cut down the workload :)

    > But if you're coding for dynamic select
    > lists, and you know that Opera 5.02 can create Option objects
    > but not add them to select lists, then that's a very specific bug.
    > Users of that browser should see things break, because that's a
    > big problem that cannot be reasonably tested for.
    > In those situations, I think it's better to
    > inform the user that their browser sucks then to change the
    > whole way that a script functions to support the broken browser.


    From the point of view of a script a browser that does not support a
    particular feature (be it through a bug or otherwise) is not any
    different from a browser that does not support scripting at all. If
    scripts are designed to degrade cleanly then they can cope with any sort
    of failure by doing what they would do on a javascript
    incapable/disabled browser.

    It is not a matter of supporting buggy browsers as such; the script
    cannot do what it was designed to actively do, but it can cleanly
    degrade.

    Are you actually saying that Opera 5.02 will allow OPTIONs to be removed
    from a SELECT element and new Options to be created but it will not
    allow them to be added to a SELECT element? That would be a very
    specific bug, but completely amenable to feature detection.

    Richard.
    Richard Cornford, Jun 12, 2004
    #15
  16. Continental Translations

    Matt Kruse Guest

    Richard Cornford wrote:
    > I had assumed that the in-window pop-up code that you recently posted
    > the URL of was contemporary


    I don't recall the URL.

    > as your comments and its appalling
    > behaviour on Opera 7 gave it the air of a work in progress.


    If you're referring to the popup window script, it certainly was a work in
    progress, and the issues with Opera were/are known.
    I've since decided to use a different approach to the whole concept. The
    code was more "test of concept" than anything.

    > 1. The act of deploying a script on a web site (and/or the
    > fact that it has been chosen by someone for deployment),
    > in itself, imbues that script with some additional "worth"
    > (value, measure of standard/quality or whatever).


    It does. Anything that is used successfully by many people has more value
    than a solution used by no one. I suppose that depends entirely on how you
    define 'value'. But to me, getting a job done, meeting requirements, and
    benefitting from work done is a sign of value. The "Pet Rock" surely had no
    value in and of itself. But as soon as millions of people wanted one, it had
    incredible value to those buying it and those profiting from it.

    > 2. That additional "worth" is proportional to the number of
    > instances of the deployment of that script (possibly
    > weighted by the size, importance, popularity, profitability,
    > or whatever, or the web sites on which it is used).


    True again. The more something is used, the more valuable it is to more
    people. Usually.

    > So by this measure of quality MM_findObj, MM_swapImage,
    > MM_swapImgRestore and their friends, are the pinnacle of browser
    > scripting.


    Quality != Value
    The dreamweaver scripts may not be high quality in terms of coding, but they
    certainly have added incredible value for a number of people who simply
    couldn't have done anything dynamic without them.

    A solution does not need to be perfect to have value.

    Go into any consumer market for a quick lesson in this fact. Things don't
    always make sense. People will sometimes prefer lower-quality solutions in
    favor of more convenience, lower price, faster delivery, etc, etc. You are
    implying that a solution which is not technically ideal is always less
    valuable than a solution which follows all the technical ideas. But this
    idea is clearly absurd!

    To a new html author making a web site for their dog, adding image swapping
    with a few clicks of a button is fantastic! Even if it's not technically the
    best solution, they don't care. Even if there are better ways to do it, they
    don't care. Even if it will break in 5% of their visitors' browsers, they
    don't care. Your assumptions about how value is determined does not apply to
    everyone. Even if you think they should.

    > When a measure of "worth" ranks scripts that informed opinion
    > denigrates so heavily above all others that criteria cannot be a
    > measurement of script quality.


    Again, don't confuse value (worth) with quality.
    The most technically-superior solutions are rarely the most popular or
    valuable to most people.

    > If you see an explanation of the possibilities as theory then that is
    > a matter of perception. It doesn't matter that you do; theories can be
    > refuted if they are wrong, so feel free to refute if you can.


    Here you go... your "solutions" are often ugly and unacceptable to some
    people who are writing the checks.
    In your "ideal" world where theories and explanations are all that need be
    discussed, this doesn't matter much to you. But in the real world (which I
    deal with, and which you continually ignore) it's a big factor.

    > bare in mind that if I really am posting speculative nonsense with no
    > hope of implementation then the fact that I am posting it on Usenet
    > would normally mean that someone would nave noticed and publicly
    > criticised me for it


    Not necessarily. Many choose not to express themselves in public. I've
    received emails with varying points of view on our discussions. :)
    I don't take any of this personally (in fact, I think I benefit from having
    ideas challenged and challenging those of others) so it doesn't both me to
    post publicly. But not everyone is like that.

    > When public script collection copy-n-paste is so bad, and bloated
    > generalised libraries little better, being supplied "something better"
    > is a matter of employing someone who knows what they are doing to work
    > on a specific problem.


    In a perfect world, maybe. In the real world, this isn't even always
    possible.

    > From the point of view of a script a browser that does not support a
    > particular feature (be it through a bug or otherwise) is not any
    > different from a browser that does not support scripting at all.


    That is completely untrue.
    Sometimes bugs cannot be found or worked around via feature detection.
    If calling alert() for example would crash browser X, how could you
    possiblly test for that, or have it degrade gracefully for such a browser?

    > Are you actually saying that Opera 5.02 will allow OPTIONs to be
    > removed from a SELECT element and new Options to be created but it
    > will not allow them to be added to a SELECT element? That would be a
    > very specific bug, but completely amenable to feature detection.


    That is exactly what I have observed.
    See this url in Opera 5.02:
    http://www.mattkruse.com/temp/opera_options_test.html

    If you can detect that the first and second links will work, but not the
    third, using only feature detection, I would like to see it. I've not come
    up with a good way to test for it, other than actually doing it and seeing
    if it works.

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 13, 2004
    #16
  17. Matt Kruse wrote:
    > Grant Wagner wrote:

    <snip>
    >> ... Millions of people world-wide smoke cigarettes too,
    >> it doesn't mean it's a good idea.

    >
    > That's completely unrelated. And not a hyperbole at all.
    >
    > It's similar to the linux-freaks who bash microsoft on a regular
    > basis, pointing out how badly Windows handles a lot of things. In
    > many cases, they're right. But so what? Millions of people use
    > Windows every day and it fits their needs perfectly and enables them
    > to work better. Just because Windows isn't perfect doesn't mean it
    > has no value, or that its use should be discouraged. Quite the
    > opposite.


    You are saying - if many use then good - (a theory), Grant is
    observing - bad (NOT good) AND many use -, and deducing - NOT <if many
    use then good> - (as the (empirical) observation refutes the theory).
    You are then representing that as - if many use then bad (NOT good) -
    and/or - if few (NOT many) use then good -. Which are rhetorical
    derivations (a "straw man" argument) not logical ones.

    > Similarly, my point is this - if some of my libraries
    > are used by thousands of developers, ...

    <snip>
    > ... . I'm sure there are countless
    > developers a day who receive the requirement of "there should be a
    > popup calendar to pick a date". You or Richard may say that's a
    > stupid requirement that shouldn't be implemented, but that doesn't
    > change the fact that there are lots of people who WILL implement it
    > because they DO need it.

    <snip>

    I have no recollection of Grant ever expressing an opinion on pop-up
    calendar date pickers. And I have never said they shouldn't be
    implemented, I actually think they can represent a potentially useful
    enhancement to a browser based GUI (for some users).

    I do think that their design should address a number of issues; starting
    with the normal clean degradation issue. If they represent the only
    means of entering the required information then the result is javascript
    dependent, but if they are implemented to, say, activate when a user
    clicks on a date entry field in a form, and act as a quick alternative
    means of entering that information (appropriately formatted, etc) then
    script failure does not deny the user the possibility of entering the
    required date.

    They are also a very pointing device orientated means of entering a
    date. Which is why I described them as an enhancement for some users
    (the ones using pointing devices as their primary means of interaction
    with the browser; the majority) and why I would only propose activation
    on a mouse click (rather than say onfocus) as that implies the pointing
    device with which the pop-up calendar makes sense. A user who is tabbing
    through a form using the keyboard is probably not going to want to
    switch to the mouse to enter data, and providing clean degradation also
    facilitates direct keyboard data entry into the fall-back HTML field(s).

    Then again, the implementation might attempt to facilitate keyboard
    navigation of the calendar GUI (Web Content Accessibility Guidelines
    1.0 - 'AA' conformance already requires that (6.4, 9.3) and Web Content
    Accessibility Guidelines 2.0 - 'A' conformance looks like it will
    require it (2.1)), but tabbing through 30-odd days in a month is
    probably more work than typing in the date directly (even if split
    across 3 fields).

    There is of course also the reliability issue when 'pop-up' means 'new
    browser window' that results from the use of pop-up blockers, and the
    display issues surrounding the combination of positioned DIV elements
    and form fields that would arise for in-window pop-up implementations.

    But they are all issues that can be addressed (one way or another) in an
    implementation to produce a potentially useful cross-browser enhancement
    to an HTML form.

    Richard.
    Richard Cornford, Jun 13, 2004
    #17
  18. Dr John Stockton wrote:
    > Richard Cornford wrote:
    >
    >>It is difficult to judge the scope of the DDA as currently there is
    >>none of the required legal precedents as the cases that have been
    >> brought to ...
    >>And then there is the rest of the world, where any country may have,
    >>or introduce, its own legislation on the subject.

    >
    > That's all rather legalistic.
    >
    > By DAA, ADA, etc., Governments have formally recognised that those
    > with disabilities should not be disadvantaged where that can
    > reasonably be avoided.
    >
    > But this has been known since Man's ancestors first became near-human;
    > although not always implemented.

    <snip>

    The moral imperative; the notion that a web developer might also attempt
    to conform with being a decent human being and so not want to take
    otherwise avoidable actions that they knew would have harmful side
    effects for the already disadvantaged.

    But can you cite a specification on that? ;-)

    Though it can be avoided through ignorance/unawareness/denial,
    attributing responsibility to others, and appeals to Mammon.

    Richard.
    Richard Cornford, Jun 13, 2004
    #18
  19. Matt Kruse wrote:
    > Richard Cornford wrote:

    <snip>
    >> 1. The act of deploying a script ...

    <snip>
    > It does. ...

    <snip>
    >> 2. That additional "worth" is proportional to ...

    <snip>
    > True again. ...

    <snip>
    > Quality != Value


    > The dreamweaver scripts may not be high quality in terms of coding,
    > but they certainly have added incredible value for a number of people
    > who simply couldn't have done anything dynamic without them.
    >
    > A solution does not need to be perfect to have value.


    The Dreamweaver functions aren't not perfect, they are bad. They
    represent almost the worst way of doing everything they attempt and the
    only justification for that is that they were designed to be used by a
    machine without the application of any knowledge on its part and in
    response to nothing other than user actions.

    > Go into any consumer market for a quick lesson in this fact. Things
    > don't always make sense. People will sometimes prefer lower-quality
    > solutions in favor of more convenience, lower price, faster delivery,
    > etc, etc. You are implying that a solution which is not technically
    > ideal is always less valuable than a solution which follows all the
    > technical ideas. But this idea is clearly absurd!


    That is not what I am implying. I am implying (saying) that your
    criteria of "value" is utterly bogus. It promotes the bad over the good,
    the dependent over the reliable, the ill-conceived over the well
    designed and the status quo over the possibility of improvement.

    Though by any rational criteria software that is technically ideal is
    better than software that is not. Why did you even contemplate arguing
    otherwise? If you achieve the ideal what you have is something good, by
    virtue of the definition of the terms. The criteria in that case is
    quality, and may be judged on nothing more than the software itself. But
    identifying an ideal doesn't necessitate that all software achieve it
    prior to use, that would be unrealistic. But it does provide a target to
    aim for and a criteria to assess the results of the attempt to reach it.

    If someone designs and implements with the goal of achieving perfection
    there is actually a chance that they may reach it (sooner or later, and
    achieve ever better quality software along the way), but if their goal
    is your criteria of "value" what is the most they can hoped for;
    MM_findObj?

    > To a new html author making a web site for their dog, adding image
    > swapping with a few clicks of a button is fantastic! Even if it's not
    > technically the best solution, they don't care. Even if there are
    > better ways to do it, they don't care. Even if it will break in 5% of
    > their visitors' browsers, they don't care. Your assumptions about how
    > value is determined does not apply to everyone. Even if you think
    > they should.


    Amateurs can do what they like, if they never learn to do anything well
    they won't have much influence on the wider word for good or ill.
    Amateurs can choose what standards they wish to work to, maybe high
    standards if they like the challenge, maybe low standards if they are
    primarily interested in other things, or maybe something in between.

    But professionals have responsibilities. You wouldn't think much of a
    doctor who chose a treatment because it was popular, convenient, quick
    and cheep, but failed 5% of the time, over a treatment that was reliable
    and effective. Web development might not be life and death but is that
    really an excuse for professional ethics so lax that they rate
    convenience so far above quality?

    >> When a measure of "worth" ranks scripts that informed opinion
    >> denigrates so heavily above all others that criteria cannot be a
    >> measurement of script quality.

    >
    > Again, don't confuse value (worth) with quality.
    > The most technically-superior solutions are rarely the most popular or
    > valuable to most people.


    Self evidently.

    <snip>
    > Here you go... your "solutions" are often ugly


    Mine personally?

    > and unacceptable to some people who are writing the checks.
    > In your "ideal" world where theories and explanations are all that
    > need be discussed, this doesn't matter much to you. But in the real
    > world (which I deal with, and which you continually ignore) it's a
    > big factor.


    You attribute ugliness and then suggest that ugliness will be unpopular
    with clients. But on the javascript and CSS capable/enabled and
    sufficiently supportive browsers a functional script that is capable of
    cleanly degrading does not have to have any appearance characteristics
    that are not identical to a javascript dependent script implementing
    identical functionality. The difference comes when the browser does not
    supports either script, and the javascript dependent version starts
    denying the possibility of user interaction and any consequential
    purchases, turnover, profits etc. While the cleanly degrading script is
    facilitating continued user interaction, but at the cost of some aspects
    of presentation and user convenience, that the user will not notice
    because that is how they normally experience the Internet (when it works
    for them at all).

    You are telling me that hard-nosed businessmen are going to prefer a
    site that doesn't look quite as designed but brings in money over a site
    that looks pretty but is not functional, for a minority of users of
    unusual browsers? These are certainly not the businessmen in my world.
    My money would be on them actually choosing the version that continues
    to bring in the money, if they had been properly informed of the
    situation.

    <snip>
    >> From the point of view of a script a browser that does not support a
    >> particular feature (be it through a bug or otherwise) is not any
    >> different from a browser that does not support scripting at all.

    >
    > That is completely untrue.
    > Sometimes bugs cannot be found or worked around via feature detection.


    You keep saying that, but never get round to proposing any concrete
    examples and I suspect that many of the things that you believe are
    untestable (see below) would prove amenable to feature detection, or
    their use unnecessary.

    > If calling alert() for example would crash browser X, how could you
    > possiblly test for that,


    Are you aware of a browser that crashes when you call - alert -? That
    would be serious evidence of a reckless failure to test on the part of
    the browser's manufacturer. However, I do get round the fact that merely
    reading the - appendChild - property from an attribute object on many IE
    6 versions will crash the browser, by not reading the - appendChild -
    property of attribute objects (as there is absolutely no need or point).
    And I also promote the use of an element's - setAttribute - and -
    getAttribute - methods over any direct interaction with the attribute
    objects, as they do all that is necessary, can be safely detected and
    have not been reported as causing any problems on any supporting browser
    to date.

    >> Are you actually saying that Opera 5.02 will allow OPTIONs to be
    >> removed from a SELECT element and new Options to be created but it
    >> will not allow them to be added to a SELECT element? That would be a
    >> very specific bug, but completely amenable to feature detection.

    >
    > That is exactly what I have observed.
    > See this url in Opera 5.02:
    > http://www.mattkruse.com/temp/opera_options_test.html
    >
    > If you can detect that the first and second links will work, but not
    > the third, using only feature detection, I would like to see it.


    Unnecessary, Opera 5.02 is capable of adding OPTION elements to the
    options collection of a SELECT element. You had misattributed the cause
    of the failure to the ability to add the element, it is actually due to
    the fact that opera 5.02 does not implement the - length - property on
    the - options - collection so:-

    f.test.options[f.test.options.length] = o;

    - is adding a property with the name "undefined" to the options
    collection, and that does not represent a meaningful action to the
    browser. The - length - property of the SELECT element itself is numeric
    and reporting the actual length of the options collection, so it may be
    used instead. But I don't think it is worth the effort for one release
    of such an old browser if a path of clean degradation exists for any
    residual users of that browser.

    How much time have you put into failing to identify that problem? The
    first thing I did was put in:-

    alert(f.test.options.length);

    - and I immediately knew exactly what was going on. My next test,
    changing your original line above to:-

    f.test.options[f.test.length] = o;

    - confirmed my suspicion and presented a possible solution.

    (A first principle of feature detection is to test as near to the
    problem as possible.)

    My dependent select script, for all its shortcomings, still degraded
    successfully to the underlying HTML on Opera 5.02 as designed, because
    one of the earliest feature detection tests it does is to verify that
    the length property of an - options - collection conforms to its
    requirements. Undefined does not conform so the script cleanly degrades
    under its own control.

    As I had to download Opera 5.02 specifically to test your page (the
    oldest Opera version I had was 5.12), tying my script with it
    represented its first exposure to a new and clearly buggy environment.
    And the fact that it behaved exactly as designed in the face of that
    environment rather demonstrates that the theory (as you would have it)
    about how to script for reliability in the face of unknown browser
    environments is a little more practical that you would like to think it.

    > I've not come up with a good way to test for it,


    if(typeof f.test.options.length == 'number'){
    // pass
    }else{
    // fail
    }

    - would do.

    > other than actually doing
    > it and seeing if it works.


    Actually adding elements (or, as I have said, preferably removing them)
    and seeing if it worked is probably the only way of verifying that the
    browser's DOM is sufficiently dynamic to actively support the script.

    Richard.
    Richard Cornford, Jun 13, 2004
    #19
  20. Continental Translations

    Matt Kruse Guest

    Richard Cornford wrote:
    > I am implying (saying) that your
    > criteria of "value" is utterly bogus. It promotes the bad over the
    > good, the dependent over the reliable, the ill-conceived over the well
    > designed and the status quo over the possibility of improvement.


    "Value" is decided by each individual person, and by extension the general
    public. For some people, the ability to implement functionality in 10
    minutes yet have it break in 2% of browsers might have higher value than a
    custom-built solution that doesn't break in any bowser but takes 8 hours to
    code and test. For a flashy personal fun site, the deciding factor for
    "value" might be a really slick interface with lots of options, and quality
    of code and browser support might not be important at all.

    In terms of javascript coding, I can think of a number of factors which
    would contribute to a person's perception of 'value' for a given solution:
    - Ease of implementation
    - Browser support (including how well it degrades)
    - Extensibility
    - Available features
    - Price/licensing/restrictions
    - Support
    - Quality of coding (and by extension, ease of maintenance)
    - Speed

    In your eyes, quality of coding and degrading gracefully are the most
    important factors, above all else, right? A solution cannot have high value
    without those being top-notch?

    But to others, the important factors might be different. The determination
    of 'value' can vary greatly. In fact, you place almost no importance on
    'ease of implementation' or 'available features' (since you disagree with
    the concept of libraries entirely), which others might put at the top of the
    list. I argue that my solutions provide higher value to some people because
    we are targeting different factors as priorities.

    In an ideal world, a solution could provide all of the above. Except maybe
    price, because to create such a solution for free is not something most
    people would do :) (although, I'd argue that I come closer than most ;)

    > Though by any rational criteria software that is technically ideal is
    > better than software that is not. Why did you even contemplate arguing
    > otherwise?


    Because I believe you are wrong.
    Technically, I think linux is better than Windows as an OS.
    However, I use Windows daily because it provides more value to me. It's
    "better" for me. Even though I don't believe it's technically superior.
    I can think of many other such examples that I encounter on a daily basis.
    Is that something you find hard to understand?

    > Web development might not be life and death
    > but is that really an excuse for professional ethics so lax that they
    > rate convenience so far above quality?


    heh, that is _everywhere_ in the world. How many people use Windows with
    bugs and viruses and broken features, because it is more convenient than
    more technically superior solutions? How many web developers receive
    requests for features every day that are technically stupid, but must be
    implemented because it adds convenience for the users? That's the way of
    life for most software developers :)

    >> Here you go... your "solutions" are often ugly

    > Mine personally?


    Yes...
    Your date picker script on your example page would be unacceptable to most
    clients I've worked with because of the UI.
    You dynamic select list script degrades nicely, but in a form that would be
    unacceptable to most.
    IMO.

    > You are telling me that hard-nosed businessmen are going to prefer a
    > site that doesn't look quite as designed but brings in money over a
    > site that looks pretty but is not functional, for a minority of users
    > of unusual browsers?


    Perhaps. I've seen it happen. Repeatedly. Have you not?

    > However, I do get round the fact that
    > merely reading the - appendChild - property from an attribute object
    > on many IE 6 versions will crash the browser, by not reading the -
    > appendChild - property of attribute objects


    So you're not doing feature detection, but rather not using a feature
    entirely. Logical, of course, but it's still an example of a bug which
    cannot be detected through normal means.

    > actually due to the fact that opera 5.02 does not implement the -
    > length - property on the - options - collection so:-


    Hmm, that is indeed interesting, and not something I had even considered
    testing, since it's such a basic feature. Well done.

    > How much time have you put into failing to identify that problem?


    About 2 minutes, way back when I detected the problem. I didn't really try
    to debug it, because I didn't care about supporting 5.02. I was left with
    the (apparently incorrect) assumption that Opera5.02 wouldn't allow adding
    new options to select lists. Some googling at the time confirmed my
    suspicions, so I stopped. In fact, the first result in a search I just did
    was http://www.quirksmode.org/js/options.html which states "You cannot
    create or delete options in Operate 5.02- on Windows". I guess I wasn't the
    only one to reach such a conclusion :)

    At the end of the day, it's pretty clear that we have different ideas about
    javascript development. I think libraries are fantastic, and have a lot of
    value for many developers. You disagree. I think your code is clearly
    advanced and looks technically excellent, but I also think some of it is
    completely unreadable for most people (date picker code, for example). You
    believe in being technically excellent first, and useable second. I believe
    in the opposite.

    Although you disagree with some of my approaches to development, I do
    continue to develop better skills - as does anyone. I strive to offer the
    most technically excellent solutions that I'm capable of, and I'm always
    rethinking my ideas trying to come up with something better. It's a shame
    that someone like you who is technically talented in coding isn't willing to
    make implementation suggestions for scripts like mine, which are highly
    useable, have a lot of features, can be easily implemented, are well
    supported, and work in the way that many developers want them to. No one is
    capable of creating the most ideal solution by themselves, IMO. Multiple
    people working together to create the best possible solutions would be
    fantastic.

    In fact, I've long wanted to create a group of javascript developers who
    work together to create the best functions, modules, and libraries to
    perform various tasks. Some of that is in the FAQ now, but there are many
    other common tasks which could be implemented and made available for every
    javascript developer to learn from and use. Perhaps it's an idea that could
    get started by regulars of this group.

    --
    Matt Kruse
    Javascript Toolbox: http://www.JavascriptToolbox.com/
    Matt Kruse, Jun 14, 2004
    #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?QUNhdW50ZXI=?=

    DropDown Menus

    =?Utf-8?B?QUNhdW50ZXI=?=, Feb 3, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    427
    Ken Cox [Microsoft MVP]
    Feb 3, 2005
  2. Maflu
    Replies:
    7
    Views:
    364
    Richard Clark
    Dec 26, 2003
  3. Hardeep Rakhra

    Help with dropdown menus. > AD xMenu

    Hardeep Rakhra, Jan 8, 2004, in forum: HTML
    Replies:
    7
    Views:
    534
    Mark Parnell
    Jan 9, 2004
  4. (Pete Cresswell)

    Dropdown menus: Good Practice?

    (Pete Cresswell), Dec 8, 2004, in forum: HTML
    Replies:
    21
    Views:
    920
    kchayka
    Dec 13, 2004
  5. news.west.cox.net

    Select menus above flyout menus? help?

    news.west.cox.net, Dec 8, 2004, in forum: HTML
    Replies:
    8
    Views:
    778
Loading...

Share This Page