two dropdown menus

Continental Translations · Jun 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

Kien · Jun 10, 2004

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

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

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

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

Thanks all

Hi,
Go here

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

HTH Kien

kaeli · Jun 10, 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--

Matt Kruse · Jun 10, 2004

Continental said:
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.

Richard Cornford · Jun 10, 2004

Matt said:
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.

Matt Kruse · Jun 10, 2004

Richard said:
(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>
</noscript>
<script>
if (browser has enough capabilities) {
document.write(other select elements)
}
else {
document.write(submit button)
}
</script>

Richard Cornford · Jun 10, 2004

Matt said:
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).

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.

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

Matt Kruse · Jun 10, 2004

Richard said:
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.

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.

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.

Richard Cornford · Jun 11, 2004

Matt said:
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?

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.

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?

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.

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

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.

Matt Kruse · Jun 11, 2004

Richard said:
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?".

I can try.

Good luck!

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.

Grant Wagner · Jun 11, 2004

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

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

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

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

--
| Grant Wagner <[email protected]>

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

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

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

Dr John Stockton · Jun 11, 2004

JRS: In article <[email protected]>, seen in
Richard Cornford

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

That's all rather legalistic.

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

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

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

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

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

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

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

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

Matt Kruse · Jun 11, 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yann-Erwan Perio · Jun 12, 2004

Matt Kruse wrote:

Hi,

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

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

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

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

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

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

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

Regards,
Yep.

Richard Cornford · Jun 12, 2004

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

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

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

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

The implications of the argument are:-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Users who offer solutions"? You mean developers?

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

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

a) This will not always work.

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

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

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

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

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

No, of course not.

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

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

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

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

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

Richard.

Matt Kruse · Jun 13, 2004

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

I don't recall the URL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Not necessarily. Many choose not to express themselves in public. I've
received emails with varying points of view on our discussions.

I don't take any of this personally (in fact, I think I benefit from having
ideas challenged and challenging those of others) so it doesn't both me to
post publicly. But not everyone is like that.

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

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

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

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

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

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

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

Richard Cornford · Jun 13, 2004

Matt said:
Grant Wagner wrote:

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

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

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

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

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

<snip>

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

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

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

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

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

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

Richard.

Richard Cornford · Jun 13, 2004

Dr said:
That's all rather legalistic.

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

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

<snip>

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

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

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

Richard.

Richard Cornford · Jun 13, 2004

Matt said:
Richard Cornford wrote:

It does. ...

True again. ...

Quality != Value

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

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

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

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

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

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

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

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

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

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

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

Self evidently.

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

Mine personally?

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

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

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

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

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

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

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

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

If you can detect that the first and second links will work, but not
the third, using only feature detection, I would like to see it.

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

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

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

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

alert(f.test.options.length);

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

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

- confirmed my suspicion and presented a possible solution.

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

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

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

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

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

- would do.

other than actually doing
it and seeing if it works.

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

Richard.

Matt Kruse · Jun 14, 2004

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

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

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

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

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

In an ideal world, a solution could provide all of the above. Except maybe
price, because to create such a solution for free is not something most
people would do

(although, I'd argue that I come closer than most

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

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

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

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

Mine personally?

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

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

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

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

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

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

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

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

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

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

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

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

Translater + module + tkinter	1	Feb 16, 2023
Add Image and label dynamically inside the dropdown	2	Mar 11, 2022
<Button ...> display is fine, except for two things	1	Oct 23, 2023
How to add dropdown selected data to table using jquery	2	Jul 2, 2022
Multi select options in a menu	1	Oct 30, 2022
Can anyone please help? HTML - two tables applying different styles	4	Dec 1, 2020
Dropdown menus in FireFox	1	Jan 25, 2007
Dynamic dropdown menus	0	Aug 29, 2003

two dropdown menus

Continental Translations

Kien

kaeli

Matt Kruse

Richard Cornford

Matt Kruse

Richard Cornford

Matt Kruse

Richard Cornford

Matt Kruse

Grant Wagner

Dr John Stockton

Matt Kruse

Yann-Erwan Perio

Richard Cornford

Matt Kruse

Richard Cornford

Richard Cornford

Richard Cornford

Matt Kruse

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads