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
32  2658 
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
In article <ca**********@hercules.btinternet.com>, ne***********@btopenworld.com 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
Continental Translations wrote: Can anybody help me? I am trying to create two drop down menus, where
the results of the second one vary depending on what was selected in
the first one.
This is a FAQ, and should probaly be addressed in the FAQ!
There are a number of solutions available. Some are specific to the data and
screen in question, others are general solutions which can be reused on any
page where dynamic dropdown menus are needed. my solution falls into the
latter, and can be found at http://www.javascripttoolbox.com/dynamicoptionlist/
Be aware that these client-side javascript solutions will fail for browsers
that do not support javascript, and depending on your requirements, you may
want to include a server-side solution which duplicates the same behavior.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Continental Translations wrote: Can anybody help me? I am trying to create two drop down menus, where
the results of the second one vary depending on what was selected in
the first one.
This is a FAQ, and should probaly be addressed in the FAQ!
<snip>
It is certainly a regularly asked question, I don't know that it is
frequently asked in the sense that most other FAQ questions are as it
seems to come in spates with a couple of months in-between. But maybe it
is (though you will have to follow FAQ request procedure if you want it
considered for the next review).
But what would the FAQ say on the subject: "Don't design this
requirement into a project as it cannot be satisfactorily implemented."?
There isn't an implementation that I would recommend, I have only seen
three that even attempt to address the degradation issue and none of
them are that usable in their degraded state (Lasse Reichstein Nielsen's
being about the best, but it sacrifices some (old) browser
compatibility).
Richard.
Richard Cornford wrote: (though you will have to follow FAQ request procedure if you
want it considered for the next review).
Or maybe I'll just create a simple HTML page addressing the issue.
A lot of the same responses are posted to this group, not just for this
question, but for many others. It would be helpful to summarize the
responses into a single HTML page that users could be directed to. Even if
it's not in the official FAQ.
But what would the FAQ say on the subject: "Don't design this
requirement into a project as it cannot be satisfactorily
implemented."?
No, it would point out a number of resources which solve the problem, both
with simple examples (storing options in arrays and simply creating new
Option objects) and complex solutions (like my library and others).
It would also point out that there are potential problems with relying on
this functionality, explain why, and gives examples of situations where this
must be taken into consideration and situations where it's not a concern.
There isn't an implementation that I would recommend
That's because you try to fit everything into a box that you are comfortable
with :)
I have only seen three that even attempt to address the degradation
issue
Of course, the degradation issues doesn't always need to be addressed. If a
summary of the issue pointed out that for environments where browsers are
fixed, or javascript is required, or degrading gracefully is not important,
then the user could simply select which pre-existing solution fitted their
needs the best.
and none of them are that usable in their degraded state (Lasse
Reichstein Nielsen's being about the best, but it sacrifices some
(old) browser compatibility).
When I get time to play with it, I'll build an example that degrades nicely
for you, using my library.
In short, it works like this:
------------------------------------------------------------------------
<select name="first" onchange="if (browser has enough capabilities) { call
dynamic population code }">
<noscript>
<submit><!-- Go back to server to re-draw page with second option-->
</noscript>
<script>
if (browser has enough capabilities) {
document.write(other select elements)
}
else {
document.write(submit button)
}
</script>
------------------------------------------------------------------------
Do you see any problems with such a solution?
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote: (though you will have to follow FAQ request procedure if you
want it considered for the next review).
Or maybe I'll just create a simple HTML page addressing the issue.
A lot of the same responses are posted to this group, not just for
this question, but for many others. It would be helpful to summarize
the responses into a single HTML page that users could be directed
to. Even if it's not in the official FAQ.
You (and indeed anyone else who feels like it) are at liberty to create
HTML pages for inclusion in the FAQ notes. Obviously the results would
have to be subject to public review for accuracy, completeness and
general suitability for inclusion (and subject to future editing if that
was considered necessary as circumstances change).
But what would the FAQ say on the subject: "Don't design this
requirement into a project as it cannot be satisfactorily
implemented."?
No, it would point out a number of resources which solve the problem,
If you could find such resources. But you define 'solution' as only
relating to the mechanics of doing what can be done where it can be done
with client-side scripting, while I think 'solution' includes the script
design issues.
both with simple examples (storing options in arrays and simply
creating new Option objects) and complex solutions (like my library
and others).
There is quite a lot of writing in that :)
It would also point out that there are potential problems with
relying on this functionality, explain why, and gives examples of
situations where this must be taken into consideration and situations
where it's not a concern.
But are you in a position to give that information, even asses the
criteria? It isn't a couple of weeks since you stated that you didn't
think that the ADA applied to public commercial web sites in the US (and
I don't really know if it does), but in a thread where the OP posted
through a UK ISP it is the British DDA that is probably applicable.
It is difficult to judge the scope of the DDA as currently there is none
of the required legal precedents as the cases that have been brought to
date have all been settled out of court (with the web site owners paying
damages, but not admitting liability). And it will probably take the
full appeals procedure to be applied (all the way to the European court)
before anyone can be certain where accessibility is required from web
sites. But the DDA has the potential (if enough judges eventually rule
that way) to be as draconian as the Australian DDA, where I gather that
every public web site is required to be accessible and so needlessly
introducing javascript dependencies is actually likely to result in a
fine for anyone (and a big fine for commercial enterprises). Making it
an issue that Australian posters need to here about up front.
And then there is the Internet/Intranet question. Over on alt.html at
the moment there is a discussion started by an Australian developer who
has used a javascript menu implementation in an Intranet project that
inhibits the scaling of fonts (a common, but completely avoidable,
feature of javascript menus). The problem is that an existing employee
is 80% blind and cannot use the menu without scaling the fonts up (which
the menu will not allow). The other Australian developers contributing
to the thread are convinced their DDA does apply to that (and presumably
other) Intranet project(s), at lest in part because it forbids an
employer form discriminating against current and potential future
employees on the grounds of disability. (The British DDA makes a
similar requirement of employers, with some exceptions.)
This seems to make determining the extent to which the introduction of a
javascript dependency can be considered acceptable quite difficult to
judge, with regional variations such that an Australian developer wants
to avoid them, a British developer would be well advised to err on the
side of caution (at least for the time being) and maybe US developers
really don't have to think about it (beyond their personal morality).
And then there is the rest of the world, where any country may have, or
introduce, its own legislation on the subject.
<snip> When I get time to play with it, I'll build an example that degrades
nicely for you, using my library.
In short, it works like this:
----------------------------------------------------------------------
-- <select name="first" onchange="if (browser has enough capabilities) {
call dynamic population code }">
<noscript>
<submit><!-- Go back to server to re-draw page with second
option--> </noscript>
<script>
if (browser has enough capabilities) {
document.write(other select elements)
}
else {
document.write(submit button)
}
</script>
----------------------------------------------------------------------
--
Do you see any problems with such a solution?
NOSCRIPT is a block element so it cannot necessarily be inserted in any
context without an impact on the resulting page flow.
The second script element will probably not be in a position to properly
test whether the browser is sufficiently dynamic to facilitate the
client-side manipulation of the OPTIONs as that is only achievable by
trying it and testing the results to see if it worked. Attempting that
as the page loads will error, and even crash, some browser, from which
there is no ability to recover and write the now needed submit button.
This implementation would impose extra work on whoever was writing the
server-side scripts as they not only have to populate your javascript
data structures for the select list, but they also have to implement the
server-side fall back (and ensure that the two interface styles make
sense to the server-side code).
Richard.
Richard Cornford wrote: No, it would point out a number of resources which solve the problem, If you could find such resources. But you define 'solution' as only
relating to the mechanics of doing what can be done where it can be
done with client-side scripting, while I think 'solution' includes
the script design issues.
You can't make everyone's decisions for them. If someone is looking for a
technical solution, you provide them with a technical solution. It's up to
them to decide if it fits. If they want consulting to know whether it's the
best option, or if there are better ways to deliver content, then that's a
different issue.
When I go in to get a new muffler for my car, for example, I don't expect to
have the salesman tell me why my car is a bad choice, and why I should be
driving something else instead. That's outside the scope of the discussion.
His job isn't to provide advice to me on whether or not I'm driving the
right car. His job is to help me pick a muffler, make sure it works for my
car, and put it on.
Likewise, a provider of technical solutions should help pick the best
solution, make sure it works, and provide implementation details. If the
user's requirements are "this should work in all browsers anywhere" then
that certainly changes the situation. If the user says "it only needs to
work on IE6" then that may affect the solution selected.
If you want to function as a consultant and tell people when various
technologies should be used, and the good and bad of various design
decisions, that's cool. There's a need for that. I'd rather focusing on
providing technical solutions that can be implemented by people who have
already decided that it's what they need. It's more fun. IMO.
It would also point out that there are potential problems with
relying on this functionality, explain why, and gives examples of
situations where this must be taken into consideration and situations
where it's not a concern.
But are you in a position to give that information, even asses the
criteria?
Certainly.
If your requirement is to support all browsers, even without javascript
enabled, then you should do X.
If only certain browsers are required to be supported, then you should do Y.
If you require backwards-compatability, then you should do Z.
It's up to the person implementing the site to determine what the
requirements are. If they have to comply with some ADA or DDA rules, then
they need to know that, and understand what restrictions that places on
their choices. Then, armed with that knowledge, they can build their
requirements and select the right tool.
I'll never concern myself with what the ADA says or what the DDA says. I
will simply say, "these are the limitations of this solution. If these
aren't acceptable to you, then find a different solution."
And then there is the Internet/Intranet question. Over on alt.html at
the moment there is a discussion started by an Australian developer
who has used a javascript menu implementation in an Intranet project
that inhibits the scaling of fonts (a common, but completely
avoidable, feature of javascript menus).
Then it's that web developer's fault for not understanding their true
requirements, and finding a solution which fit them.
It's certainly not the script author's fault for implementing something that
doesn't fit someone else's requirements.
NOSCRIPT is a block element so it cannot necessarily be inserted in
any context without an impact on the resulting page flow.
<style>
noscript { display:inline; margin:0px; }
</style>
Even without css, so what?
If a person has javascript disabled, they won't see as "pretty" of a page,
but the functionality will still be there. That's what matters, right? The
developer can decide how to design around such issues.
The second script element will probably not be in a position to
properly test whether the browser is sufficiently dynamic to
facilitate the client-side manipulation of the OPTIONs as that is
only achievable by trying it and testing the results to see if it
worked.
Hmm.... if window.Option exists, and a call to it works, then an Option
object can be created. In every browser that I know of, if I can create an
Option object, I can add it to a select list. Except for Opera 5.? which has
a bug. That could be checked as a special case with browser sniffing. By
default, in case of any errors at all, the javascript mode could be turned
off.
Do you propose to _never_ add options to select lists? Because even
attempting to do so and seeing if it works will fail in some browsers in
some situations, in a way that cannot be trapped. You can't code for _every_
situation. Buggy browsers should not be supported.
This implementation would impose extra work on whoever was writing the
server-side scripts as they not only have to populate your javascript
data structures for the select list, but they also have to implement
the server-side fall back (and ensure that the two interface styles
make sense to the server-side code).
Now you're really reaching, Richard :)
Sure, it may be more work, but your argument was that it's not possible -
not that it was easy and quick.
Lots of cool things are extra work. If a person wants this functionality on
both server-side and client-side, then they can do the work.
Besides, both client-side code and server-side code would surely work off
the same back-end logic, so outputing the requirement script calls surely
would not be as much work as you would make it seem.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote: No, it would point out a number of resources which solve the
problem, If you could find such resources. But you define 'solution' as only
relating to the mechanics of doing what can be done where it can be
done with client-side scripting, while I think 'solution' includes
the script design issues.
You can't make everyone's decisions for them.
I don't even try to make peoples decisions for them. But I do try to
encourage the making of informed decisions.
If someone is looking for a technical solution,
you provide them with a technical solution.
If someone is paying me for a technical solution then I do try to create
the best technical solution that I am capable of, otherwise I would not
be able to take any pride in my work.
It's up to them to decide if it fits.
No, I would have said that it was up to them to come up with a
specification first (though not necessarily on their own).
If they want consulting to know whether it's the best option,
or if there are better ways to deliver content, then that's a
different issue.
Getting opinions on the best way of doing anything is an inevitable
consequence of using Usenet. If people don't want that then they need to
employ developers directly.
But have you thought about how this notion sits with your suggestion
that the individuals that employ javascript on their web sites should
not be expected to have more than a rudimentary knowledge of javascript?
How can someone with little knowledge of javascript make an informed
decision about the relative quality and suitability of javascript
implementations for any given context unless someone who has that
knowledge tells them what needs to be considered?
<snip> His job is to help me pick
a muffler, make sure it works for my car, and put it on.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^
See, you actually want a lot more than the abiity to demand something
and just have it handed over regardless. You want the people who have
technical skills to to bring them to the table if you don't have
them.
Likewise, a provider of technical solutions should
help pick the best solution, make sure it works,
and provide implementation details.
I don't have a problem with that in general, but helping to pick the
best solution certainly should include things like advising on the
appropriateness of the criteria.
If the user's requirements are "this should work in all
browsers anywhere" then that certainly changes the situation.
There is a running theme in your posts where you describe the people who
employ your javascript as "users". Given what you write I can see how,
from your perspective, they are users; your users at least. But they are
not users they are developers, designers, web site owners, and
ultimately clients. The user is the person sitting in front of their
browsers looking at the resulting web site. Making life easy for the
clients you consider your users isn't necessarily doing any good for the
real users.
When you say that this "changes the situation" you are implying that a
web site should not be expected to be functional on the Internet by
default. I would have thought that would be the reverse of the normal
client's expectations. My starting point would be to assume that a
public web site was expected to operate to normal Internet
interoperability standards by default and then examine the validity of
any reasoning that suggested detracting from that. It should be the
things that do introduce a dependency of some sort, such as data binding
or socket communication through applets or ActiveX that change the
situation.
But no client would specify every web browser anywhere, and no sane
developer would accept the requirement, because neither is capable of
being aware what every web browser anywhere means. There would be no way
to know if the result met that requirement and so no way of deciding if
and when the job was finished (for either party).
A specification of a list of browsers with which a commission will
function can be looked upon as a specification of test criteria that can
be used to determine that the delivered end result confirms with the
specification. But the Internet was designed around interoperability and
normal authoring principles, the application of suitable standard and
appropriate design can deliver a result that works (and should be
expected to work, even if that could not be made a specified
requirement) with browsers outside of the test set.
If the user says "it only needs to work on IE6" then
that may affect the solution selected.
When a specification says that something only needs to work on IE 6 it
means that it only needs to be demonstrated to be working on IE 6, it
doesn't mean that it must not work on any other browser, and it does not
mean that it only has to work on javascript enabled default
configurations of IE 6 either.
Anything that will cope with all configuration
permutations of IE 6 could be implemented in a way
that would work pretty much the same on all dynamic standards
compliant browsers (at minimum) for no additional effort in
script creation. Under those circumstances, and given a non-Intranet
application, it looks like the initial specification was not well
informed, or it was chosen for convenience in testing.
If you want to function as a consultant and tell people when
various technologies should be used, and the good and bad of
various design decisions, that's cool. There's a need for that.
There is a need for that.
I'd rather focusing on providing technical solutions that
can be implemented by people who have already decided that it's
what they need. It's more fun. IMO.
I could churn out javascript dependent half-ass hacks till the cows come
home, any fool could. But to implement a script such that it meets the
strictest design criteria, addresses and handles all of the issues,
exhibits planned behaviour in the face of every permutation of browser
environment and do so on a time scale equivalent to any less complete
'solution', that is a challenge. And for me a challenge is more fun.
Not to mention that you learn more from being challenged than from going
over the same ground time and again. Two years ago I was writing scripts
much like you write now, and I thought I know what I was doing, but at
least when I was introduced to the issues in browser scripting I was
willing to recognise them an learn to handle them. Your complacency is
going to mean that in two years time you are going to still be writing
scripts much as you do now, and continuing to contribute towards making
the Internet a worse place than it has to be.
It would also point out that there are potential problems with
relying on this functionality, explain why, and gives examples of
situations where this must be taken into consideration and
situations where it's not a concern.
But are you in a position to give that information, even asses the
criteria?
Certainly.
If your requirement is to support all browsers, even without
javascript enabled, then you should do X.
If only certain browsers are required to be supported, then you
should do Y. If you require backwards-compatability, then you should
do Z.
And you accuse me of trying to fit everything into a box that I am
comfortable with. This is hardly a comprehensive list of web site design
requirements, but if X is normal internet authoring with
interoperability as the goal it must also satisfy Y under most
circumstances and Z much of the time.
It's up to the person implementing the site to determine what the
requirements are.
Who is the "person implementing the site"? The owner of the site, their
business managers, the project manager, the designer, the developers?
Aren't the requirements going to be hierarchical? Is a business manager
expected to comprehend the distinction between an unnecessary dependency
and an unavoidable one, or a designer the best person to be choosing a
menu implementation (rather than just deciding what it should look like
when implemented)? Shouldn't design be a collaborative process moving
through stages from the general to the specific, with the input form the
top of the decision making hierarchy maybe diminishing and the input
from the bottom end increasing as the process moves toward completion?
<snip> And then there is the Internet/Intranet question. Over on alt.html at
the moment there is a discussion started by an Australian developer
who has used a javascript menu implementation in an Intranet project
that inhibits the scaling of fonts (a common, but completely
avoidable, feature of javascript menus).
Then it's that web developer's fault for not understanding their
true requirements, and finding a solution which fit them.
The web developer certainly could have done better in that area. But
there is your problem again, web developers don't necessarily have the
skills to judge every aspect of what they are asked to do. They may know
everything that can be known about their own specialisation and next to
nothing about another. This individual seemed mostly concerned with
server-side scripting, but that wouldn't equip him to judge a javascript
implementation or comprehend the impact on accessibility that followed
from the HTML/CSS employed by that script.
It's certainly not the script author's fault for implementing
something that doesn't fit someone else's requirements.
But the script author was utterly misguided in creating a script for use
in a browser environment that detracted from the usability of that
browser for no apparent reason. Though in practice I have no doubt that
the actual reason was an ignorance of how to do any better.
Browsers have characteristics and scripts for use in browsers should
take those into account. Fonts can be scaled to suite the user, that
isn't a secret it is right there in the menus for anyone to see.
Then again the script author may have known that the menu could be
implemented flexibly but didn't care to learn to do any better and just
offered the script up on a take it or leave it basis, and the developer,
not knowing what criteria to apply to the choice of menu script, used it
because it was there.
That happens a lot, people who don't know any better lumber themselves
with problems by choosing inappropriate scripts because those scripts
are easy to find. Not knowing what they have done until a problem
manifests itself and then not knowing what to do about it. Assuming the
consequence of the use of a poor script has an observable manifestation,
which might not be the case when, say, a needless javascript dependency
is reducing turnover for a small business site as there will be not
turnover figures without the dependency against which a comparison could
be made.
<snip> Hmm.... if window.Option exists, and a call to it works, then an
Option object can be created. In every browser that I know of, if I
can create an Option object, I can add it to a select list. Except
for Opera 5.? which has a bug. That could be checked as a special
case with browser sniffing. By default, in case of any errors at all,
the javascript mode could be turned off.
Do you propose to _never_ add options to select lists? Because even
attempting to do so and seeing if it works will fail in some browsers
in some situations, in a way that cannot be trapped.
I have told you before, you start off with the OPTIONs defined in the
HTML and you test the dynamism of the browser by trying to remove them.
Then a worst case failure leaves those OPTIONs available to the user.
The same goes for the submit button, define it in the HTML and
conceal/remove it with a script and the whole implementation is much
simpler and no longer has any path that will leave the user without the
ability to use the form.
It is defining data/content for a script in any place other than
on the HTML page that is directly responsible for *needlessly*
introducing javascript dependency in the vast majority of scripts
that suffer from it. And it is a design decision, not something that
follows from the use of javascript as such.
You can't code for _every_ situation.
I can try.
Buggy browsers should not be supported.
Is there (or has there ever been) a single web browser that does not
have a bug?
All you are saying is that if a bug cannot be handled by your scripts as
you design them then it is the browser's fault, bugs your scripts can
cope with you don't consider a problem but that does not mean they are
not there (or are not bugs).
This implementation would impose extra work on whoever was writing
the server-side scripts as they not only have to populate your
javascript data structures for the select list, but they also have
to implement the server-side fall back (and ensure that the two
interface styles make sense to the server-side code).
Now you're really reaching, Richard :)
Sure, it may be more work, but your argument was that it's not
possible - not that it was easy and quick.
No, I think you will find that I said "it cannot be satisfactorily
implemented", which is not the same as impossible, and certainly does
include a consideration of how many hoops have to be jumped through in
order to implement it.
Lots of cool things are extra work. If a person wants this
functionality on both server-side and client-side,
then they can do the work.
Which was my point. If they do it exclusively on the server these is no
extra work, and if they use a client-side implementation that degrades
there is no extra work (even if the degraded interface is not that
usable in this instance), but if they use a javascript dependent
implementation, and want reliability, they have to put work in to
compensate for the script.
A design that lumbers someone else with extra work to compensate for its
shortcoming is not a good design. In a team context designing scripts to
minimise the effort needed for their employment by server-scripting
colleagues is the best plan. And that is easiest achieved by having the
scripts manipulate the HTML (and get their date from the HTML) because
server scripting is optimised for the creation of HTML and the people
doing it know how to understand and write out HTML. While presenting
them with new and complex javascript data structures to learn and
assemble on the server is unpopular, error prone and a sure way of
needlessly introducing javascript dependencies.
Designs based around the manipulation of HTML page content also offer
easy paths of clean degradation, and consequentially facilitate
reliability in the face of any browser environment.
Besides, both client-side code and server-side code would surely work
off the same back-end logic, so outputing the requirement script
calls surely would not be as much work as you would make it seem.
Above a certain level they are the same, but the specific form input
handling is very different. In a standard form handling script the input
from the HTTP request is validated and if it validates it is processed
and some sort of result response is generated, and if invalid it is
returned to the user for correction. You plan adding the handling of
partly completed form data and the construction of incremental stages in
the multiple selection.
The handler still has to do what it would have done otherwise but now it
is also interested in the user's current stage in the selection process
and re-assembling the party completed form to be returned to the user,
and it has to know at which point the form is finished so it can do the
validation instead. And if the form doesn't validate it is going to have
to handle the possibility that the user may want to change the
selection.
It is trivial to implement a progressive selection as a wizard style
interface with back and forward options but doing it all in one big
handler for a form introduces quite a lot that needs additional thought.
Plus the turnaround on the server would be slower if the whole form was
going back and forth each time.
Richard.
Richard Cornford wrote: Two years ago I was
writing scripts much like you write now
(first of all, much of the content of my site is not what I'm writing "now",
but has been there for a while... the latest addition was the DHTML tree,
which surely follows your design ideals)
but at least when I was introduced to the issues in
browser scripting I was willing to recognise them an learn to handle
them. Your complacency is going to mean that in two years time you
are going to still be writing scripts much as you do now, and
continuing to contribute towards making the Internet a worse place
than it has to be.
Oh blah, Richard, your mantra bores me.
Considering that some of my code has been used by smany very major web sites
around the world, and my libraries have been useful to literally thousands
of web sites and saved the butts of many behind-schedule web developers, I
think you're being over-dramatic.
As with anything a person does over time, my skills have developed and I
could certainly now develop anything that you or anyone else could. I just
implemented a very slick UI using all DOM stuff that works beautifully in
all current browsers and even degrades nicely back to NN4. You'd be proud!
But unfortunately it's for a private webapp. :)
When I finish putting up content at http://www.javascripttoolbox.com/ then
I'll welcome your revised comments, because the code there will be more
representative of my current skills, and most certainly more in line with
your ideals. But as with most people with a family and kids, it's tough to
find time to even keep a web site current with new and better ways of doing
things! I know some problems in the scripts that are on my site, and I know
how to make them better and more robust, but I just don't have the time to
do so. Yet.
So quit the condescending crap. If you were offering up a bunch of solutions
for thousands of developers around the world to use and benefit from, and it
was always up-to-date and representative of the best coding ideals, then you
might be able to criticize. Offering theory - as you usually do - is much
_much_ _MUCH_ easier than maintaining a web site of examples, code, support,
and documentation.
That happens a lot, people who don't know any better lumber themselves
with problems by choosing inappropriate scripts because those scripts
are easy to find.
Would it not make sense for you to then offer "better" solutions so that
they can become popular and used everywhere?
I'm not sure you should be condemning users who offer solutions (and opening
themselves up to criticism) when you aren't prepared to offer any better
replacements. Telling the world that they are doing something wrong doesn't
carry much weight when you don't supply something better.
I have told you before, you start off with the OPTIONs defined in the
HTML and you test the dynamism of the browser by trying to remove
them.
a) This will not always work. I would _love_ for you to demonstrate this in
a cross-browser way that degrades nicely and doesn't break in any browsers.
b) The concept of "draw plain html and then go back and make it into fancy
dhtml" is good in theory, but not always in reality. I've had a number of
users complain that the screen is drawn, then "snaps" into place with a
better interface. "Why does the screen jump like that? Can you fix it?".
Things like changing a <ul> into a dhtml tree is different, because the same
structure is there. The page contents don't change drastically. You can't code for _every_ situation.
I can try.
Good luck! Buggy browsers should not be supported.
Is there (or has there ever been) a single web browser that does not
have a bug?
No, of course not.
But if you're coding for dynamic select lists, and you know that Opera 5.02
can create Option objects but not add them to select lists, then that's a
very specific bug. Users of that browser should see things break, because
that's a big problem that cannot be reasonably tested for. In those
situations, I think it's better to inform the user that their browser sucks
then to change the whole way that a script functions to support the broken
browser.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote:
but at least when I was introduced to the issues in
browser scripting I was willing to recognise them an learn to handle
them. Your complacency is going to mean that in two years time you
are going to still be writing scripts much as you do now, and
continuing to contribute towards making the Internet a worse place
than it has to be.
Oh blah, Richard, your mantra bores me.
Considering that some of my code has been used by smany very major web sites
around the world, and my libraries have been useful to literally thousands
of web sites and saved the butts of many behind-schedule web developers, I
think you're being over-dramatic.
And I've gotten a bit bored of your on-going desire to get the upperhand on
Richard. It's not going to happen, he is much more level-headed and presents
better arguments in a more informed manner. He does not resort to hyperbole
about "thousands of developers world-wide". Millions of people world-wide smoke
cigarettes too, it doesn't mean it's a good idea.
Even if you could provide audited logs proving your case, it would say nothing
about the quality of your work.
You've presented your code examples, you've made your opinions clear, you've
lost, move on.
--
| Grant Wagner <gw*****@agricoreunited.com>
* Client-side Javascript and Netscape 4 DOM Reference available at:
* http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
* http://msdn.microsoft.com/workshop/a...ence_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-deve...upgrade_2.html
JRS: In article <ca*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Thu, 10 Jun 2004 20:49:16 : It is difficult to judge the scope of the DDA as currently there is none
of the required legal precedents as the cases that have been brought to
...
And then there is the rest of the world, where any country may have, or
introduce, its own legislation on the subject.
That's all rather legalistic.
By DAA, ADA, etc., Governments have formally recognised that those with
disabilities should not be disadvantaged where that can reasonably be
avoided.
But this has been known since Man's ancestors first became near-human;
although not always implemented.
The legal requirements should be considered as indicating a bare minimum
standard - though they also provide a tool that should be usable in
reasonable safety when attempting to persuade an obdurate
employer/client of the errors of his wishes - and authors/designers
should endeavour to provide a maximum of accessibility to all of the
target readership, whether or not they are formally recognised as
disabled.
Perhaps interested organisations should provide - and advertise - a
defaults-test page.
This page would be free of CSS (but should have <big> <small> <pre> and
default of each of the prime families of fonts, e.g. monospace), and
should strongly assert that :-
* it should be comfortably readable to most people using a normally set-
up browser on default or medium settings,
* people with minor disabilities should adjust their browser defaults to
make it comfortably readable,
* other people should seek browsers or other assistance appropriate to
their condition, in order to make the material as accessible as
possible;
and that, the above having been done, all material on the Web ought to
be accessible to them (except as unavoidably prevented by their
condition), and that if it is not the blame lies squarely with the page
provider.
The above doubtless needs adjustment; but it should give the general
idea.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Grant Wagner wrote: And I've gotten a bit bored of your on-going desire to get the
upperhand on Richard. It's not going to happen, he is much more
level-headed and presents better arguments in a more informed manner.
Well, I disagree, because he _consistantly_ fails to provide examples of his
ideas in action (all theory, no code).
He consistantly refuses to discuss specific things he finds wrong in any of
my code.
He consistantly ignores the fact that not everyone is designing in an
internet mode, supporting a wide scope of browsers.
And seriously, if he thinks he is correct in his opinions on the useage of
javascript on public web sites, I think he needs to look around the web a
bit. Some hugely popular sites employing many people who are surely at least
as intelligent as Richard have chosen to do things that conflict with his
design ideals. The world is not black-and-white. Just because someone
disagrees with his ideas does not mean they are wrong or less intelligent.
I'm tired of his continued posts saying things are not done correctly, when
he offers no technical criticisms at all. When asked to do so, he refuses.
He's all talk.
He does not resort to hyperbole about "thousands of developers
world-wide". Millions of people world-wide smoke cigarettes too, it
doesn't mean it's a good idea.
That's completely unrelated. And not a hyperbole at all.
It's similar to the linux-freaks who bash microsoft on a regular basis,
pointing out how badly Windows handles a lot of things. In many cases,
they're right. But so what? Millions of people use Windows every day and it
fits their needs perfectly and enables them to work better. Just because
Windows isn't perfect doesn't mean it has no value, or that its use should
be discouraged. Quite the opposite.
Similarly, my point is this - if some of my libraries are used by thousands
of developers, and they find value in them, and there are a couple of people
who say "yeah, but that's not the ideal way to do it!"... so what? Are those
nay sayers adding the same value in ways that they find to be correct, or
are they just whining?
Even if you could provide audited logs proving your case, it would
say nothing about the quality of your work.
My point is, it's peer-reviewed. Lots of web developers use the code, and it
solves their problems. Nothing is perfect, and I don't claim that anything
of mine is. Obviously, not _every_ peer agrees with it.
But I don't put much weight in theories and opinions expressed by an
extremely negative guy whose goal in life seems to be to tell people why
they are stupid and doing things the wrong way, yet not providing his "good"
solutions up for the world to use, review, and criticize. If there are
better ways to do what my code does, then by all means DEMONSTRATE IT.
But the response to that often is, "well, you shouldn't be doing that at
all." Which is a view from Utopia. I'm sure there are countless developers a
day who receive the requirement of "there should be a popup calendar to pick
a date". You or Richard may say that's a stupid requirement that shouldn't
be implemented, but that doesn't change the fact that there are lots of
people who WILL implement it because they DO need it. If I supply a great
solution that they can plug in without spending hours of work developing it
from scratch, I've added value. And that's bad?
You've presented your code examples, you've made your opinions clear,
you've lost, move on.
heh, you can have that opinion, that's fine... but the emails I get, the
places I see my code used, and the daily donations I receive lead me to a
different conclusion ;)
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
On Thu, 10 Jun 2004 11:03:26 +0000 (UTC), Continental Translations <ne***********@btopenworld.com> 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
Here's yet another demo for this type of thing :-) http://cross-browser.com/x/examples/xselect.html
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.
Matt Kruse wrote: Richard Cornford wrote: Two years ago I was
writing scripts much like you write now
(first of all, much of the content of my site is not what I'm writing
"now", but has been there for a while... the latest addition was the
DHTML tree, which surely follows your design ideals)
I had assumed that the in-window pop-up code that you recently posted
the URL of was contemporary, as your comments and its appalling
behaviour on Opera 7 gave it the air of a work in progress. I did think
that not taking the opportunity to define the contents of the pop-ups
(at least the non-IFRAME ones) in the HTML on the page was retrograde
after your DHTML tree, but as you have repeatedly express a belief that
needlessly introducing javascript dependencies has no significance that
didn't strike me as out of character.
<snip> Considering that some of my code has been used by smany very major
web sites around the world, and my libraries have been useful to
literally thousands of web sites and saved the butts of many
behind-schedule web developers, I think you're being over-dramatic.
As you have decided to raise this weight of numbers/deployed on real web
sites thing again (when I thought that the reason you did not pursue the
argument last time was that you had spotted how hollow it was) it is
probably worth examining its merits.
The implications of the argument are:-
1. The act of deploying a script on a web site (and/or the
fact that it has been chosen by someone for deployment),
in itself, imbues that script with some additional "worth"
(value, measure of standard/quality or whatever).
2. That additional "worth" is proportional to the number of
instances of the deployment of that script (possibly
weighted by the size, importance, popularity, profitability,
or whatever, or the web sites on which it is used).
It doesn't take much examining of web sites, or knowledge of web site
development, to realise that there is one clear contender for the most
widely used scripts; from the smallest web sites to the largest, by at
least an order of magnitude, the most popular deployed scripts worldwide
are the javascript functions output by Macromedia Dreamweaver.
Dreamweaver functions are so popular that you will often see the same
one defined two or three times on the same page.
So by this measure of quality MM_findObj, MM_swapImage,
MM_swapImgRestore and their friends, are the pinnacle of browser
scripting.
However, the opinion of the Dreamweaver functions most widely expressed
on this group is that they are among the worst scripts ever written and
would be best used to illustrate how not the write javascript. Indeed I
have only ever seen one comment in favour of the Dreamweaver functions
and that stressed nothing but how general they are. A characteristic
that directly results in them being inefficient, which invariably
features in the list of arguments against them.
When a measure of "worth" ranks scripts that informed opinion denigrates
so heavily above all others that criteria cannot be a measurement of
script quality.
<snip> So quit the condescending crap. If you were offering up a bunch of
solutions for thousands of developers around the world to use and
benefit from, and it was always up-to-date and representative of the
best coding ideals, then you might be able to criticize.
By which you are saying that my opinion has no value unless I adopt your
approach to javascript authoring and start doing what you have chosen to
do. But my opinion is that your approach is misguided, so I could not be
expected to adopt it.
To only accept criticism about your approach from people who follow your
approach is one way of disregarding criticism, but it lacks any
reasonable foundation.
Offering theory - as you usually do - is much _much_
_MUCH_ easier than maintaining a web site of examples,
code, support, and documentation.
What you see as theory I regard as explanation. I don't see the
distribution of even the very best generalised javascript libraries as
the solution to the lamentable current state of Internet browser
scripting. I perceive promoting an understanding of browser scripting as
a practice, its issues and javascript as a language as much more likely
to have a positive impact in that area. Understanding is best promoted
through explanation.
If you see an explanation of the possibilities as theory then that is a
matter of perception. It doesn't matter that you do; theories can be
refuted if they are wrong, so feel free to refute if you can. Though
bare in mind that if I really am posting speculative nonsense with no
hope of implementation then the fact that I am posting it on Usenet
would normally mean that someone would nave noticed and publicly
criticised me for it (that is what happens on Usenet, as you must have
observed given that you have complained about it).
That happens a lot, people who don't know any better lumber
themselves with problems by choosing inappropriate scripts
because those scripts are easy to find.
Would it not make sense for you to then offer "better" solutions
so that they can become popular and used everywhere?
That wouldn't help much as giving someone who doesn't know what criteria
to apply to the choice something else to choose from only fractionally
increases the chances of an appropriate outcome (assuming it is a
"better" choice). While making them aware of the criteria they should be
applying to that choice significantly increases their chances of making
the right one.
I'm not sure you should be condemning users who offer solutions
"Users who offer solutions"? You mean developers?
(and opening themselves up to criticism) when you aren't
prepared to offer any better replacements. Telling the
world that they are doing something wrong doesn't carry much
weight when you don't supply something better.
When public script collection copy-n-paste is so bad, and bloated
generalised libraries little better, being supplied "something better"
is a matter of employing someone who knows what they are doing to work
on a specific problem. I cannot work on everyone's specific problems,
but I can try to increase the chances that whoever does knows what they
are doing.
I have told you before, you start off with the OPTIONs defined in
the HTML and you test the dynamism of the browser by trying to
remove them.
a) This will not always work.
Whether it will always work isn't practical to judge, but the mere fact
that the OPTIONs start off in the SELECT elements on the page massively
increases the chances that they will be available to the user in the
event of script failure or lack of browser support over any
implementation that defines the data for the OPTIONs in a javascript
data structure.
I would _love_ for you to demonstrate
this in a cross-browser way that degrades nicely and
doesn't break in any browsers.
You found a browser on which the version of mine that you have seen
didn't display its degraded interface when it failed act dynamically?
b) The concept of "draw plain html and then go back and make it into
fancy dhtml" is good in theory, but not always in reality. I've had a
number of users complain that the screen is drawn, then "snaps" into
place with a better interface. "Why does the screen jump like that?
Can you fix it?". Things like changing a <ul> into a dhtml tree is
different, because the same structure is there. The page contents
don't change drastically.
A browser that tries to render progressively can do that with pure
HTML/CSS (particularly when float:right|left are used). It is a long way
form being unaddressable.
<snip> Buggy browsers should not be supported.
Is there (or has there ever been) a single web browser that does not
have a bug?
No, of course not.
So no browser should be supported? (that will cut down the workload :)
But if you're coding for dynamic select
lists, and you know that Opera 5.02 can create Option objects
but not add them to select lists, then that's a very specific bug.
Users of that browser should see things break, because that's a
big problem that cannot be reasonably tested for.
In those situations, I think it's better to
inform the user that their browser sucks then to change the
whole way that a script functions to support the broken browser.
From the point of view of a script a browser that does not support a
particular feature (be it through a bug or otherwise) is not any
different from a browser that does not support scripting at all. If
scripts are designed to degrade cleanly then they can cope with any sort
of failure by doing what they would do on a javascript
incapable/disabled browser.
It is not a matter of supporting buggy browsers as such; the script
cannot do what it was designed to actively do, but it can cleanly
degrade.
Are you actually saying that Opera 5.02 will allow OPTIONs to be removed
from a SELECT element and new Options to be created but it will not
allow them to be added to a SELECT element? That would be a very
specific bug, but completely amenable to feature detection.
Richard.
Richard Cornford wrote: I had assumed that the in-window pop-up code that you recently posted
the URL of was contemporary
I don't recall the URL.
as your comments and its appalling
behaviour on Opera 7 gave it the air of a work in progress.
If you're referring to the popup window script, it certainly was a work in
progress, and the issues with Opera were/are known.
I've since decided to use a different approach to the whole concept. The
code was more "test of concept" than anything.
1. The act of deploying a script on a web site (and/or the
fact that it has been chosen by someone for deployment),
in itself, imbues that script with some additional "worth"
(value, measure of standard/quality or whatever).
It does. Anything that is used successfully by many people has more value
than a solution used by no one. I suppose that depends entirely on how you
define 'value'. But to me, getting a job done, meeting requirements, and
benefitting from work done is a sign of value. The "Pet Rock" surely had no
value in and of itself. But as soon as millions of people wanted one, it had
incredible value to those buying it and those profiting from it.
2. That additional "worth" is proportional to the number of
instances of the deployment of that script (possibly
weighted by the size, importance, popularity, profitability,
or whatever, or the web sites on which it is used).
True again. The more something is used, the more valuable it is to more
people. Usually.
So by this measure of quality MM_findObj, MM_swapImage,
MM_swapImgRestore and their friends, are the pinnacle of browser
scripting.
Quality != Value
The dreamweaver scripts may not be high quality in terms of coding, but they
certainly have added incredible value for a number of people who simply
couldn't have done anything dynamic without them.
A solution does not need to be perfect to have value.
Go into any consumer market for a quick lesson in this fact. Things don't
always make sense. People will sometimes prefer lower-quality solutions in
favor of more convenience, lower price, faster delivery, etc, etc. You are
implying that a solution which is not technically ideal is always less
valuable than a solution which follows all the technical ideas. But this
idea is clearly absurd!
To a new html author making a web site for their dog, adding image swapping
with a few clicks of a button is fantastic! Even if it's not technically the
best solution, they don't care. Even if there are better ways to do it, they
don't care. Even if it will break in 5% of their visitors' browsers, they
don't care. Your assumptions about how value is determined does not apply to
everyone. Even if you think they should.
When a measure of "worth" ranks scripts that informed opinion
denigrates so heavily above all others that criteria cannot be a
measurement of script quality.
Again, don't confuse value (worth) with quality.
The most technically-superior solutions are rarely the most popular or
valuable to most people.
If you see an explanation of the possibilities as theory then that is
a matter of perception. It doesn't matter that you do; theories can be
refuted if they are wrong, so feel free to refute if you can.
Here you go... your "solutions" are often ugly and unacceptable to some
people who are writing the checks.
In your "ideal" world where theories and explanations are all that need be
discussed, this doesn't matter much to you. But in the real world (which I
deal with, and which you continually ignore) it's a big factor.
bare in mind that if I really am posting speculative nonsense with no
hope of implementation then the fact that I am posting it on Usenet
would normally mean that someone would nave noticed and publicly
criticised me for it
Not necessarily. Many choose not to express themselves in public. I've
received emails with varying points of view on our discussions. :)
I don't take any of this personally (in fact, I think I benefit from having
ideas challenged and challenging those of others) so it doesn't both me to
post publicly. But not everyone is like that.
When public script collection copy-n-paste is so bad, and bloated
generalised libraries little better, being supplied "something better"
is a matter of employing someone who knows what they are doing to work
on a specific problem.
In a perfect world, maybe. In the real world, this isn't even always
possible.
From the point of view of a script a browser that does not support a
particular feature (be it through a bug or otherwise) is not any
different from a browser that does not support scripting at all.
That is completely untrue.
Sometimes bugs cannot be found or worked around via feature detection.
If calling alert() for example would crash browser X, how could you
possiblly test for that, or have it degrade gracefully for such a browser?
Are you actually saying that Opera 5.02 will allow OPTIONs to be
removed from a SELECT element and new Options to be created but it
will not allow them to be added to a SELECT element? That would be a
very specific bug, but completely amenable to feature detection.
That is exactly what I have observed.
See this url in Opera 5.02: http://www.mattkruse.com/temp/opera_options_test.html
If you can detect that the first and second links will work, but not the
third, using only feature detection, I would like to see it. I've not come
up with a good way to test for it, other than actually doing it and seeing
if it works.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Grant Wagner wrote:
<snip> ... Millions of people world-wide smoke cigarettes too,
it doesn't mean it's a good idea.
That's completely unrelated. And not a hyperbole at all.
It's similar to the linux-freaks who bash microsoft on a regular
basis, pointing out how badly Windows handles a lot of things. In
many cases, they're right. But so what? Millions of people use
Windows every day and it fits their needs perfectly and enables them
to work better. Just because Windows isn't perfect doesn't mean it
has no value, or that its use should be discouraged. Quite the
opposite.
You are saying - if many use then good - (a theory), Grant is
observing - bad (NOT good) AND many use -, and deducing - NOT <if many
use then good> - (as the (empirical) observation refutes the theory).
You are then representing that as - if many use then bad (NOT good) -
and/or - if few (NOT many) use then good -. Which are rhetorical
derivations (a "straw man" argument) not logical ones.
Similarly, my point is this - if some of my libraries
are used by thousands of developers, ...
<snip> ... . I'm sure there are countless
developers a day who receive the requirement of "there should be a
popup calendar to pick a date". You or Richard may say that's a
stupid requirement that shouldn't be implemented, but that doesn't
change the fact that there are lots of people who WILL implement it
because they DO need it.
<snip>
I have no recollection of Grant ever expressing an opinion on pop-up
calendar date pickers. And I have never said they shouldn't be
implemented, I actually think they can represent a potentially useful
enhancement to a browser based GUI (for some users).
I do think that their design should address a number of issues; starting
with the normal clean degradation issue. If they represent the only
means of entering the required information then the result is javascript
dependent, but if they are implemented to, say, activate when a user
clicks on a date entry field in a form, and act as a quick alternative
means of entering that information (appropriately formatted, etc) then
script failure does not deny the user the possibility of entering the
required date.
They are also a very pointing device orientated means of entering a
date. Which is why I described them as an enhancement for some users
(the ones using pointing devices as their primary means of interaction
with the browser; the majority) and why I would only propose activation
on a mouse click (rather than say onfocus) as that implies the pointing
device with which the pop-up calendar makes sense. A user who is tabbing
through a form using the keyboard is probably not going to want to
switch to the mouse to enter data, and providing clean degradation also
facilitates direct keyboard data entry into the fall-back HTML field(s).
Then again, the implementation might attempt to facilitate keyboard
navigation of the calendar GUI (Web Content Accessibility Guidelines
1.0 - 'AA' conformance already requires that (6.4, 9.3) and Web Content
Accessibility Guidelines 2.0 - 'A' conformance looks like it will
require it (2.1)), but tabbing through 30-odd days in a month is
probably more work than typing in the date directly (even if split
across 3 fields).
There is of course also the reliability issue when 'pop-up' means 'new
browser window' that results from the use of pop-up blockers, and the
display issues surrounding the combination of positioned DIV elements
and form fields that would arise for in-window pop-up implementations.
But they are all issues that can be addressed (one way or another) in an
implementation to produce a potentially useful cross-browser enhancement
to an HTML form.
Richard.
Dr John Stockton wrote: Richard Cornford wrote:
It is difficult to judge the scope of the DDA as currently there is
none of the required legal precedents as the cases that have been
brought to ...
And then there is the rest of the world, where any country may have,
or introduce, its own legislation on the subject.
That's all rather legalistic.
By DAA, ADA, etc., Governments have formally recognised that those
with disabilities should not be disadvantaged where that can
reasonably be avoided.
But this has been known since Man's ancestors first became near-human;
although not always implemented.
<snip>
The moral imperative; the notion that a web developer might also attempt
to conform with being a decent human being and so not want to take
otherwise avoidable actions that they knew would have harmful side
effects for the already disadvantaged.
But can you cite a specification on that? ;-)
Though it can be avoided through ignorance/unawareness/denial,
attributing responsibility to others, and appeals to Mammon.
Richard.
Matt Kruse wrote: Richard Cornford wrote:
<snip> 1. The act of deploying a script ...
<snip> It does. ...
<snip> 2. That additional "worth" is proportional to ...
<snip> True again. ...
<snip> Quality != Value
The dreamweaver scripts may not be high quality in terms of coding,
but they certainly have added incredible value for a number of people
who simply couldn't have done anything dynamic without them.
A solution does not need to be perfect to have value.
The Dreamweaver functions aren't not perfect, they are bad. They
represent almost the worst way of doing everything they attempt and the
only justification for that is that they were designed to be used by a
machine without the application of any knowledge on its part and in
response to nothing other than user actions.
Go into any consumer market for a quick lesson in this fact. Things
don't always make sense. People will sometimes prefer lower-quality
solutions in favor of more convenience, lower price, faster delivery,
etc, etc. You are implying that a solution which is not technically
ideal is always less valuable than a solution which follows all the
technical ideas. But this idea is clearly absurd!
That is not what I am implying. I am implying (saying) that your
criteria of "value" is utterly bogus. It promotes the bad over the good,
the dependent over the reliable, the ill-conceived over the well
designed and the status quo over the possibility of improvement.
Though by any rational criteria software that is technically ideal is
better than software that is not. Why did you even contemplate arguing
otherwise? If you achieve the ideal what you have is something good, by
virtue of the definition of the terms. The criteria in that case is
quality, and may be judged on nothing more than the software itself. But
identifying an ideal doesn't necessitate that all software achieve it
prior to use, that would be unrealistic. But it does provide a target to
aim for and a criteria to assess the results of the attempt to reach it.
If someone designs and implements with the goal of achieving perfection
there is actually a chance that they may reach it (sooner or later, and
achieve ever better quality software along the way), but if their goal
is your criteria of "value" what is the most they can hoped for;
MM_findObj?
To a new html author making a web site for their dog, adding image
swapping with a few clicks of a button is fantastic! Even if it's not
technically the best solution, they don't care. Even if there are
better ways to do it, they don't care. Even if it will break in 5% of
their visitors' browsers, they don't care. Your assumptions about how
value is determined does not apply to everyone. Even if you think
they should.
Amateurs can do what they like, if they never learn to do anything well
they won't have much influence on the wider word for good or ill.
Amateurs can choose what standards they wish to work to, maybe high
standards if they like the challenge, maybe low standards if they are
primarily interested in other things, or maybe something in between.
But professionals have responsibilities. You wouldn't think much of a
doctor who chose a treatment because it was popular, convenient, quick
and cheep, but failed 5% of the time, over a treatment that was reliable
and effective. Web development might not be life and death but is that
really an excuse for professional ethics so lax that they rate
convenience so far above quality?
When a measure of "worth" ranks scripts that informed opinion
denigrates so heavily above all others that criteria cannot be a
measurement of script quality.
Again, don't confuse value (worth) with quality.
The most technically-superior solutions are rarely the most popular or
valuable to most people.
Self evidently.
<snip> Here you go... your "solutions" are often ugly
Mine personally?
and unacceptable to some people who are writing the checks.
In your "ideal" world where theories and explanations are all that
need be discussed, this doesn't matter much to you. But in the real
world (which I deal with, and which you continually ignore) it's a
big factor.
You attribute ugliness and then suggest that ugliness will be unpopular
with clients. But on the javascript and CSS capable/enabled and
sufficiently supportive browsers a functional script that is capable of
cleanly degrading does not have to have any appearance characteristics
that are not identical to a javascript dependent script implementing
identical functionality. The difference comes when the browser does not
supports either script, and the javascript dependent version starts
denying the possibility of user interaction and any consequential
purchases, turnover, profits etc. While the cleanly degrading script is
facilitating continued user interaction, but at the cost of some aspects
of presentation and user convenience, that the user will not notice
because that is how they normally experience the Internet (when it works
for them at all).
You are telling me that hard-nosed businessmen are going to prefer a
site that doesn't look quite as designed but brings in money over a site
that looks pretty but is not functional, for a minority of users of
unusual browsers? These are certainly not the businessmen in my world.
My money would be on them actually choosing the version that continues
to bring in the money, if they had been properly informed of the
situation.
<snip> From the point of view of a script a browser that does not support a
particular feature (be it through a bug or otherwise) is not any
different from a browser that does not support scripting at all.
That is completely untrue.
Sometimes bugs cannot be found or worked around via feature detection.
You keep saying that, but never get round to proposing any concrete
examples and I suspect that many of the things that you believe are
untestable (see below) would prove amenable to feature detection, or
their use unnecessary.
If calling alert() for example would crash browser X, how could you
possiblly test for that,
Are you aware of a browser that crashes when you call - alert -? That
would be serious evidence of a reckless failure to test on the part of
the browser's manufacturer. However, I do get round the fact that merely
reading the - appendChild - property from an attribute object on many IE
6 versions will crash the browser, by not reading the - appendChild -
property of attribute objects (as there is absolutely no need or point).
And I also promote the use of an element's - setAttribute - and -
getAttribute - methods over any direct interaction with the attribute
objects, as they do all that is necessary, can be safely detected and
have not been reported as causing any problems on any supporting browser
to date.
Are you actually saying that Opera 5.02 will allow OPTIONs to be
removed from a SELECT element and new Options to be created but it
will not allow them to be added to a SELECT element? That would be a
very specific bug, but completely amenable to feature detection.
That is exactly what I have observed.
See this url in Opera 5.02:
http://www.mattkruse.com/temp/opera_options_test.html
If you can detect that the first and second links will work, but not
the third, using only feature detection, I would like to see it.
Unnecessary, Opera 5.02 is capable of adding OPTION elements to the
options collection of a SELECT element. You had misattributed the cause
of the failure to the ability to add the element, it is actually due to
the fact that opera 5.02 does not implement the - length - property on
the - options - collection so:-
f.test.options[f.test.options.length] = o;
- is adding a property with the name "undefined" to the options
collection, and that does not represent a meaningful action to the
browser. The - length - property of the SELECT element itself is numeric
and reporting the actual length of the options collection, so it may be
used instead. But I don't think it is worth the effort for one release
of such an old browser if a path of clean degradation exists for any
residual users of that browser.
How much time have you put into failing to identify that problem? The
first thing I did was put in:-
alert(f.test.options.length);
- and I immediately knew exactly what was going on. My next test,
changing your original line above to:-
f.test.options[f.test.length] = o;
- confirmed my suspicion and presented a possible solution.
(A first principle of feature detection is to test as near to the
problem as possible.)
My dependent select script, for all its shortcomings, still degraded
successfully to the underlying HTML on Opera 5.02 as designed, because
one of the earliest feature detection tests it does is to verify that
the length property of an - options - collection conforms to its
requirements. Undefined does not conform so the script cleanly degrades
under its own control.
As I had to download Opera 5.02 specifically to test your page (the
oldest Opera version I had was 5.12), tying my script with it
represented its first exposure to a new and clearly buggy environment.
And the fact that it behaved exactly as designed in the face of that
environment rather demonstrates that the theory (as you would have it)
about how to script for reliability in the face of unknown browser
environments is a little more practical that you would like to think it.
I've not come up with a good way to test for it,
if(typeof f.test.options.length == 'number'){
// pass
}else{
// fail
}
- would do.
other than actually doing
it and seeing if it works.
Actually adding elements (or, as I have said, preferably removing them)
and seeing if it worked is probably the only way of verifying that the
browser's DOM is sufficiently dynamic to actively support the script.
Richard.
Richard Cornford wrote: I am implying (saying) that your
criteria of "value" is utterly bogus. It promotes the bad over the
good, the dependent over the reliable, the ill-conceived over the well
designed and the status quo over the possibility of improvement.
"Value" is decided by each individual person, and by extension the general
public. For some people, the ability to implement functionality in 10
minutes yet have it break in 2% of browsers might have higher value than a
custom-built solution that doesn't break in any bowser but takes 8 hours to
code and test. For a flashy personal fun site, the deciding factor for
"value" might be a really slick interface with lots of options, and quality
of code and browser support might not be important at all.
In terms of javascript coding, I can think of a number of factors which
would contribute to a person's perception of 'value' for a given solution:
- Ease of implementation
- Browser support (including how well it degrades)
- Extensibility
- Available features
- Price/licensing/restrictions
- Support
- Quality of coding (and by extension, ease of maintenance)
- Speed
In your eyes, quality of coding and degrading gracefully are the most
important factors, above all else, right? A solution cannot have high value
without those being top-notch?
But to others, the important factors might be different. The determination
of 'value' can vary greatly. In fact, you place almost no importance on
'ease of implementation' or 'available features' (since you disagree with
the concept of libraries entirely), which others might put at the top of the
list. I argue that my solutions provide higher value to some people because
we are targeting different factors as priorities.
In an ideal world, a solution could provide all of the above. Except maybe
price, because to create such a solution for free is not something most
people would do :) (although, I'd argue that I come closer than most ;)
Though by any rational criteria software that is technically ideal is
better than software that is not. Why did you even contemplate arguing
otherwise?
Because I believe you are wrong.
Technically, I think linux is better than Windows as an OS.
However, I use Windows daily because it provides more value to me. It's
"better" for me. Even though I don't believe it's technically superior.
I can think of many other such examples that I encounter on a daily basis.
Is that something you find hard to understand?
Web development might not be life and death
but is that really an excuse for professional ethics so lax that they
rate convenience so far above quality?
heh, that is _everywhere_ in the world. How many people use Windows with
bugs and viruses and broken features, because it is more convenient than
more technically superior solutions? How many web developers receive
requests for features every day that are technically stupid, but must be
implemented because it adds convenience for the users? That's the way of
life for most software developers :)
Here you go... your "solutions" are often ugly
Mine personally?
Yes...
Your date picker script on your example page would be unacceptable to most
clients I've worked with because of the UI.
You dynamic select list script degrades nicely, but in a form that would be
unacceptable to most.
IMO.
You are telling me that hard-nosed businessmen are going to prefer a
site that doesn't look quite as designed but brings in money over a
site that looks pretty but is not functional, for a minority of users
of unusual browsers?
Perhaps. I've seen it happen. Repeatedly. Have you not?
However, I do get round the fact that
merely reading the - appendChild - property from an attribute object
on many IE 6 versions will crash the browser, by not reading the -
appendChild - property of attribute objects
So you're not doing feature detection, but rather not using a feature
entirely. Logical, of course, but it's still an example of a bug which
cannot be detected through normal means.
actually due to the fact that opera 5.02 does not implement the -
length - property on the - options - collection so:-
Hmm, that is indeed interesting, and not something I had even considered
testing, since it's such a basic feature. Well done.
How much time have you put into failing to identify that problem?
About 2 minutes, way back when I detected the problem. I didn't really try
to debug it, because I didn't care about supporting 5.02. I was left with
the (apparently incorrect) assumption that Opera5.02 wouldn't allow adding
new options to select lists. Some googling at the time confirmed my
suspicions, so I stopped. In fact, the first result in a search I just did
was http://www.quirksmode.org/js/options.html which states "You cannot
create or delete options in Operate 5.02- on Windows". I guess I wasn't the
only one to reach such a conclusion :)
At the end of the day, it's pretty clear that we have different ideas about
javascript development. I think libraries are fantastic, and have a lot of
value for many developers. You disagree. I think your code is clearly
advanced and looks technically excellent, but I also think some of it is
completely unreadable for most people (date picker code, for example). You
believe in being technically excellent first, and useable second. I believe
in the opposite.
Although you disagree with some of my approaches to development, I do
continue to develop better skills - as does anyone. I strive to offer the
most technically excellent solutions that I'm capable of, and I'm always
rethinking my ideas trying to come up with something better. It's a shame
that someone like you who is technically talented in coding isn't willing to
make implementation suggestions for scripts like mine, which are highly
useable, have a lot of features, can be easily implemented, are well
supported, and work in the way that many developers want them to. No one is
capable of creating the most ideal solution by themselves, IMO. Multiple
people working together to create the best possible solutions would be
fantastic.
In fact, I've long wanted to create a group of javascript developers who
work together to create the best functions, modules, and libraries to
perform various tasks. Some of that is in the FAQ now, but there are many
other common tasks which could be implemented and made available for every
javascript developer to learn from and use. Perhaps it's an idea that could
get started by regulars of this group.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote:
<--snip--> 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.
Where do you want to start out? It sounds interesting...
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Randy Webb wrote: Where do you want to start out? It sounds interesting...
I'd volunteer to create a mailing list.
Also, I'm creating a site and content for the URL in my sig (redirecting to
my personal site for now), and I think it would be a logical place to house
such a project. My plan for now is to put my stuff up there, but I would
certainly dedicate a portion of the site (if not the majority of it, and the
site's emphasis) to housing the collaborative efforts of a group of
javascript experts.
I envision a site which accomodates a number of different approaches to
script development. I like libraries which deliver a lot of different
functionality to end-users (developers) and are relatively easy to
implement. Others don't like this approach. But these libraries are
dependent on blocks of common functions, glued together to serve a purpose.
So others can stop at that level, and just build functions which perform
very specific tasks, but offer no functionality on their own. Even those
functions are dependent on low-level coding structures which can be made
very efficient. For the people who enjoy tighter loops and super-efficient
code, they can focus on streamlining the common functions.
I believe in doing something productive immediately, and getting immediate
results to get going. If things like this get bogged down in planning and
fighting over theories and ideals, they fail.
I would love to see a plan something like this:
1) Create a separate mailing list to communicate.
2) Get a core group of knowledgeable and experienced people on the list
3) Decide on some very basic assumptions and requirements for all code,
or at least an approach to separating solutions which offer similar
functionality but with different assumptions/requirements.
4) Build low-level functions for common functions which many
higher-level scripts are dependent on.
5) Create test cases for each function/snippet for future browser
testing of the core functionality
6) Publish the content as it gets completed for immediate peer review,
further testing, and use in real projects
Of course, this would rely on a number of talented people coming together,
cooperating, and putting egos aside. I think that's the biggest stumbling
block ;)
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote: I am implying (saying) that your
criteria of "value" is utterly bogus. It promotes the bad over the
good, the dependent over the reliable, the ill-conceived over the
well designed and the status quo over the possibility of improvement.
"Value" is decided by each individual person,
It certainly can be, but without (at least some) common criteria there
is not much point in those people trying to talk to each other about
"value". Yesterday "value" was proportional to instances of script
deployment, I don't agree but at least that is concrete enough to be the
subject of rational consideration. Today it is entirely a matter of
individual opinion.
and by extension the general public.
The general public (even just the Internet using portion of the general
public) are unlikely to have any well formed attitude towards browser
scripting. The majority will be totally unaware of browser scripting as
a distinct aspect of a web page/site, and script design should aim to
keep the role of scripting in a web page/site transparent to users.
For some people, the ability to implement
functionality in 10 minutes yet have it break in 2% of browsers
You do love stating numbers without any apparent relationship to
anything.
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.
If it is an informed decision appropriate to the context then that is
fine. Though when extremely questionable statistics start appearing in
the criteria you have to wonder how informed the decision could be.
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:
From the list you appear to be looking upon this person exclusively as a
potential purchaser (acquirer) of pre-existing browser scripts. Rather
than, say, the commissioner of browser scripts for a particular task, or
the project manager of a team, including javascript authors, creating
commercial web applications in a software house, or any of the many
other people who might have a reason for weighting these and other
factors.
- Ease of implementation
Implementation is a relatively vague term when used in this context. It
is common to talk of implementing a specification, but ease of
implementation in that context is a quality of the specification not of
the script that will be implemented from it. Ease of implementation
might also be a quality of a design, existing prior to any script that
represents the implementation.
Given the previous discussion I assume you mean ease of deployment,
employment or use in a web page/site. The ease of that is related to
various factors including the quality of the documentation (which is
independent of the script) and who is doing it.
The author of a script would usually find it trivial to deploy without
any documentation at all, while a complete newcomer might struggle even
with comprehensive and well-written documentation and a script designed
to be easy to deploy. Then there is quite a spectrum in between where
different factors contribute to ease of deployment/use, and factors
contributing to the significance of the javascript code to its ease of
deployment.
Take deployment through JSP tag libraries, for example, It would be
quite feasible to use a script implementation that was objectively
complex to set-up and initialise within a tag library because that task
would be done once by the specialist who created the tag library code.
All of the details would be completely concealed from whoever was
eventually using that tag library, allowing easy deployment of that
script by people who would be incapable of using actual javascript code
independently. But a script written with the intention that it be used
directly by those same people would do well to be as simple as a JSP tag
to employ.
So in the case of the code inside the tag library, effort put into
making the javascript easy to set-up and initialise has little reward as
it is only occasionally done, no matter how many times the corresponding
tags are used. That effort would be better directed at making the script
as well suited to its use within a tag library as possible. While effort
put in to reduce the set-up and initialisation complexity of the script
for direct deployment is very significant because that would be done
repeatedly, and by people who would not normally be expected to have
more than a minimal understanding of javascript.
- Browser support (including how well it degrades)
- Extensibility
I am not sure extensibility should be in here at all. It speaks of your
library mentality, where you want to be adding ever more and more
features. But that produces the code bloat problem that is one of the
main arguments against libraries as a concept in browser scripting.
Modularity should probably take the place of extensibility in this list.
Small, direct, re-usable components so that they can be mixed and
matched to suite the application.
- Available features
The availability of features doesn't mean much if you don't intend using
them. Beyond the need for a script to have all of the features that are
wanted/needed (specified), features that are not used are just code
bloat (and maybe higher memory/resource consumption, slower execution
and download, etc.).
- Price/licensing/restrictions
Price (or cost) certainly. Licensing and licensing restrictions are
closely related to the purchasing (acquiring) of software products.
Browser scripts themselves are not necessarily software products, they
may be, for example, created in-house and used as part of, say, a web
application product. They would still have an absolute cost (in
developer hours), and knock-on cost implications resulting from their
design. But licensing would not be a issue at all.
- Support
Again very much related to the extent to which a browser script is
itself seen as the product.
- Quality of coding (and by extension, ease of maintenance)
- Speed
Speed of execution, speed of download, creation deadlines. A DHTML
animating script needs to be fast (generally), while form validation
execution speed probably doesn't matter at all (unless it is really
bad).
In your eyes, quality of coding and degrading gracefully are
the most important factors, above all else, right?
I have never said this. I have said that quality is an absolute
characteristic of code and so can be used in objectively comparing code
(rather than your rather flexible criteria of "value"), and I have said
that quality is more likely to be achieved by attempting to achieve it.
What I do consider more important than (almost) anything else is design.
Design that is appropriate for the application, specification and the
context, design that encompasses established software design principles,
applies recognised applicable best practices, facilitates effective
testing and eases implementation (and to some extent documentation).
The stress that I place on graceful degradation follows from the
realisation that it is necessitated in a script intended for use in a
web browser in an Internet context.
Much as the author of a web application that is to operate over HTTP
needs to recognise that HTTP has characteristics that need to understood
and handled at the design stage of that application, the author of an
Internet browser script needs to recognise that browsers also have
characteristics that need to be handled at the design stage. One of
those characteristics is that client-side scripting is optional, another
is that it is unreliable when it is available. Failing to recognise
those (and other) facts, and handle them, is failing to design/author an
Internet browser script.
Graceful degradation is nothing but one of a number of design
prerequisites in scripts intended to be used in web browsers over the
Internet.
Designing for another context, say an Intranet, where client-side
scripting is not optional (because someone has decided that it is not)
and scripting is not unreliable (because only a finite set of browsers
are intended to be used) removes those factors from the list of
prerequisites. The result of such a design will not be a script suited
for use in an Internet browser context.
Clean degradation offers the only practical way of handling the optional
client-side scripting and the variation in DOMs that results in
unreliability in scripts, and it is best handled at the design stage as
attempting to bolt it on afterwards impacts significantly on many other
significant aspects of any script (ease of deployment being a pertinent
example).
A combination of good design and skilled implementation will tend to
result in a quality script, but a combination of appropriate design and
knowledgeable implementation should be enough to produce a reliable and
functional script.
A solution cannot have high
value without those being top-notch?
We are getting further away from any definition of "value" as time goes
by.
But to others, the important factors might be different. The
determination of 'value' can vary greatly.
See what I mean?
In fact, you place almost
no importance on 'ease of implementation'
That isn't what the archives would show (assuming we are actually
talking about ease of deployment again), I have actually written quite a
lot on designing for easy deployment. It should be a factor in a design.
Its significance is specific to the expected circumstances of
deployment.
or 'available features'
(since you disagree with the concept of libraries entirely), which
others might put at the top of the list.
As I said, features beyond what is needed (or specified) are potentially
negative.
I argue that my solutions
provide higher value to some people because we are targeting
different factors as priorities.
All else aside, you promote scripts you have designed without clean
degradation as Internet browser scripts, and then come up with spurious
justifications for not considering normal browser characteristics in
your design. I am just not going to see that as good (or even
appropriate) design, and targeting them at people who don't know enough
to recognise the consequences, or making them easy to deploy for those
people, is not going to change that.
<snip> 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.
If you make a judgement on technical criteria then technical superiority
relates to "better", if you choose other criteria then they rank
"better". You chose "not technically ideal" and "follows all the
technical ideas" as the characteristics for comparison, which look like
technical criteria to me (nothing else is implied about the hypothetical
scripts under discussion).
<snip> 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?
WTF has that got to do with anything? We are talking about people who
purport to be professionals providing professional services to clients.
The question would be whether a professional should be
recommending/supplying software to a client because it was convenient
for them. An ethical professional should be doing what they thought was
best for their client. There are many valid reasons why that actually
may result in recommending a Windows OS over another. But they would
relate to the circumstances of the client not the convenience of the
"professional".
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?
How do "technically stupid" and "adds convenience for users" get to
appear together in the same sentence? If something is technically stupid
it stands a very good chance of inconveniencing users. Or are you using
"users" to refer to someone other than the person sitting in front of
the browser again?
<snip> Your date picker script on your example page would be unacceptable to
most clients I've worked with because of the UI.
Specifically?
You dynamic select list script degrades nicely, but in a form that
would be unacceptable to most.
Isn't that what I have been saying from the outset; that the dependent
select list concept has the potential for clean degradation but the
degraded state is unsatisfactory as a user interface? Making a fully
server-side approach the easiest way of achieving the combination of
reliability and functionality in a task that is a fairly common
requirement, but usually pre-supposes the availability of server-side
scripting.
But in circumstances where my UI is being unsatisfactory yours is
non-functional.
You are telling me that hard-nosed businessmen are going to prefer a
^
There should have been a "not" in there.
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?
I am yet to meet a businessman (or woman) who would turn down the
opportunity to make money when all else was equal.
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.
One example from a browser that will build 10,000-odd objects for an
average web page, allow their error free use and facilitate feature
detection on all the rest of them and their properties. Appending child
nodes to attribute objects is something that does not need to be done at
all, so it is not a big deal to not be attempting it.
Feature detecting is not diminished in its practicality by locating one
or two fatal problems in arias of the DOM you would not normally be
going into.
Feature detection has grown out of a need that no other strategy came
close to satisfying. It is practical, it is implementable and it works.
And much as your assertions that it would be of no use in the case of
Opera 5.02 proved pessimistic, once you become familiar with the
techniques and the proper application of the strategy you will find that
it can handle everything you are likely to throw at it. (And it isn't as
if there is any contender as a viable alternative, short of the
acceptance of unreliability and uncontrolled failure.)
<snip> ... . 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 :)
Jim wants me to put a link to quirksmode.org in the resources section of
the FAQ. I probably will but I am not so sure it is a good idea. Finding
them peddling old wives tails doesn't help.
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.
And I didn't turn out to be alone in that opinion did I?
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).
The date picker code is not exactly formatted for being read. The
commented development version would be easier to understand, but it is
too big a script to be practical to document as an example for learning
purposes.
You believe in being technically excellent
first, and useable second. I believe in the opposite.
Do you have any specific reasons for attributing that belief to me?
<snip> 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.
I have made suggestions; I suggested you design was fundamentally
ill-suited to the environment of its application. You don't believe me
so there is not a great deal more I can do.
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.
<snip>
My experience of problem solving says: stage 1. Identify the problem.
And uses that to define what would qualify as a solution.
Richard.
Richard Cornford wrote: Take deployment through JSP tag libraries, for example, It would be
quite feasible to use a script implementation that was objectively
complex to set-up and initialise within a tag library because that
task would be done once by the specialist who created the tag library
code.
In fact, I've done exactly this. Nothing polished yet, but you can see my
playing around here:
http://www.mattkruse.com/javascript/...ipttoolbox.zip
It is my goal to have most of my scripts packaged into jsp taglibs (some
most likely tied to struts, which is what I work with on a daily basis). It
works great. It just takes _more_ time, of which I don't have enough...
How do "technically stupid" and "adds convenience for users" get to
appear together in the same sentence?
I typed them both without a [.!?] between them.
Your date picker script on your example page would be unacceptable to
most clients I've worked with because of the UI.
Specifically?
It's unlike the interface many users are used to, and it covers up the input
field. It also activates whether the user wants it to or not. Annoying for
keyboard-users who happen to have a capable browser.
Jim wants me to put a link to quirksmode.org in the resources section
of the FAQ. I probably will but I am not so sure it is a good idea.
Finding them peddling old wives tails doesn't help.
Rather, I'd say that others came to the same erroneous conclusion I did,
based on not testing assumptions we assumed would always be true (that the
options collection would have a length). Testing for the obvious could add a
lot of bloat to scripts.
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.
And I didn't turn out to be alone in that opinion did I?
Nor am I alone in my opinion.
The date picker code is not exactly formatted for being read.
s/formatted/coded/
You believe in being technically excellent
first, and useable second. I believe in the opposite.
Do you have any specific reasons for attributing that belief to me?
Magical powers of observation.
I have made suggestions; I suggested you design was fundamentally
ill-suited to the environment of its application. You don't believe me
so there is not a great deal more I can do.
My libraries are made up of a lot of smaller functions which perform
specific tasks.
Even if you disagree with combining the functions into libraries, individual
functions could be critiqued for their ability to perform the specific task
for which they were written. 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.
My experience of problem solving says: stage 1. Identify the problem.
And uses that to define what would qualify as a solution.
I have no idea how that relates to what I said.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote:
<snip> It is my goal to have most of my scripts packaged into jsp taglibs
(some most likely tied to struts, which is what I work with on a
daily basis). It works great. It just takes _more_ time, of which I
don't have enough...
Thinking about your "Available features" and "Extensibility". I was
wondering about the potential for having separate software assemble js
files from a pre-defined "library" based on only the specified required
features as a way of dealing with the code bloat problem, at least
partly.
Given a sufficiently modular design providing a number of utility
functions and a basic object with the minimal common functionality, and
then a series of augmentation methods; the software could understand the
relationships between the components and output a js file that included
any required utilities, the basic object and the augmentation methods
needed to achieve any combination of features required, but no more.
Leaving the person deploying the code using no more (or little more)
than just what was needed for the task, and so no code bloat.
That would leave you free to stuff as many features in as you wanted to
into the system because that would not impact on everyone using the
"library", beyond the extent that they actually wanted those features.
It would also allow features to be explicitly mutually exclusive in a
way that could not be achieved in a single file.
<snip> Your date picker script on your example page would be unacceptable
to most clients I've worked with because of the UI.
Specifically?
It's unlike the interface many users are used to,
I lifted the design straight from a standard piece of windows software,
so its users will be familiar, it just wasn't Outlook. I really don't
think it would be that hard to work out anyway, a calendar is a
calendar. It is not that different form some of the permutations of
yours except visually, but a bit of CCS could change that.
and it covers up the input field.
When a positioning algorithm can hit an input field it can easily be
modified to avoid it, if that was a requirement. I lent towards the
opinion that the pop-up calendar represented an alternative means of
inputting the date, so the original field is not needed simultaneously.
It also activates whether the user wants it to or not.
It activates onmouseup on the input field, so only when the user is
traversing the form with a pointing device in their hand, thus likely to
appreciate a pointing device orientated means of quickly inputting the
date.
Annoying for keyboard-users who happen to have a capable browser.
Keyboard users tend to tab between fields so they will not be seeing it
at all.
<snip> Rather, I'd say that others came to the same erroneous
conclusion I did, based on not testing
assumptions we assumed would always be true
There are people who say "make *no* assumptions about browsers". There
are some things that I would be willing to assume, the existence of -
document -, some common global functions/objects, ECMA 262 2nd edition
specified global functions/objects, but that is about it. Everything
else needs verifying first, or handling in a way that is safe.
(that the options collection would have a length). Testing
for the obvious could add a lot of bloat to scripts.
Very little seems obvious once you start looking into browser DOMs.
Suitable testing will increase the size of scripts, but isn't really
optional if the results are going to be reliable. Probably a more
significant impact follows form how that testing is implemented as the
wrong strategy can seriously burden the execution speed and efficiency
of code. The fact that extensive testing is necessary and that testing
increases the amount of code used just provides an additional reason for
not including code that is not used.
<snip> ... . I think libraries are fantastic, and have a lot of
value for many developers. You disagree.
And I didn't turn out to be alone in that opinion did I?
Nor am I alone in my opinion.
But you didn't find anyone who has demonstrated an understanding of
browser scripting to publicly express that opinion.
The date picker code is not exactly formatted for being read.
s/formatted/coded/
If I wrote code that I would have found understandable with the
knowledge that I had two years ago there would have been no point in
learning what I have learnt over the intervening period (it surprised me
that there was so much more to be learnt, but I don't regret making the
effort).
I have seen it argued, by Java programmes, that javascript should be
authored in an exclusively Java-like style. That would be possible, and
would produce code that was more comprehensible to Java programmers, but
they are not the same language and some of javascript's most powerful
features would become unavailable. And they are features that really
lend themselves well to the problems of browser scripting.
However, occasionally, when the subject of obfuscation of client-side
code has come up, I have suggested that code that fully exploits
javascript as a language doesn't really need obfuscation as anyone who
can understand how it works can write it for themselves and so doesn't
need to steal it.
But given a suitably modular and OO approach the techniques use to
implement something (however advanced they may be) don't represent a bar
to the use of that code by less skilled authors. With a properly
documented public interface the internal details of components don't
impact on their usability (so long as they work as advertised).
<snip> My libraries are made up of a lot of smaller functions which perform
specific tasks.
Even if you disagree with combining the functions into libraries,
individual functions could be critiqued for their ability to perform
the specific task for which they were written.
If you post code chances are that someone will critique it.
... . Multiple people working together to
create the best possible solutions would be fantastic.
My experience of problem solving says: stage 1. Identify the problem.
And uses that to define what would qualify as a solution.
I have no idea how that relates to what I said.
You want to create a "best possible solution". "Best" implies some sort
of ranking criteria that would differentiate between "possible
solutions". "Possible" implies realisable or achievable; a demonstrable
characteristic. And "solution" implies a problem. You won't create a
"best possible solution" until you know what the problem is that it is
going to solve.
Unless I am suffering from another of your overly flexible word
definitions and you mean something unexpected when you say "solution".
Richard.
Richard Cornford wrote: Thinking about your "Available features" and "Extensibility". I was
wondering about the potential for having separate software assemble js
files from a pre-defined "library" based on only the specified
required features as a way of dealing with the code bloat problem, at
least partly.
I've done this, and it turned out to be more hassle then it's worth. Also,
it stops being a purely javascript solution. You need some server-side
processing to assemble and deliver the javascript.
I've concluded that IMO, some 'code bloat' is acceptable. I compact my
library source to remove whitespace and comments and all that, which reduces
the size by 50%, usually. If I removed 'extra' code that I might not use on
a page, then I could maybe remove 5k or 10k from a big library. That's not
enough to even worry about, IMO.
Given a sufficiently modular design providing a number of utility
functions and a basic object with the minimal common functionality,
and then a series of augmentation methods; the software could
understand the relationships between the components and output a js
file that included any required utilities, the basic object and the
augmentation methods needed to achieve any combination of features
required, but no more.
Building a dependency chain into javascript functions and objects is a royal
PITA. I've done it, and decided it's more work than it's worth.
a calendar is a calendar. It is not that different form some of the
permutations of yours except visually, but a bit of CCS could change
that.
Your 'solution' is very limited, though. Can it change date format? Can it
parse user-entered dates and popup the calendar with the correct day
highlighted? Can you make some days unselectable? Can you make the week
start on any given day? Can month/day names be easily changed for
internationalization? Can the calendar populate 3 separate d/m/y fields?
There are a lot of features that everyday users would find handy. Adding an
additional 5k of library code to have as many of those functions available,
tested, and working is a huge advantage to many developers, and definitely
adds 'value' to the script. It also activates whether the user wants it to or not.
It activates onmouseup on the input field, so only when the user is
traversing the form with a pointing device in their hand, thus likely
to appreciate a pointing device orientated means of quickly inputting
the date.
Hey, it's a fine way to implement it, just not a way that I find very
useable. It should hide when the user clicks off of it. It shouldn't hide
the field. It shouldn't popup without the user choosing to pop it up. All
IMO.
But, I'm not trying to be overly-picking about your date picker solution. It
looks like a fine script. I'm just explaining why I lean towards the
'library' approach, and building in functionality that many people find
useful, even if a number of people will never use that functionality.
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
On Tue, 15 Jun 2004 08:26:14 +0100, Richard Cornford <Ri*****@litotes.demon.co.uk> wrote: Thinking about your "Available features" and "Extensibility". I was
wondering about the potential for having separate software assemble js
files from a pre-defined "library" based on only the specified required
features as a way of dealing with the code bloat problem, at least
partly.
Given a sufficiently modular design providing a number of utility
functions and a basic object with the minimal common functionality, and
then a series of augmentation methods; the software could understand the
relationships between the components and output a js file that included
any required utilities, the basic object and the augmentation methods
needed to achieve any combination of features required, but no more.
Leaving the person deploying the code using no more (or little more)
than just what was needed for the task, and so no code bloat.
Interesting you should say that ;-)
I have a tool (xLib) that does this for my library. Its just a beta tool
I use myself. Its a relatively simple C program which parses your
application files and makes a list of library functions used. It has a
table of function names and dependencies, and I have all library functions
in separate files, and so it builds a custom library file and applies a
little compression (optional).
This is how I create the library files that are downloadable from my site.
My choice of which functions to include in which files was just a compromise
because it makes it quicker to write the demos I put on the site. xLib makes
it easy to group certain functions I need into one file.
I even use xLib to create/update the function name and dependency table.
Mike
Matt Kruse wrote: Richard Cornford wrote:
<snip> a calendar is a calendar. It is not that different form some of the
permutations of yours except visually, but a bit of CCS could change
that.
Your 'solution' is very limited, though.
Either that, or it is very specific.
Can it change date format?
That wasn't a specified requirement, but if it was it could be added.
Can it parse user-entered dates and popup the
calendar with the correct day highlighted?
Currently it defaults to whatever is defined/enterd in the HTML, or
today otherwise. The date defaulting code would not be difficult to
modify to accept information as function call parameters, or whatever.
Can you make some days unselectable?
The resolution of unavailable dates is to the Year boundary. It could
also be parameterised if there was a need for more control.
Can you make the week start on any given day?
No more than I can turn back the tide :) But if you mean the ordering
of the day columns, yes of course I could, it would need a more complex
algorithm and more code (the current ordering is certainly the most
easily coded, and not that unexpected from a calendar).
Can month/day names be easily
changed for internationalization?
They are both in isolated Arrays so they could be swapped for other
nation/language specific dynamically or otherwise, if that was required.
Can the calendar populate 3 separate d/m/y fields?
That is what it does now (the second two being select elements).
There are a lot of features that everyday
users would find handy.
Is this user "users" or developer "users"?
Adding an additional 5k of library code to have as many
of those functions available, tested, and working is a
huge advantage to many developers, and definitely adds
'value' to the script.
You comments so far centre on the way my script is not configurable to
every permutation of possible deployment. You want me to write library
style software products for use by third parties as you do, else you
will consider the results inferior. I am not going to do that, my script
is *one* specific implementation of a date picker, a demonstration. I
could write others, and maybe re-use much of the existing code in doing
so. But I will not write an all singing and dancing, 100% configurable,
multi-UI, multi-national date picker until that is the specific
specification (so not in my spare time).
While I disagree with the concept of client-side javascript libraries it
cannot be reasonable to criticise my scripts for not exhibiting
characteristics that are only called for in client-side javascript
libraries. If my scripts did have those characteristics it would mean my
design was inappropriate for the context and they would represent ground
for criticism in themselves.
I notice that you assert that this additional flexibility can be
accommodated in 5K.
You want to be able to change the date format. How many date formats are
there world wide? How many unicode characters represent numbers and/or
digits? Can you really cope with all the possibilities in 5K?
You want to swap the language for the labels. How many languages are
there world wide? How much space will all of their month names and day
abbreviations take up? Plus the corresponding digit character mappings
for the calendar body.
You wonder if dates can be pre selected. What about color-highlighting
local holidays? Internationally? Other dates of interest/relevance? How
about highlighting week when hovering, or the day column, or both in
different colors?
You wonder if the column order can be changed. What about using rows
instead, ordered up or down (right to left) for different languages (if
that is normal for their calendars)?
You wonder how many fields it might populate. What would be the limit;
one to infinity? spread across multiple windows and frames? Different
types; input here, hidden there, the year to a select in another frame?
The first US slash separated date format in UTC, the second equivalent
local time in ISO format?
You want to have the position specifiable. Does it cover the input field
or not (or partly overlap with an offset)? If not is it going to be
above it, below it, to the left or right, offset by how much, offset at
an arbitrary angle, by pixels, em or cm? Or is it positioned relative to
any arbitrary element, or absolutely positioned. Is its position
adjusted so that it will be within the client area or might the user
have to scroll to get to all of it? Should it be dragable?
You think it should close onmousedown outside of the picker. What about
onmouseout, with a close button, onkeydown/press/up outside, onfoucs for
any other control/link? What happens if an event handler is already
assigned to any element that might be considered relevant? What if
someone wants opening onmouseover some other element?
How many other possibilities might suggest themselves? Scripting to a
specification can attempt to provide all of what *is* wanted, a library
cannot practically provide all of what *may* be wanted (even if
everything could be anticipated). A line must be drawn, and with only 5K
to play with that line is not going to be too far from where it is now.
So the library, no matter how feature packed and flexible, ultimately
defines the outcome. And the harder it tries to avoid that the more it
will become bloated with features that some may want but most will not.
It also activates whether the user wants it to or not.
It activates onmouseup on the input field, so only when the user is
traversing the form with a pointing device in their hand, thus likely
to appreciate a pointing device orientated means of quickly inputting
the date.
Hey, it's a fine way to implement it, just not a way that I find very
useable.
It should hide when the user clicks off of it.
As few as 8 lines of code will do that if the deployment context is
known not to include a document.onmousedown handler. For an unknown
context either much more code is needed or cross-browser support would
be restricted. Ultimately it is a matter of someone deciding that it is
something they want (and that implies the context of its use).
It shouldn't hide the field.
Why not? It is not as if you can do anything with the field while it is
showing (as you want the picker closed on any mousedown in the
document).
It shouldn't popup without the user choosing to pop it up.
By implication clicking on the Date field is a request to be able to
enter a date, and the date picker being easy to use with the pointing
device implied by the method of activation might easily justify making
that facility available when date entering is requested. It is really
just a matter of UI style, if someone wanted it activated otherwise that
wouldn't be at all difficult to arrange.
Richard.
Richard Cornford wrote: You comments so far centre on the way my script is not configurable to
every permutation of possible deployment.
My comments point out common requirements for developers around the world
trying to implement a date-picker popup. Having had my date picker available
for qutie some time, and having received hundreds of suggestions and feature
requests, I'm fairly familiar with the requirements that most developers
have when looking for such a script. Surely no one can meet all requirements
that anyone might have. But solving the vast majority of typical
requirements is definitely possible.
My point in raising those questions was to show that your solution is very
specific to a single set of requirements, and therefore not very useful to
very many people. My solution - although more 'bloated' with code - is built
to meet a wide range of common requirements, and therefore it is very useful
to a lot of people. This is not to knock your solution - it may be _perfect_
for someone. The point is to examine what 'value' each of our aproaches
offers to potential developers who wish to implement a date picker.
If someone wishes to implement a date picker using your philosophy of
javascript development, they would need to download your code, fully
understand it (and it is unreadable to most people), then customize it to
add the required functionality. This could be very time-consuming.
Or, they could download my library, customize the display with a few lines
of code using built-in parameters and methods, and have their requirements
met in a few minutes. And have the date picker work on a wider range of
browsers. At the expense of an additional few kb of code 'bloat'.
If you were a non-expert developer wishing to add a date-picker popup to
your page, which solution do you think you would prefer? You may disagree,
but I think most people would clearly prefer the latter. You have offered a
solution which meets the requirements of very very few developers. I have
offered a solution which meets the requirements of thousands of developers.
And that is why I build libraries, and why I think the library concept is
superior for general use and distribution than your philosophy.
I notice that you assert that this additional flexibility can be
accommodated in 5K.
Your code is 23k, mine is 34k. So, I estimated wrong - an additional 11k is
required. But that also adds many more features than what I noted ;)
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote: You comments so far centre on the way my script is not configurable
to every permutation of possible deployment.
My comments point out common requirements for developers around the
world trying to implement a date-picker popup. Having had my date
picker available for qutie some time, and having received hundreds of
suggestions and feature requests,
What proportion have you fulfilled? Did you notice the post today form
someone who wants to drag select a range of dates? I wonder how that
would work for month/year spanning ranges but I can see it being a very
realistic requirement. For example, an Intranet application for booking
holidays where nobody would ever be entitled to more than, say, 8 weeks
off at a stretch, and so the interface would never have to span more
than 3 months of dragged selection.
<snip> ... . Surely no one can meet all requirements that anyone might
have. But solving the vast majority of typical requirements is
definitely possible.
Surly it is entirely possible to meet all requirements that anyone might
have (assuming that they are technically achievable) because no matter
what those requirements may be they will be specific and finite. Your
problem is that it is not practical to meet all possible requirements in
one piece of javascript all at the same time.
My point in raising those questions was to show that your
solution is very specific to a single set of requirements,
As it was designed to be.
and therefore not very useful to very many people.
As long as it is useful in the context for which it was created then it
is doing its job.
<snip> This is not to knock
your solution - it may be _perfect_ for someone. The point is to
examine what 'value' each of our aproaches offers to potential
developers who wish to implement a date picker.
If someone wishes to implement a date picker using your philosophy of
javascript development, they would need to download your code,
Someone using my "philosophy of javascript" would have no need to be
downloading my example. They would start by reading their specification,
then design their script, then they would write it themselves.
fully understand it (and it is unreadable to most people),
That would do nobody any harm, but it is not necessary.
then customize it to add the required functionality.
It would almost certainly be more efficient (in terms of time to
implement and the resulting code) to design the script for the
requirements that apply to it than try to customise a script designed
with different requirements.
This could be very time-consuming.
Trying to reverse engineer a script that you don't understand and then
get it to do something other than what it was designed to do would be
very time consuming. You will be hard pressed to find anyone
recommending that as a development strategy.
However, given a repertoire of well tried and tested low level
functions/components/objects, an understanding of the design issues and
a familiarity of common patterns in implementation, creating a specific
script for the context and specification doesn't have to be that time
consuming at all.
Or, they could download my library, customize the display with a few
lines of code using built-in parameters and methods, and have their
requirements met in a few minutes. And have the date picker work on a
wider range of browsers.
Assuming that there specification was achievable within the inevitably
limited features of your library. Otherwise they stand a very good
chance of not being able to find them implemented in any library and
either having to find an expert to implement it for them or wishing they
had learnt how to do it themselves.
At the expense of an additional few kb of code 'bloat'.
If you were a non-expert developer ...
As I said, amateurs can do as they like, they have no responsibility to
others. Professional and non-expert do not sit well together, though I
cannot deny that web development is full of people for whom "non-expert
developer" would be a very good title (but I doubt they would appreciate
it).
Server-scripting some years ago, a client decided that one of our web
applications needed a facelift beyond what could be accommodated in the
style sheets. They commissioned a firm of HTML designers to create
templates for all of the interface pages and then had us install the
server-side logic into the templates.
Not in itself a bad idea, but the HTML designers unfortunately fell into
a category that would deserve the title "non-expert". At the time I had
been playing with GIF files and their format, and had written a
loss-less batch GIF re-compressor. It did no more than identify which
colours where actually used in a GIF image and re-arranged to color
table and image to color table mappings so that the table was a size
that accommodated all of the colours used, but was no bigger,
re-encoding the image using that new color table. Running the images
directory that came with the HTML templates through my re-compressor
reduced the total size of that directory to (literally) 1/10 of the size
that it was originally (without changing the color of a single pixel in
any of the images within it). The originals had all been created with
256 item color tables (the maximum for GIF) regardless of the number of
colors used.
The images themselves had been created without any grasp of what was
appropriate for their application. A common background color carried
over from the HTML to the images, and expressible in the CSS as a
six-character hex color value, was reproduced in the images as a four
color random dither pattern. GIF colors are 24 bit, it could have been
one flat color instead of a pattern of four, and if it had been the GIF
compression algorithms would have packed those background regions down
to a tiny fraction of there actual size (and the color tables could have
been even smaller as well). Just in the images alone we were looking at
total bandwidth wastage of two orders of magnitude.
The HTML was no better; tables within tables within tables. Our project
manager looked at all this and said: "it is what the client has provided
and we are not being paid to fix it", so we did our jobs and delivered
to schedule. The client withdrew the site after a month and reverted to
the old one because they were fed up with fielding complaints from their
users that the new version was too slow to be useable (making the whole
exercise a total waste of money for them).
And that is what you get from professionals who turn out to be
"non-expert developers"; script bloat on top of image bloat on top of
HTML bloat. It doesn't do the users any good, and it doesn't do the
clients any good, no matter how convenient it may be for those
"professionals" never to have to learn the skills they purport to be
selling.
<snip> You have offered a solution which meets the requirements of very
very few developers. I have offered a solution which meets the
requirements of thousands of developers.
I have no interest in meeting the requirements of thousands of
developers. I have an interest in meeting the requirements of a
specification, and doing the best job of that I can of that.
<snip> I notice that you assert that this additional flexibility can be
accommodated in 5K.
Your code is 23k, mine is 34k. So, I estimated wrong - an additional
11k is required. But that also adds many more features than what I
noted ;)
When I look at you calendar example page I find it importing a 58K JS
file. Because it has dependencies on - PopupWindow -, -date - and -
AnchorPosition - (oddly your dependency list for CalendarPopup doesn't
list - date - but uses its functions anyway). While examining my file
would reveal that my date picker code employs:-
InitializeMe
getElementWithId
associateObjWithEvent
getSimpleExtPxIn
HideCovered (needs getSimpleExtPxIn (or equivalent interface))
compatModeTest
getWindowState (needs compatModeTest)
- as independent low-level components that it is depended upon. As low
level components they stand a reasonable chance of also finding
themselves
being used by other non-date picker code in any actual deployment. In
much the same way as you might argue that - PopupWindow -, -date - and -
AnchorPosition - could. Though the lower the level of the component the
more likely it is to find use in other code.
But for purposes of comparison it would be more reasonable to compare
your 58K deployment code against my 23K, or your 35K date picker
specific code against my 15K date picker specific code. With those
numbers we see a difference exceeding the size of the smaller.
Although a more meaningful comparison would run both through a JS
minimiser of some sort and compare what come out to provide a measure of
unavoidable differences, as large blocks of comments don't really need
to be being sent to the user, and so impacting on bloat comparisons
(unless copyright restrictions require them to remain)). And the
minimiser would have to be a version that re-wrote identifiers so that
the differences in identifier naming styles was also removed from the
comparison.
But it remains the case that I can produce a date picker implementing
any specific features required, including any not already covered by
your library, and come up with something more or less the same size,
because different requirements would displace the code need for other
approaches. While if your library wants to cover new requirements it
needs additional features and you have no choice but make it bigger.
Richard.
Richard Cornford wrote: What proportion have you fulfilled?
I would say 80-90% of the requests I get are now covered by the library. I
only implement those features that might be useful to a number of people (or
myself). If there are unusual or unique requirements, I instruct the
developer where additional code could be plugged in.
Did you notice the post today form
someone who wants to drag select a range of dates?
Nope. That would be cool, though :)
But I'd still prefer a "start date" and "end date" interface.
Your problem is that it is not practical to meet all possible
requirements in one piece of javascript all at the same time.
It is practical to meet most of the possible requirements, and that's my
goal.
If someone wishes to implement a date picker using your philosophy of
javascript development, they would need to download your code,
Someone using my "philosophy of javascript" would have no need to be
downloading my example. They would start by reading their
specification, then design their script, then they would write it
themselves.
Of all the web developers out there, I would bet that only a small fraction
could implement a date picker resembling either one of our solutions. If
everyone wishing to have javascript functionality needed to write their code
from scratch (or pay someone to do so) then there wouldn't be much js out
there.
Expecting code to be designed and written from scratch is incredibly
unrealistic, IMO. Even if you think that is the way things should be, you
will _always_ be in the minority. If you wish to code for the minority, then
that's your approach. My approach is to give the greatest value to the
greatest number of people. There will always be a market for my approach.
I have no interest in meeting the requirements of thousands of
developers. I have an interest in meeting the requirements of a
specification, and doing the best job of that I can of that.
Which is where we fundamentally differ. But while I say your approach is
fine - just not what I choose, you say that my approach is fundamentally
flawed. *shrugs*
I've found that distributing my code to thousands of users has a lot of
benefits:
1) It makes me consider situations and environments I otherwise might have
not thought of, making my solution more robust for my own future use
2) It encourages me to add features that I might otherwise have skipped, and
in turn give me a more powerful tool to use on my own. I've added features
to scripts before, thinking it was an odd requirement. Then later, realized
I did have a use for the same thing, and it was already coded.
3) It benefits me personally by bringing traffic to my site and even being
quite nice financially, via donations.
I enjoy building tools more than anything. Small nuggets which perform
specific tasks in the best way possible, which can be plugged into
applications. In and of itself, a date picker is useless. But it's a tool to
be used to achieve a higher goal, and that's what intrigues me.
Your code is 23k, mine is 34k. So, I estimated wrong - an additional
11k is required. But that also adds many more features than what I
noted ;)
When I look at you calendar example page I find it importing a 58K JS
file.
Indeed, the example page currently links to the uncompressed version of the
code. Usually my examples link to the shortened version. For the calendar
popup, the condensed version is 34k.
(oddly your dependency list for CalendarPopup doesn't
list - date - but uses its functions anyway).
It's optional, for date formatting. If the user wishes to use that features.
- as independent low-level components that it is depended upon. As low
level components they stand a reasonable chance of also finding
themselves being used by other non-date picker code in any actual
deployment. In much the same way as you might argue that - PopupWindow -, -date -
and - AnchorPosition - could.
And that's exactly why they are separate libraries - because they serve
separate, independent functions. Inside of each of those libraries are other
smaller functions which are reusable, too.
Although a more meaningful comparison would run both through a JS
minimiser of some sort
As I do for all my code. I have "Original" which is fully commented,
"Compact" which is stripped of whitespace, etc, "Combined" which combines
all dependencies into one file, and "Combined & Compact" which does that and
also minimizes. For debugging, the original is preferred, and for production
the compact is preferred.
And the minimiser would have to be a version that re-wrote
identifiers so that the differences in identifier naming styles was
also removed from the comparison.
That's leaning more towards an obfuscator ;)
I could also trim code out of the combined code which isn't required by the
calendar popup, and make it even smaller. But I'm not that worried about
size. [heh]
While if your library wants to cover new requirements it
needs additional features and you have no choice but make it bigger.
And that wouldn't bother me. :)
At some point, if the script gets too big, I'll probably offer a "simple"
version and a "fully-featured" version.
I've even toyed with the idea of a page where you select which features you
need, and it intelligently builds the script for you, based on smart
comments and dependency listings within the code. That would be cool, IMO.
All the benefits of a big full-featured library, but with the smaller
footprint of code written for a specific situation. I don't even think the
concept would be that difficult to implement. It just takes more time...
--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/
Matt Kruse wrote: Richard Cornford wrote:
<snip> Did you notice the post today form
someone who wants to drag select a range of dates?
Nope. That would be cool, though :)
But I'd still prefer a "start date" and "end date" interface.
You might prefer it, you might even explain that it would be easier to
understand, but if the client wants drag selection of date ranges and
cannot be persuaded otherwise then someone is going to have to implement
it. That makes it a good idea for anyone likely to be on the receiving
end of the requirement to be able to create it themselves, or be
prepared to find (and fund) someone who can.
Your problem is that it is not practical to meet all possible
requirements in one piece of javascript all at the same time.
It is practical to meet most of the possible requirements,
and that's my goal.
Until you are in a position to identify *all* possible requirements it
is not possible to tell if any finite subset represents most of them. A
goal of implementing all of the common requirements makes sense, but it
makes exactly as much sense for any other date-picker library so
anything outside the common requirements stands a good chance of needing
a specific implementation.
If someone wishes to implement a date picker using your philosophy
of javascript development, they would need to download your code,
Someone using my "philosophy of javascript" would have no need to be
downloading my example. They would start by reading their
specification, then design their script, then they would write it
themselves.
Of all the web developers out there, I would bet that only a small
fraction could implement a date picker resembling either one of our
solutions.
Web developers cover a considerable range of skills. HTML/CSS
specialists, server-side scripting specialists, etc, largely could not
implement a javascript date-picker. It would make about as much sense
asking them to as it would to ask an HTML/CSS specialist to write an
EJB. But for people who know javascript and a bit of DHTML it isn't a
massive problem. It is basically putting the days of a given month into
appropriate positions in a grid, showing it to the users and doing
something when the user clicks on a number. The specification should
fill in any other interface requirements and that just leaves a number
of issues to be handled that may or may not become significant depending
on the context of use.
OK, there are not that many who could do it the way I did (and not all
of those would choose to), and there will be some who haven't got to
grips with basic javascript objects sufficiently to do it your way. But
a date picker could be implemented in a purely procedural way and do its
job adequately. There may be objectively better of worse ways of
designing a date picker scripts, and more or less skilled
implementations possible, but I am inclined to think that someone who
could not make one at all should not be working in a client-side
scripting related capacity on a web site (working in the sense of; in a
professional capacity).
If everyone wishing to have javascript functionality
needed to write their code from scratch (or pay someone
to do so) then there wouldn't be much js out there.
When the vast bulk as the copy and paste javascript code that is out
there is somewhere between poor and actively harmful that wouldn't
necessarily be a bad thing.
Expecting code to be designed and written from scratch is incredibly
unrealistic, IMO.
Nobody but a complete beginner would write anything from scratch. The
process of acquiring any level of skill in javascript entails the
creation of numerous scripts of various sorts, and it doesn't take long
to start seeing recurring patterns and re-using existing functions
instead of re-writing them. How far that gets taken would depend on the
level of experience of the programmer and their grasp of applicable
programming design practices and the like.
Even if you think that is the way things should be,
you will _always_ be in the minority.
Maybe, there is always considerably more potential for things to be done
badly than well.
If you wish to code for the
minority, then that's your approach.
Being in a minority is not the same as coding *for* a minority. How does
cross-browser coding aimed at achieving 100% reliability, combined with
exploiting the maximum of available script functionality from any
browser, qualify as coding for a minority? There are two groups that I
should be coding for, the users (of the browser) and the client
(individual or company). For the first group I am very patently coding
for the majority (in trying to accommodate all of them) and coding for
the second group is obviously coding for a minority as they are each an
distinct entity.
<snip> Which is where we fundamentally differ. But while I say your approach
is fine - just not what I choose, you say that my approach is
fundamentally flawed. *shrugs*
Yes, the fundamental flaw is that you want to place in the hands of
someone with negligible browser scripting skills a lump of functionality
wrapped up in a form that they will find easy to deploy, and then expect
that individual to asses the suitability of it for the context of its
use, comprehend the consequences of its design (the code bloat an so
on), recognise and mitigate any dependencies by implementing suitable
browser testing and clean degradation and basically sort out everything
pertinent to any application of the library in a specific context.
These are mutually exclusive anticipations, the people who the libraries
are targeted at don't have the skills to even recognise the consequences
of what they are doing let alone handle them. The consequences of
needless javascript dependencies, pop-up window use, restricted browser
support, etc. are going to carry right through deployment straight onto
public web sites, where they will start detracting from the usability of
those sites, and from there they will detract from the achievement of
the aims of whoever commissioned the site (be they commercial or
otherwise). The client may never notice this; they way be completely
happy with the outcome (only ever viewing their site on javascript
enabled IE 6 and anticipating that the rest of the world dose likewise),
but that doesn't mean that it didn't happen or that its impact isn't
negative.
So in the end all you might be doing is saying to someone who doesn't
know any better "here is something that you can use to give your client
(who doesn't know any better either) the impression that you have done
your job, without any knowledge or effort on your part". And yes, that
is going to be very appealing to probably many thousands of "non-expert
developers". But using the library alone doesn't mean they have done
their job.
There will inevitably also be circumstances where a completely competent
developer decides that your library entirely fits the context of its use
and deploys it in a way appropriate to that context. I suspect those
developers will also be in a minority.
I've found that distributing my code to thousands of users has a lot
of benefits:
1) It makes me consider situations and environments I otherwise might
have not thought of, making my solution more robust for my own future
use
Yet somehow you missed the possibility of browsers having javascript
switched off or not supporting it, their ability (and the need for)
scaling fonts, and the existence of entire categories of javascript
capable browser.
<snip> 3) It benefits me personally by bringing traffic to my site
and even being quite nice financially, via donations.
<snip>
There is nothing like a financial incentive. Didn't someone mention
cigarettes recently?
Richard. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: chart43 |
last post by:
I have question about the technique for css dropdown menus described in
http://www.alistapart.com/articles/horizdropdowns/. Based on an html list,
it has a few items in a 1st order list and further...
|
by: sandy |
last post by:
This sounds like a frequently asked question, but I
didn't find the answer in any faq I've looked at.
I have a question about the wisdom of using
(javascript generated) dropdown menus.
...
|
by: Ian Davies |
last post by:
Hello
I have two drop down menus in my php script. The items displayed in the
second is dependent on which item is choosen from the first i.e. the choosen
item from the first filters the items in...
|
by: ACaunter |
last post by:
Hi there,
can someone please tell me what the easiest way to have a dropdown menu bar
positioned on the screen
(eg. Home, company, ... , contact us)
then when the mouse goes over then, the sub...
|
by: Patrick Cambre |
last post by:
Hello all,
I just registered with the forum. Glad to be with you all!
During the last few days I have been improving my website with dropdown menus. I found this one at...
...
|
by: nishac |
last post by:
Can anyone suggest me how to make my drop down menu work in IE7 too.Its working in other browsers.On mouse over the submenus should be displayed.Am attaching my css code hereby.Anyone please check...
|
by: torquehero |
last post by:
Hi all :)
I have created a horizontal navbar using Xara Menumaker. The Menu items have several dropdown menus. Its a javascript. When the mouse cursor is moved over any menu item, a dropdown...
|
by: Sky |
last post by:
I have an Access 2003 front-end database with custom toolbars. The toolbars
work fine.
One annoying feature is that at the far right edge of each custom toolbar
there a small dropdown arrow....
|
by: pedalpete |
last post by:
Hey Gang,
More difficult to describe this than see it, so here's a link which shows the issue I'm having
http://zifimusic.com/testing/broken-hovers.html
I've been looking at this for quite a...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
