Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > two dropdown menus

Reply
Thread Tools

two dropdown menus

 
 
Continental Translations
Guest
Posts: n/a
 
      06-10-2004
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


 
Reply With Quote
 
 
 
 
Kien
Guest
Posts: n/a
 
      06-10-2004
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/go...ndexForms.html

HTH Kien

 
Reply With Quote
 
 
 
 
kaeli
Guest
Posts: n/a
 
      06-10-2004
In article <ca9f5u$apg$(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) 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[i]);
o.appendChild(document.createTextNode(firstChoices[i]));
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][i]);
o.appendChild(document.createTextNode(secondChoice s[val][i]));
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

 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      06-10-2004
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/


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      06-10-2004
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.


 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      06-10-2004
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/


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      06-10-2004
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.


 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      06-10-2004
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/


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      06-11-2004
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.


 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      06-11-2004
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/


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dropdown Menus Color balado Firefox 0 07-01-2005 07:12 PM
DropDown Menus =?Utf-8?B?QUNhdW50ZXI=?= ASP .Net 1 02-03-2005 04:09 PM
Select menus above flyout menus? help? news.west.cox.net HTML 8 12-09-2004 12:54 PM
Help with dropdown menus. > AD xMenu Hardeep Rakhra HTML 7 01-09-2004 12:54 AM
Best Software to Create Dropdown Menus? Maflu HTML 7 12-26-2003 03:22 AM



Advertisments