dynamic combo boxes

Discussion in 'Javascript' started by mr_burns, Apr 1, 2004.

  1. mr_burns

    mr_burns Guest

    hi,

    is it possible to change the contents of a combo box when the contents
    of another are changed. for example, if i had a combo box called
    garments containing shirts, trousers and hats, when the user selects
    shirts another combo box called 'size' would contain sizes in relation
    to shirts (ie. chest/neck size). the same would occur for trousers and
    hats. when the user selects an option in the garment combo box, the
    options available change dynamically in the size combo box. any ideas?

    cheers
     
    mr_burns, Apr 1, 2004
    #1
    1. Advertising

  2. mr_burns

    Matt Kruse Guest

    "mr_burns" <> wrote:
    > is it possible to change the contents of a combo box when the contents
    > of another are changed.


    There are lots of libraries out there which do this.

    Mine is at: http://www.mattkruse.com/javascript/dynamicoptionlist/

    Also, I'm putting the finishing touches on version 2 of the script which has
    more features and a better interface:

    http://www.mattkruse.com/javascript/dynamicoptionlist2/

    Hope that helps!

    --
    Matt Kruse
    Javascript Toolbox: http://www.mattkruse.com/javascript/
     
    Matt Kruse, Apr 1, 2004
    #2
    1. Advertising

  3. mr_burns wrote:
    > is it possible to change the contents of a combo box when the contents
    > of another are changed. for example, if i had a combo box called
    > garments containing shirts, trousers and hats, when the user selects
    > shirts another combo box called 'size' would contain sizes in relation
    > to shirts (ie. chest/neck size). the same would occur for trousers and
    > hats. when the user selects an option in the garment combo box, the
    > options available change dynamically in the size combo box. any ideas?


    The majority of dynamic browsers will facilitate the swapping of the
    options in a SELECT element, or the switching of the display of several
    alternative second SELECT elements. But a big question when doing that
    is what will the user be getting if they are using a browser that does
    not support javascript (or has it disabled)? You are selling clothes,
    and to make profits you want to sell as many clothes as possible.
    Placing any artificial barrier between the potential customer and their
    ability to do business with you is not going to increase profits. And
    there is no conceivable relationship between the customer's use of a
    javascript capable dynamic web browser and their need to dress. (And it
    is not the web developer's place to impose that relationship on the
    business owners site, at least not without making the consequences, and
    the fact that it is not necessary, clear to the business owner first.)

    Most "swap the options in the next SELECT based on the selection in the
    first SELECT" scripts store all of the date for the various options in
    javascript structures (arrays and/or objects) so the resulting UI for
    the javascript incapable visitor is unusable (you have just lost a
    potential customer). A few designs place all of the possible options in
    the HTML for the SELECT element and then remove the unneeded ones, they
    are usable in the absence of javascript but are not exactly easy to use.
    A last style creates numerous second SELECT elements containing the
    options for each selection in the first, separately, and then hides the
    unneeded ones. That is also usable in the absence of client-side
    scripting but, again, not necessarily that easy to use.

    All scripts of this type are more or less unsatisfactory in the way in
    which they degrade when scripting is not supported on the client, or the
    browser lacks the required features. On the other hand, the ones that
    put the options in the HTML still allow the customer to purchase clothes
    even without javascript.

    But a wizard style interface, running entirely on server-side scripts,
    is probably the best combination of reliability and usability. The
    customer selects "trousers" and submits that selection form, and is
    taken to a page on which they can select things like type, colour and
    size. The back end returns the options suited to the initial selections.
    It is relatively easy to program and use and there is no dependence on
    anything on the client-side beyond HTML support. Every potential
    customer is in a position to do business with the site.

    Richard.
     
    Richard Cornford, Apr 1, 2004
    #3
  4. mr_burns

    Matt Kruse Guest

    "Richard Cornford" <> wrote:
    > All scripts of this type are more or less unsatisfactory in the way in
    > which they degrade when scripting is not supported on the client, or the
    > browser lacks the required features.
    > But a wizard style interface, running entirely on server-side scripts,
    > is probably the best combination of reliability and usability.


    First of all, you're assuming that the browser and/or javascript
    enabled/disabled aren't fixed, which in many intranet environments they are.
    And maybe the OP's site _requires_ javascript to be enabled. The OP might
    not be looking for a solution to be used on the internet in a commerce
    situation :)

    I disagree with your conclusion, though.

    Dynamic option lists _can_ coexist peacefully with a server-side solution,
    and in cases like you mentioned, should be done that way.
    If the client has javascript, they see multiple select lists which are
    dynamic.
    If they do not have javascript, they see a single select list with perhaps a
    "Select" button which goes to the server and comes back with a new select
    list with sub-options.

    This can be done quite well using a combination of document.write() calls to
    write out the child selects and <noscript> to add the "Select" buttons.

    So the best solution, IMO, is to use both methods. And that would be up to
    the application developer to integrate their server-side code with a
    client-side library (which should know or care about the server-side
    option).

    --
    Matt Kruse
    Javascript Toolbox: http://www.mattkruse.com/javascript/
     
    Matt Kruse, Apr 1, 2004
    #4
  5. Matt Kruse wrote:
    > "Richard Cornford" wrote:
    >> All scripts of this type are more or less unsatisfactory in the way
    >> in which they degrade when scripting is not supported on the client,
    >> or the browser lacks the required features.
    >> But a wizard style interface, running entirely on server-side
    >> scripts, is probably the best combination of reliability and
    >> usability.

    >
    > First of all, you're assuming that the browser and/or javascript
    > enabled/disabled aren't fixed, which in many intranet environments
    > they are.


    People sell trousers on Intranets? Well I suppose it is not impossible
    given a sufficiently large company.

    > And maybe the OP's site _requires_ javascript to be
    > enabled.


    Retailers who require javascript have already shot themselves in the
    foot. But I have always thought that it is web developers lacking the
    skills to do better that results in javascript dependent retail sites,
    and if you asked the business people behind the sites whether they had
    chosen to needlessly turn away customers you would probably discover
    that they either didn't know they were or that they had been told that
    it couldn't be avoided (by the web developers, form whom their skill
    defect made it true).

    > The OP might not be looking for a solution to be used on the
    > internet in a commerce situation :)


    Selling clothes sounds commercial (unless they are very generously being
    given away, and in a range of sizes too). And the Internet is the pace
    that retailing web sites need to be to get customers. It makes much more
    sense to conclude that the question relates to and Internet e-commerce
    site than an Intranet clothing distribution site (if such a thing
    exists).

    > I disagree with your conclusion, though.


    My conclusion that client-side dependent select scripts are more or less
    unsatisfactory when it comes to degrading in the absence of browser
    support for scripting or the required features? Falling back to a
    server-side script isn't even considered in most of the available
    implementations and has drawbacks of its own. Without a fall-back to
    server-side some an crippled by the absence of client-side support and
    the few remaining that are still functional don't provide an easily
    usable UI.

    > Dynamic option lists _can_ coexist peacefully with a server-side
    > solution, and in cases like you mentioned, should be done that way.


    A design process that requires the server-died process to be designed
    first and then short-circuited with client-side scripting once
    appropriate browser support has been verified. But a wizard style
    interface needs to be fast or the users will be unhappy with it, and
    sending all of the script and data needed for a client side enhancement
    is not going to help when it comes to download time.

    > If the client has javascript, they see multiple select lists which are
    > dynamic.
    > If they do not have javascript, they see a single select list with
    > perhaps a "Select" button which goes to the server and comes back
    > with a new select list with sub-options.
    >
    > This can be done quite well using a combination of document.write()
    > calls to write out the child selects and <noscript> to add the
    > "Select" buttons.


    Not <noscript>, and support for document.write are not the correct
    relationship for the task. The <noscript> relationship is javascript can
    be executed, or javascript is unsupported or disabled. But the ability
    to execute javascript does not imply that the browser will be capable of
    supporting the dynamic swapping of OPTIONs in a SELECT element. And
    neither does the ability to use the document.write function.

    Achieving an integration of client-side scripting and server-side
    fall-back requires that the client side script actively verify the
    browser's support for the required features and use the server-side
    fall-back whenever it cannot be certain that it will be supported
    locally. The script - noscript relationship doesn't achieve that, indeed
    the noscript element has almost no practical application in the creation
    of browser scripts because whatever the noscirpt element may have
    included in the document to make sense in the absence of client-side
    scripting would still have to be in the document if it is to make sense
    in the absence of browser support for the features required by the
    script when it does get a chance to execute. And the obvious way to
    facilitate that is to have whatever noscript would have inserted in the
    HTML from the outset and have the script manipulate it to suite the
    situation only when it found itself to be fully functional.

    It is precisely this type of failure to properly recognise and attribute
    dependency relationships that stands in the way of the ability to create
    truly robust client-side systems and integrate them with suitable
    server-side fall-back.

    > So the best solution, IMO, is to use both methods. And that would be
    > up to the application developer to integrate their server-side code
    > with a client-side library (which should know or care about the
    > server-side option).


    The library concept is not suited to browser scripting. Obviously it
    introduces a dependency on the creator of that library to have properly
    handled its implementation, which very few of them do, usually
    disregarding adequate testing, fall-back and clean degradation entirely,
    or failing to recognise the real dependency relationships so any
    fall-back and degradation will be faulty. But libraries also introduce a
    level of code bloat, attempting to cover actions and conditions
    irrelevant to many applications. But the library user needs to be
    sufficiently skilled to write the code themselves in order to be in a
    position to decide what it is possible to omit as unneeded in the
    application. A much more efficient result would inevitably be achieved
    with code tailored to the specific application, eliminating superfluous
    code and allowing a very direct integration with the mark-up used and a
    direct path of degradation to the server-side fall-back.

    Richard.
     
    Richard Cornford, Apr 1, 2004
    #5
  6. mr_burns

    Matt Kruse Guest

    Are you a lawyer, or do you just like using a lot of wording? :)

    "Richard Cornford" <> wrote:
    > > First of all, you're assuming that the browser and/or javascript
    > > enabled/disabled aren't fixed, which in many intranet environments
    > > they are.

    > People sell trousers on Intranets? Well I suppose it is not impossible
    > given a sufficiently large company.


    *shrug* The OP didn't say anything about selling. Just selecting.
    Nevertheless, the question wasn't whether or not it should be done, but how
    to do it.

    > Retailers who require javascript have already shot themselves in the
    > foot.


    I highly doubt it. I bet at least 95% (if not more) of users visiting a
    commerce site have javascript enabled. If you require javascript, you'll
    only alienate a small portion of potential buyers, which may be offset by
    reduced development costs. Who knows. I would never recommend that someone
    require js on their commerce site, but your generalization is a bit extreme,
    IMO.

    > > I disagree with your conclusion, though.

    > My conclusion that client-side dependent select scripts are more or less
    > unsatisfactory when it comes to degrading in the absence of browser
    > support for scripting or the required features?


    Yes.

    > Falling back to a
    > server-side script isn't even considered in most of the available
    > implementations and has drawbacks of its own.


    A dynamic option list library shouldn't need to consider the conditions
    where it isn't used.

    > sending all of the script and data needed for a client side enhancement
    > is not going to help when it comes to download time.


    It probably won't matter much. An extra 10k? No big deal.
    If you're sending over 200k of data to the client, then that's a bad
    decision (I've seen people do it).

    > But the ability
    > to execute javascript does not imply that the browser will be capable of
    > supporting the dynamic swapping of OPTIONs in a SELECT element.


    Very few browsers are incapable of this these days. Depends on your target
    audience's browser choices, I guess. Anyone browsering with Opera5 or
    Netscape3 needs to be pushed into upgrading anyway. If a browser supports
    Javascript, I expect it to support the core features of 1.1, at least,
    including the ability to swap out option objects. If it doesn't, then it's
    broken, and the user needs to use a browser that isn't broken if he or she
    expects to have a good experience on the web.

    There are some assumptions you must make about the browser's capabilities.
    What if the browser doesn't implement for() loops? Do you check for that
    before using them? heh.

    > The library concept is not suited to browser scripting.


    That's absurd.

    > But libraries also introduce a
    > level of code bloat, attempting to cover actions and conditions
    > irrelevant to many applications. But the library user needs to be
    > sufficiently skilled to write the code themselves in order to be in a
    > position to decide what it is possible to omit as unneeded in the
    > application.


    Code bloat isn't that big of a deal when you're considering a 20k library
    which is cached across many pages on a site.
    Users stripping out code from a library is unnecessary and not recommended,
    because it makes for maintenance hell later if the library is updated.

    > A much more efficient result would inevitably be achieved
    > with code tailored to the specific application, eliminating superfluous
    > code and allowing a very direct integration with the mark-up used and a
    > direct path of degradation to the server-side fall-back.


    So you want to re-invent the wheel each time?

    What you save in download times and "superfluous code" will easily be offset
    by increased development time and expense.
    Libraries and code reuse should be encouraged, IMO.
    Especially for users without the skills to indepdendently develop code to
    perform a function which a library could perform in a black-box manner.

    --
    Matt Kruse
    Javascript Toolbox: http://www.mattkruse.com/javascript/
     
    Matt Kruse, Apr 1, 2004
    #6
  7. mr_burns

    R Guest

    (mr_burns) wrote in message news:<>...
    > hi,
    >
    > is it possible to change the contents of a combo box when the contents
    > of another are changed. for example, if i had a combo box called
    > garments containing shirts, trousers and hats, when the user selects
    > shirts another combo box called 'size' would contain sizes in relation
    > to shirts (ie. chest/neck size). the same would occur for trousers and
    > hats. when the user selects an option in the garment combo box, the
    > options available change dynamically in the size combo box. any ideas?
    >
    > cheers


    Try:
    <html>
    <head>
    <title>Untitled</title>
    <script>
    function updateSize(){
    currSelect = document.a.item.options[document.a.item.selectedIndex].value
    //create options based on selection
    if (currSelect == "shirt"){
    //paramaters are (display text,value,default selected,selected)
    document.a.size.options[0]=Option(15,15)
    document.a.size.options[1]=Option(15.5,15.5)
    document.a.size.options[2]=Option(16,16,true,true)
    document.a.size.options[3]=Option(16.5,16.5)
    }else if (currSelect == "pants"){
    document.a.size.options[0]=Option("small","small")
    document.a.size.options[1]=Option("medium","medium")
    document.a.size.options[2]=Option("large","large",true,true)
    document.a.size.options[3]=Option("x-large","x-large")
    }
    }
    </script>
    </head>
    <body>
    <form name="a">
    item:<br />
    <select name="item" onChange="updateSize()">
    <option name="">-</option>
    <option value="shirt">shirt</option>
    <option value="pants">pants</option>
    </select>
    <br /><br /><br />
    size:<br />
    <select name="size">
    </select>
    </form>
    </body>
    </html>
     
    R, Apr 1, 2004
    #7
  8. Matt Kruse wrote:
    > "Richard Cornford" wrote:

    <snip>
    > Nevertheless, the question wasn't whether or not it should be done,
    > but how to do it.


    Almost all questions asked are how to do something, but many answers
    turn out to be that it shouldn't be done at all. Someone wishing to save
    their server the burden of doing server-side form validation, for
    example, might ask how and be told how to do their validation
    client-side, but they *should* be told that they *must* repeat the
    validation on the server or leave it as exclusively server-side.

    It is irresponsible not to consider the wisdom of any proposed action,
    nobody should be handing out loaded guns upon request.

    >> Retailers who require javascript have already shot
    >> themselves in the foot.

    >
    > I highly doubt it. I bet at least 95% (if not more) of users visiting
    > a commerce site have javascript enabled.


    Are you falling for the statistics? The most commonly reported
    statistics for javascript incapable/disabled browsers are 8-12%, but the
    range of reported statistics that I have seen is 2-80%, which says quite
    a lot about the usefulness of reported statistics.

    But assuming your 95% guesstimate is correct; now go to the business
    people and ask them if they are willing to sacrifice 5% of turnover as a
    consequence of an arbitrary and unnecessary design decision. Are they
    going to be agreeing to the unnecessary sacrifice or calling for the
    alternatives?

    > If you require javascript, you'll only alienate
    > a small portion of potential buyers, which may
    > be offset by reduced development costs.


    For some reason it is only the people who don't know how to handle
    implementing e-commence sites that are 100% reliable who think that it
    must cost more to do so, and they are not in a good position to judge.
    If something is built from scratch with the intention of being 100%
    reliable then it would not cost any more than any other similar site,
    there is no more actual work involved.

    <snip>
    >> > I disagree with your conclusion, though.

    >> My conclusion that client-side dependent select scripts are more or
    >> less unsatisfactory when it comes to degrading in the absence of
    >> browser support for scripting or the required features?

    >
    > Yes.


    You have seen one that degrades to a usable and simple pure HTML UI
    without client-side scripting? Where? That has got to be worth a look.

    >> Falling back to a server-side script isn't even
    >> considered in most of the available
    >> implementations and has drawbacks of its own.

    >
    > A dynamic option list library shouldn't need to consider the
    > conditions where it isn't used.


    It should be reporting when it is unusable (unsupported) though, else
    the script that would otherwise employ it will not know that it needs to
    fall-back to the server.

    >> sending all of the script and data needed for a client side
    >> enhancement is not going to help when it comes to download time.

    >
    > It probably won't matter much. An extra 10k? No big deal.
    > If you're sending over 200k of data to the client, then that's a bad
    > decision (I've seen people do it).


    With a recommended upper limit of 80k for total download time for a page
    (else people get bored an go elsewhere) 10k is a significant percentage
    of any really viable web page.

    >> But the ability
    >> to execute javascript does not imply that the browser will be
    >> capable of supporting the dynamic swapping of OPTIONs in a SELECT
    >> element.

    >
    > Very few browsers are incapable of this these days.


    But some of the browsers that cannot do it are the latest versions
    available for the devices on which they opperate. And there is not one
    javascript capable browser that can do it on which scripting cannot be
    disabled.

    > Depends on your
    > target audience's browser choices, I guess.


    The target audience for e-commerce doesn't have to be anything but the
    people with enough money to pay for the products, and there is no
    relationship between having sufficient money to make purchases and any
    particular web browsers (indeed it has been observed that people with
    lots of surplus money sometimes have a tendency to bye electronic
    gadgets, which is where you find the strangest browsers embedded). The
    whole "target audience" thing is just a smokescreen used by people who
    are not capable of delivering 100% of customers (and would rather find
    any excuse than learn how).

    > Anyone browsering with
    > Opera5 or Netscape3 needs to be pushed into upgrading anyway.


    That's right, it is the potential customer's fault when you cannot do
    business with them.

    > If a browser supports Javascript,
    > I expect it to support the core features
    > of 1.1, at least,


    Why? Support for an ECMAScript version would be a more rational
    expectation, as that is the standard for the language.

    > including the ability to swap out option objects.


    The ability to swap option elements (using the Option constructor rather
    than DOM) is non-standard and no matter how many browsers copied
    Netscape and implemented it there are no grounds to for hanging the
    functionality of an e-commerce web site upon it.

    > If it doesn't, then it's broken, and the user needs to use a browser
    > that isn't broken if he or she expects to have a good experience on
    > the web.


    That's right, it is the potential customer's fault when you cannot do
    business with them.

    But none of this matters if the script has been designed with a path of
    clean-degradation to either a useable HTML UI or fall-back to server
    side. If the browser doesn't support the required features the script
    can recognise that condition and degrade itself under control.
    Everything works for all potential customers, one way or another. Crying
    "broken" when the browser doesn't satisfy you unrealistic expectations
    is no way of handling the reality.

    > There are some assumptions you must make about the browser's
    > capabilities.


    Yes, you have to assume it can handle HTML over HTTP, that is what
    defines a web browser. Everything else is optional. But, from the pint
    of view of an executing script, the relevant features are testable, so
    you don't have to _assume_ anything beyond an ECMAscript compliant
    scripting engine.

    > What if the browser doesn't implement for() loops? Do
    > you check for that before using them? heh.


    Standard language constructs must be assumed to be functional, else the
    browser just isn't scriptable, no code will run (which isn't a problem
    when the script has been suitably designed), features known to only
    appear in later language versions should be tested for (or avoided), as
    should implementation details that are known to be buggy.

    >> The library concept is not suited to browser scripting.

    >
    > That's absurd.


    No, that's browser scripting.

    Libraries make perfect sense with compiled languages and languages
    running locally in a known system. In the case of compiled languages the
    final code only needs to contain the code from the libraries that it is
    actually going to use (the compiler can recognise dependencies and make
    informed decisions about what to include). And languages running locally
    can have their library resources easily to hand (on the hard disk) so
    there isn't the same download and bandwidth considerations as apply to
    browser scripting.

    But push pages at people with an ever-decreasing attention span and if
    the page doesn't show up before they get bored waiting there is every
    chance you have lost a visitor that you wanted. When the window of
    opportunity is small and the pipe may be narrow every byte can count.

    >> But libraries also introduce a
    >> level of code bloat, attempting to cover actions and conditions
    >> irrelevant to many applications. But the library user needs to be
    >> sufficiently skilled to write the code themselves in order to be in a
    >> position to decide what it is possible to omit as unneeded in the
    >> application.

    >
    > Code bloat isn't that big of a deal when you're considering a 20k
    > library which is cached across many pages on a site.


    And if the same task can be done with < 10k of site-tailored code?

    > Users stripping out code from a library is unnecessary and not
    > recommended, because it makes for maintenance hell later if the
    > library is updated.


    Sending code that will _never_ be executed to remote users is
    unnecessary.

    >> A much more efficient result would inevitably be achieved
    >> with code tailored to the specific application, eliminating
    >> superfluous code and allowing a very direct integration with the
    >> mark-up used and a direct path of degradation to the server-side
    >> fall-back.

    >
    > So you want to re-invent the wheel each time?


    > What you save in download times and "superfluous code" will easily be
    > offset by increased development time and expense.


    No, I want to tailor the code to its application, to the extent to which
    its application differs the code should differ. Which is exactly what
    happens with library code anyway, as the library itself does not do
    anything it just provides resources that still need application specific
    code to use them. The difference is that the library must attempt to
    facilitate everything that could be asked of it while tailored code only
    needs to facilitate what is needed of it.

    > Libraries and code reuse should be encouraged, IMO.


    Code re-use is entirely sensible and proper, it is the library concept
    that is misguided. Small re-usable task-specific components are
    certainly desirable for browser scripting. But it is the nature of
    libraries to provide large interdependent and all-encompassing systems
    (and if they don't they end up being too inflexible).

    Building up form small task-specific components easily creates complex
    code that does no more than is required. But try using two separate
    libraries and not only will you have all the code for the features you
    don't need but you will also have doubled up all the code for the
    necessary internal tasks that are common to both, three libraries and it
    is worse again.

    > Especially for users without the skills to indepdendently develop
    > code to perform a function which a library could perform in a
    > black-box manner.


    In practice it often takes as much effort to learn how to use a library
    (particularly the "corss-broser" DHTML ones as it would take to script
    the browser DOMs directly, so if that time is put into learning browser
    APIs instead of library APIs making your own, and understanding other's,
    small components is easy, as is gluing them together.

    Black-boxes do not have to be big boxes.

    Richard.
     
    Richard Cornford, Apr 2, 2004
    #8
  9. mr_burns

    Matt Kruse Guest

    "Richard Cornford" <> wrote:
    > >> The library concept is not suited to browser scripting.

    > > That's absurd.

    > No, that's browser scripting.


    Well, we'll have to agree to disagree on almost every point in this
    back-and-forth :)

    I respect your views, I just don't fully agree with them. I've been very
    successful with my approach, both in my personal projects and with business
    projects. I suspect that we actually agree on a lot of concepts, just to
    different degrees. I think I'm a bit more practical than idealistic. I've
    seen a lot of people who obsess endlessly about standards and supporting
    every possible browser in every possible environment, so much so that they
    end up never actually creating something useful. Not all situations are the
    same.

    I've developed applications that were only used on specific browsers on
    specific OS's at specific resolutions, etc (which is actually quite
    refreshing to do!). So I know that not everyone is working in a wide-open
    Internet environment where lowest-common-denominator browsers must be
    supported and all that stuff. Sometimes fancy browser-based solutions really
    work well, and if you give people the benefit of the doubt that they know
    what they need (or at least leave that to a different discussion) then you
    can direct them to good solutions that solve their problems without
    diverging into sermons about what they should and shouldn't be doing.

    --
    Matt Kruse
    Javascript Toolbox: http://www.mattkruse.com/javascript/
     
    Matt Kruse, Apr 2, 2004
    #9
  10. Matt Kruse wrote:
    > "Richard Cornford" <> wrote:
    >> >> The library concept is not suited to browser scripting.
    >> > That's absurd.

    >> No, that's browser scripting.

    >
    > Well, we'll have to agree to disagree on almost every point in this
    > back-and-forth :)
    >

    <snip>
    > I think I'm a bit more practical than idealistic.


    There is nothing idealistic about recognising that there are 100%
    reliable underlying technologies available to form the foundations of
    any web based system and suggesting that additional technologies can be
    layered on top of that in away that fully exploits the capabilities of
    any browser encountered but does not detract from its fundamental
    reliability when the browser does not facilitate the script. It is a
    practical way of designing and implementing a system that will work for
    everyone, and an appropriate approach to e-commerce sites as it doesn't
    exclude the possibility of flashy presentation and dynamic page
    manipulation but also places no barriers between the customer and their
    ability to do business.

    While the opinion that it is unnecessary to even be aware of the true
    diversity of web browsers, to dismiss those that don't meet expectations
    as broken and fail to handle (or even attempt to handle) the
    consequences of a script's inevitable failure in any unsupporting
    environment, is only practical to the extent to which potential
    employers do not appreciate how much better the job can be done.

    > I've seen a lot of people who obsess endlessly about
    > standards and supporting every possible browser in every possible
    > environment, so much so that they end up never actually creating
    > something useful.


    I don't believe that you have, you might like to think so but the few
    people who bother to address the Internet cross-browser scripting design
    problem seem to manage to produce scripts that are both useful and
    reliable in operation and cleanly degrading when necessary.

    > Not all situations are the same.


    At any moment the internet is always the same.

    > I've developed applications that were only used on specific browsers
    > on specific OS's at specific resolutions, etc (which is actually quite
    > refreshing to do!).


    Scripting for a known environment is trivial, there is no intellectual
    challenge in it, just reading documentation, scripting and testing.

    <snip>
    > ... , and if you give people the benefit of the doubt
    > that they know what they need


    The evidence is that many (possibly most) of the people asking questions
    here haven't even managed to identify there true problem, instead they
    perceive a specific need and pursue that but attempting to satisfy that
    expressed need is of less real benefit to them than identifying and
    addressing their real problem.

    > (or at least leave that to a different discussion)


    And where do you propose that discussion is going to happen if it is not
    right here? comp.lang.javascript is a discussion forum after all, not a
    helpdesk.

    > then you can direct them to good
    > solutions that solve their problems without diverging into
    > sermons about what they should and shouldn't be doing.


    When the real problem is misguided underlying design then the solution
    is best achieved by highlighting the issues and proposing changes to the
    correct part of the design. Not flaky copy-and-paste javascript
    Band-Aids.

    Richard.
     
    Richard Cornford, Apr 2, 2004
    #10
  11. "Richard Cornford" <> writes:

    > You have seen one that degrades to a usable and simple pure HTML UI
    > without client-side scripting? Where? That has got to be worth a look.


    I considered it once, and came to the conclusion that there was two
    ways of handling dependent select elements that degraded nicely.

    The first option was to have all the elements available in one visible
    select element. If Javascript is enabled, then a second, higher level,
    select is made visible, and its first entry selected. That updates the
    original select to only contain elements in the selected group.
    Only the original select will be submitted.

    The other option is to have the select with the groups visible from
    start, and when you submit, you get the form back with a select with
    the elements in that group. You then progress like in a "wizard".

    Example code:
    <URL:http://www.infimum.dk/HTML/multiselect.html>

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Apr 2, 2004
    #11
  12. Lasse Reichstein Nielsen wrote:
    > "Richard Cornford" <> writes:
    >> You have seen one that degrades to a usable and simple pure
    >> HTML UI without client-side scripting? Where? That has got
    >> to be worth a look.

    >
    > I considered it once, and came to the conclusion that there was two
    > ways of handling dependent select elements that degraded nicely.

    <snip>

    Yes, I remember it. It is one of only 3 (maybe 4) scripts that I have
    seen that even attempt to handle the degradation issue. But even yours,
    which makes good use optgroup elements (at least if supported), does not
    produce that simple an HTML UI when degraded. It is one of the more
    usable versions if only two levels of dependence exists in the select
    elements, but with 3 or 4 levels the degraded UI is not going to be easy
    to use, just technically functional. And that is the running theme with
    these scripts, the best of the pure client-side attempts don't quite
    manage to qualify as good, the best they can claim is to be acceptable.

    > The other option is to have the select with the groups visible from
    > start, and when you submit, you get the form back with a select with
    > the elements in that group. You then progress like in a "wizard".

    <snip>

    For all "wizard" style interfaces may not be that popular with users,
    they do lend themselves to HTTP and can at least be reliably implemented
    without any dependence on optional technology. They should, of course,
    be fast (in transition between pages).

    In most respects, short-circuiting a request to a server-side fall-back
    with client-side scripting can have benefits without introducing
    unnecessary dependence, but short-circuiting the wizard means that the
    first page has to have all of the date for every subsequent branch.
    Probably not that significant with only two levels of dependence but
    potentially a big handicap to the performance of the wizard with 3 or 4
    levels of dependent select elements.

    Richard.
     
    Richard Cornford, Apr 3, 2004
    #12
  13. mr_burns

    mr_burns Guest

    burnsy
     
    mr_burns, Apr 3, 2004
    #13
    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. dthmtlgod

    Fill Combo Box based on another Combo Box

    dthmtlgod, Nov 16, 2005, in forum: ASP General
    Replies:
    1
    Views:
    624
    Bob Barrows [MVP]
    Nov 16, 2005
  2. Andreas Wohlhaupter

    Problem with dynamic combo boxes

    Andreas Wohlhaupter, Aug 20, 2003, in forum: Javascript
    Replies:
    0
    Views:
    103
    Andreas Wohlhaupter
    Aug 20, 2003
  3. Multiple dynamic combo boxes

    , Mar 9, 2005, in forum: Javascript
    Replies:
    3
    Views:
    107
    Mick White
    Mar 9, 2005
  4. dynamic combo boxes widths

    , Dec 26, 2005, in forum: Javascript
    Replies:
    2
    Views:
    104
  5. SM
    Replies:
    2
    Views:
    403
Loading...

Share This Page