dynamic combo boxes

[mr_burns]

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

[Matt Kruse]

Re: dynamic combo boxes

"mr_burns" <bissatch@yahoo .co.uk> wrote:[color=blue]
> is it possible to change the contents of a combo box when the contents
> of another are changed.[/color]

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/

[Richard Cornford]

Re: dynamic combo boxes

mr_burns wrote:[color=blue]
> 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?[/color]

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]

Re: dynamic combo boxes

mr_burns wrote:[color=blue]
> 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?[/color]

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.

[Matt Kruse]

Re: dynamic combo boxes

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue]
> 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.[/color]

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/

[Richard Cornford]

Re: dynamic combo boxes

Matt Kruse wrote:[color=blue]
> "Richard Cornford" wrote:[color=green]
>> 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.[/color]
>
> First of all, you're assuming that the browser and/or javascript
> enabled/disabled aren't fixed, which in many intranet environments
> they are.[/color]

People sell trousers on Intranets? Well I suppose it is not impossible
given a sufficiently large company.
[color=blue]
> And maybe the OP's site _requires_ javascript to be
> enabled.[/color]

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).
[color=blue]
> The OP might not be looking for a solution to be used on the
> internet in a commerce situation :)[/color]

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).
[color=blue]
> I disagree with your conclusion, though.[/color]

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.
[color=blue]
> Dynamic option lists _can_ coexist peacefully with a server-side
> solution, and in cases like you mentioned, should be done that way.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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).[/color]

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.

[Matt Kruse]

Re: dynamic combo boxes

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

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue][color=green]
> > First of all, you're assuming that the browser and/or javascript
> > enabled/disabled aren't fixed, which in many intranet environments
> > they are.[/color]
> People sell trousers on Intranets? Well I suppose it is not impossible
> given a sufficiently large company.[/color]

*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.
[color=blue]
> Retailers who require javascript have already shot themselves in the
> foot.[/color]

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.
[color=blue][color=green]
> > I disagree with your conclusion, though.[/color]
> 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?[/color]

Yes.
[color=blue]
> Falling back to a
> server-side script isn't even considered in most of the available
> implementations and has drawbacks of its own.[/color]

A dynamic option list library shouldn't need to consider the conditions
where it isn't used.
[color=blue]
> sending all of the script and data needed for a client side enhancement
> is not going to help when it comes to download time.[/color]

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).
[color=blue]
> 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.[/color]

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.
[color=blue]
> The library concept is not suited to browser scripting.[/color]

That's absurd.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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

What you save in download times and "superfluou s 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/

[R]

Re: dynamic combo boxes

bissatch@yahoo. co.uk (mr_burns) wrote in message news:<651c6ea9. 0404010708.3901 e978@posting.go ogle.com>...[color=blue]
> 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[/color]

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,defa ult selected,select ed)
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,t rue,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,t rue)
document.a.size .options[3]=Option("x-large","x-large")
}
}
</script>
</head>
<body>
<form name="a">
item:<br />
<select name="item" onChange="updat eSize()">
<option name="">-</option>
<option value="shirt">s hirt</option>
<option value="pants">p ants</option>
</select>
<br /><br /><br />
size:<br />
<select name="size">
</select>
</form>
</body>
</html>

[Richard Cornford]

Re: dynamic combo boxes

Matt Kruse wrote:[color=blue]
> "Richard Cornford" wrote:[/color]
<snip>[color=blue]
> Nevertheless, the question wasn't whether or not it should be done,
> but how to do it.[/color]

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.
[color=blue][color=green]
>> Retailers who require javascript have already shot
>> themselves in the foot.[/color]
>
> I highly doubt it. I bet at least 95% (if not more) of users visiting
> a commerce site have javascript enabled.[/color]

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?
[color=blue]
> If you require javascript, you'll only alienate
> a small portion of potential buyers, which may
> be offset by reduced development costs.[/color]

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>[color=blue][color=green][color=darkred]
>> > I disagree with your conclusion, though.[/color]
>> 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?[/color]
>
> Yes.[/color]

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.
[color=blue][color=green]
>> Falling back to a server-side script isn't even
>> considered in most of the available
>> implementations and has drawbacks of its own.[/color]
>
> A dynamic option list library shouldn't need to consider the
> conditions where it isn't used.[/color]

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.
[color=blue][color=green]
>> sending all of the script and data needed for a client side
>> enhancement is not going to help when it comes to download time.[/color]
>
> 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).[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> Very few browsers are incapable of this these days.[/color]

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.
[color=blue]
> Depends on your
> target audience's browser choices, I guess.[/color]

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).
[color=blue]
> Anyone browsering with
> Opera5 or Netscape3 needs to be pushed into upgrading anyway.[/color]

That's right, it is the potential customer's fault when you cannot do
business with them.
[color=blue]
> If a browser supports Javascript,
> I expect it to support the core features
> of 1.1, at least,[/color]

Why? Support for an ECMAScript version would be a more rational
expectation, as that is the standard for the language.
[color=blue]
> including the ability to swap out option objects.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> There are some assumptions you must make about the browser's
> capabilities.[/color]

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.
[color=blue]
> What if the browser doesn't implement for() loops? Do
> you check for that before using them? heh.[/color]

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.
[color=blue][color=green]
>> The library concept is not suited to browser scripting.[/color]
>
> That's absurd.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

And if the same task can be done with < 10k of site-tailored code?
[color=blue]
> Users stripping out code from a library is unnecessary and not
> recommended, because it makes for maintenance hell later if the
> library is updated.[/color]

Sending code that will _never_ be executed to remote users is
unnecessary.
[color=blue][color=green]
>> 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.[/color]
>
> So you want to re-invent the wheel each time?[/color]
[color=blue]
> What you save in download times and "superfluou s code" will easily be
> offset by increased development time and expense.[/color]

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.
[color=blue]
> Libraries and code reuse should be encouraged, IMO.[/color]

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.
[color=blue]
> Especially for users without the skills to indepdendently develop
> code to perform a function which a library could perform in a
> black-box manner.[/color]

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.

[Matt Kruse]

Re: dynamic combo boxes

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue][color=green][color=darkred]
> >> The library concept is not suited to browser scripting.[/color]
> > That's absurd.[/color]
> No, that's browser scripting.[/color]

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/

[Richard Cornford]

Re: dynamic combo boxes

Matt Kruse wrote:[color=blue]
> "Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=green][color=darkred]
>> >> The library concept is not suited to browser scripting.
>> > That's absurd.[/color]
>> No, that's browser scripting.[/color]
>
> Well, we'll have to agree to disagree on almost every point in this
> back-and-forth :)
>[/color]
<snip>[color=blue]
> I think I'm a bit more practical than idealistic.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Not all situations are the same.[/color]

At any moment the internet is always the same.
[color=blue]
> 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!).[/color]

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

<snip>[color=blue]
> ... , and if you give people the benefit of the doubt
> that they know what they need[/color]

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.
[color=blue]
> (or at least leave that to a different discussion)[/color]

And where do you propose that discussion is going to happen if it is not
right here? comp.lang.javas cript is a discussion forum after all, not a
helpdesk.
[color=blue]
> 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.[/color]

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.

[Lasse Reichstein Nielsen]

Re: dynamic combo boxes

"Richard Cornford" <Richard@litote s.demon.co.uk> writes:
[color=blue]
> 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.[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

Re: dynamic combo boxes

Lasse Reichstein Nielsen wrote:[color=blue]
> "Richard Cornford" <Richard@litote s.demon.co.uk> writes:[color=green]
>> 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.[/color]
>
> I considered it once, and came to the conclusion that there was two
> ways of handling dependent select elements that degraded nicely.[/color]
<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.
[color=blue]
> 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".[/color]
<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.

[mr_burns]

Re: dynamic combo boxes

burnsy