Javascript Best Practices Document v1.0

[Richard Cornford]

The point you missed: Not everyone wants to understand
javascript. Some just want to take advantage of its
features by implementing packaged solutions.

And the point you miss is that the wants and desired of an individual
are not, in isolation, sufficient to justify action on the part of those
individuals. There is a reason that responsible parents do not let their
children say up all night whenever they want to, and do not let them eat
what they want to eat whenever they want to eat it. And as adults, when
we are expected to apply some personal judgement in assessing the wisdom
of acting on our every whim, we all live under a legal system that makes
it very clear that some wants should never be gratified.

If people don't want to learn to understand javascript that is fine, all
they have to do is never use javascript. But the desire to use
javascript without an understanding of how to use it has real, harmful
consequences. In a non-professional context those consequences don't
mater too much, people should be allowed to do harm to themselves (only)
if that is their desire, but when someone is being paid (a fee or wages)
there clients/employers have a right to expect them to know enough not
to be doing harm by their actions.

I encountered yet another example of this on Friday when a friend of one
of my mangers, who happens to run his own small business, asked me to
look at his recently re-designed web site and see of there was any
apparent reason why it had dropped out of the Google listings following
the re-design. Apparently he had notices a significant drop in enquires
(in a business where a few enquires now means the possibility of no work
in a couple of months time) and in investigating possible reasons he had
noticed the change in Google's placing of the site, and that the drop in
enquires and change in google rankings had followed the site re-design.
None of the content of the site had changed a word, just the way in
which it was presented. A task undertaken by a 'professional' web
designer in exchange for a fee.

I looked at the HTML of his home page, and I looked for links into the
rest of the site. There were none. Instead all of the navigation into
the rest of the site was handled by a javascript menu, with the link
URLs defined in an external JS file. It wasn't even a complex
(drop-down, expanding tree, or similar) menu, just rollover effects. It
could have been done entirely with CSS that even IE would understand an
act upon. But no, a combination of wanting to use javascript without
understanding it and the availability of a pre-built menu script were
enough to allow a 'professional' web designer to take a fee for
significantly harming the future viability of her client, risking the
livelihoods of its employees and forcing it pay a similar fee to someone
else to rectify the situation.

I can understand that individuals may not want to take time and effort
to learn particular technical skills, but I cannot see that as
justifying their going on to perpetrate unskilled applications of the
technologies when the consequences are so predictably harmful.

Your statement is as ridiculous

Not as a response to the statement of yours that it followed. You have
edited out its context (and failed, again, to mark that eddit).

as saying that if it weren't practical for people to learn
to repair their own cars, we wouldn't have auto mechanics.
It's not, in fact, practical for many people. I didn't say
it was not practical for anyone.

Your statement was: "The idea of spending many hours learning a
programming language is not at all practical". That is a general
statement without qualification, and as the consequences of its being
true contradict the empirical evidence it is therefor a false statement.

I disagree.

You are solving the specific case each time a new one
comes up.

Not each time, only the fist time. Fortunately specific cases do tend to
reoccur on a regular bases. While some of the possible permutations of
the general case may be extremely uncommon.

I find it to be more challenging, rewarding, and beneficial
to try to solve the general case (as much as possible) and
then apply it to the specific case at hand.

You are fixating on the problems of general algorithms. Which is not
that surprising as general algorithms are a prerequisite of general
libraries. The general problem that I am interested in is finding an
optimum code authoring strategy. And one of the issues that I need to
address in achieving that is avoiding the problem of the general
algorithm. The general algorithm may be ultimately re-useable, if it can
actually be achieved, but it is often big, often slow, and sometimes an
impossibility.

In looking at strategies the observation that code is ultimately never
used in a general context allows the issues to be avoided entirely. But
obviously re-writing everything for each specific context is not
efficient, as it eliminates the potential for code-reuse.

My answer to the problem is to build application specific code on top of
re-usable low level components that provide an interface to the
browsers. Such that those low-level components can be specifically
appropriate to the context of their use, but if the context changes they
can be replaced with a different component proving the same public
interface.

The challenge in that is designing an interface that provides the
necessarily information/actions while allowing the component that
provides it to have various diverse implementations.

The result is code that is:-

1. Re-usable, taking advantage of the fact that specific contexts do
reoccur in web development (particularly the common ones).
2. Fast in executing, because it is not trying to take account of
possibilities that are not present in the particular context.
3. Reliable, because it is possible to rigorously test such components
in isolation and so be confident that they do work as designed in the
context for which they were designed.
4. Easily maintained, because changes in their context can be
accommodated by swapping one reliable and well-tested component with
another providing the same interface and so not impact upon any of the
higher level code at all.
5. Small, because excluding consideration of the conditions that do not
apply to a specific context allows the corresponding code to be omitted.

While the general algorithm might be re-usable, and if it is a full and
correct algorithm it may also never need maintaining, but in attempting
to be general it cannot help but be slower and bigger. And rigorously
testing a truly general algorithm means exposing it to all of the
possible permutations, including the ones that are so unlikely that they
may never be encountered in a real context. Indeed, writing re-usable
context specific components as and when needed may mean never having to
tackle the more obscure possible permutations at all, while the quest
for the general algorithm pre-supposes the handling of all such
permutations form the outset.

If someone asks, "how do I find the position of my object
on the page?" and you supply the simplest solution which
will work on their example page, you may not be helping as
much as you could.

I wouldn't respond to such a question by supplying anything.

Such a question would be a joke if it was intended to be a specification
for a browser scripting task, certainly a long way short of something
that could be analysed, designed and implemented.

If the question was asked on this newsgroup it would probably be best
answered with a request for more information. But might instead warrant
a discussion of the properties, object and methods available to provide
position and dimension information, and the factors influencing their
application in determining the absolute position of an element.

It is perhaps significant that you have decided to pick on this
particular task, as you appear to be getting increasingly bitter about
the fact that nobody seems willing to help you write a general
position/dimension reporting algorithm. Though I must remind you that
when you asked the specific question I did tell you that un-resolvable
contradictions made the general position/dimension reporting algorithm
an impossibility. As it happens I have changed my mind about that
because I have seen a was of resolving those apparent contradictions,
but the resulting algorithm is so convoluted that I suspect it would
have to apply a couple of thousand lines of code to each
node/node-ancestor in the DOM. The result might work, but would be too
slow to be practically used in any of the contexts where I have been
interested in knowing elements position/dimensions.

Consider some of the factors involved in the general position/dimension
reporting algorithm:

There is the CSS 'display' property, which may have any of the values;
inline | block | list-item | run-in | compact | marker | table |
inline-table | table-row-group | table-header-group | table-footer-group
| table-row | table-column-group | table-column | table-cell |
table-caption | none | inherit, and any value may be assigned to any
element at any time. So whenever the display value may influence the
calculation of positions and dimensions (which it does) then the
influence needs to be determined on a node by node bases and taken into
account. Of course the odds (even the rational) of someone switching the
display property of an element from 'table-footer-group' to 'compact' in
any real context are extremely low. But that is one of the problems with
the genial algorithm, you have to account for all of the possibilities
or it is not truly general.

Then there is CSS 'position', which may be static | relative | absolute
| fixed, and can also be changed at any point (at least on some
browsers). Combine that with the fact that any element can be moved in
the DOM from one point to almost any other and it is quite clear that
the general algorithm needs to re-calculate the positions and offsets
for each node that it takes into account when calculating positions for
each individual position it calculates.

And the above CSS properties may be mixed with; border-collapse,
border-spacing, empty-cells, float, list-style-position,
list-style-type, marker-offset, table-layout, list-style to produce more
permutations of layout behaviour, and that is without considering the
influence of borders, padding, margins and scrolling.

Summing up the offsetTop/Left of the offsetParents works in the simplest
case, but CSS can have a huge influence on where those offsets are taken
form and the general algorithm needs to be taking that into account.

Abandoning the concept of a general algorithm and working with only the
factors pertinent to an actual context massively reduces the problem,
and allows for possible optimisations in the code that is used. And
doing so with a low level component providing an interface to the
position/dimension information retains the flexibility of the
theoretical general algorithm by allowing the component to be swapped
with one tailored to any other specific context.

Consider, for example, a real context where it is known that no page
elements will have borders, that the HTML and BODY elements will have
zero padding and margins, that all tables will have -
border-collapse:collapse; - and - border-spacing:0; -, that no display
style will be switched from its default to anything but none, and back
again, that no position property will be switched at all, that no
overflow property will be set to auto or scroll and that no element will
be moved in the DOM. The remaining permutations are so reduced that not
only can an appropriate algorithm be easily implemented but it can also
be heavily optimised to minimise the work done to aquifer each
position/dimension.

It may sound like a very restrictive context, but it does apply to a
great many real web sites, and slightly different permutations of
restrictions cover huge numbers of real web sites. All without ever
having to tackle the general problem of accounting for the influence of
all possible permutations.

Tomorrow, if they introduce scrollable areas into their page,

Tomorrow? Real web sites are not radically re-designed at the drop of a
hat. If a design is such that scrollable areas are a possibility then
that is part of the context from the outset, and they may or may not
appear on any specific page. If the design suggests (or the designer
states) that no page divisions will be scrollable then the introduction
of such arias implies a significant re-design. And a significant
re-design is likely to break any pre-existing javascript anyway.

change their layout with CSS, or put some browsers into
standards mode, your solution may break.

It won't break, it will require that the pertinent component be swapped
for one suited to the new context. And given that this happens in the
context of a significant site re-design that is not particularly
unexpected, as whoever deployed the original component understood its
limitations and know the re-design will take it outside its specified
boundaries.

And the person will once again have no idea to fix it,

But If they understood why and how they were using the code in the first
place they would understand how to fix it.

because you gave them a very limited-scope solution which
can't be applied in varied situations.

And what did you supply them with? You gave them code that you clamed
was a general solution (or, more realistically, a 'partial general
solution' (nonsense though such a claim would be)) and it will also
break in the face of particular site re-design changes. And you pretty
much grantee that the individual using your script will not know how to
fix it.

Instead, you can solve the general case which also happens to
solve their specific example.

If you can solve the general case. And assuming that the solution is
viable. I tend to find that when I want to know the position and
dimensions of an element I want that information about a group of
element more frequently than 15 times a second (preferably 24 times).
The bulky, slow, general position/dimension algorithm just cannot
deliver the required performance, because it has to take into account so
much, and do so for each node/node-ancestor.

Then, when their page changes, they don't need to change their
code, because the general solution already considers it correctly.

Again, if you can solve the general case.

The few extra k of
code which is not actually executed in each case is easily
offset by the fact that you don't need to go back and re-visit
the code to solve the new specific case, or change the code
used every time your layout changes.

The stuff that doesn't ever get executed is only the parts that can be
seen to apply to other browsers and the alternatives to things that can
be decided just once and cannot be dynamically changed (such as
standards/quirks mode). The rest, everything that can be influenced by
dynamic manipulation, needs to be re-calculated continuously. The truly
general algorithm must account for all of the possibilities or it is not
general.

The obvious fact to me is that most people prefer the
approach taken by me and many others.

Most people wouldn't have a clue hat you were talking about if you asked
them. This is a question that is only even of interest to a minority of
web developers. So that is a minority of a minority of people.

You may not, and that's fine, because obviously you have
the time and talent to do things your own way.

The question of time is a significant motivating factor in seeking an
effective and efficient strategy. As I have already said, my time is
allocated to projects for the next year, each one with a deadline, and
each followed by another with its own deadline.

... . I don't hear anyone saying, "Thank god I didn't
implement a packaged solution, but instead spent the last
3 months learning and experimenting with javascript so I
could build up my own low-level function library and solve
the specific requirement that I had 3 months ago!"

That is not something you are likely to hear. But you don't have to read
this group for long to see many examples of people who have been using
pre-packed libraries to give the impression that they could use
javascript and have now been asked to do something that they cannot find
pre-packaged and are asking for help meeting a deadline that they could
have met on their own if they had bothered to lean javascript for
themselves in the meanwhile.

Compare it to some every-day examples:

Browser scripting is not directly comparable with everyday examples of
anything. Browser scripting isn't even comparable with any other types
of programming. Remove the downloading issue, the variation in execution
environments and the relatively slow execution and discuss a language
that has its resources on the local computer, provides a known
environment and is compiled into machine code and the library concept
goes form being a dubious idea to being the most sensible strategy
available.

But even so, how many real world examples are there of people providing
professional technical and design services without their accepting a
need to understand what they are doing? And how many clients of such
professionals would not have exactly that same expectation?

When you buy a new TV, do you learn electronics from scratch
and build your own to only have the features you want? Or do
you buy one that costs a little more and has more than you
need, but gives you a TV right away and gives you options in
the future?

The person who needs to learn how to build a television set is
television set designer.

When you want a new computer, do you research and buy all
the parts separately and spend time assembling them to get
the maximum possible performance?

<snip>

Yes of course. Computer parts are really easy to assemble, something to
do with the parts being designed to be interchangeable by implementing
common interface standards.

When you choose an OS, do you build it from scratch and make
it consist of the fewest possible features that you need to
use, in order to optimize performance? Or do you use a packaged
solution with lots more functionality than you'll ever need,
which uses more disk space and CPU, but makes your life easier
and more convenient?

Some and some. I learnt the Windows batch installation process years ago
so when I install it I only install the components I want and have my
personal user preferences in place form the fist boot-up.

Using a pre-packaged, generalized solution to a given problem
is not lazy or a cop-out as you seem to suggest.

But selling your services as a creator of javascript using web sites
without understanding what your are doing is as irresponsible as I
suggest. And it is the pre-packaged 'solutions' that make doing so
possible.

It's a realistic approach to take when you consider all the
factors involved and decide that building your own from scratch
just isn't advantageous.

Can someone who is ignorant of the technology they are using take all
the factors involved into account?

Why you object to it as a concept continues to baffle me.

It fails to deliver what it promises. It has directly harmful side
effects. There are better approaches. Why would I stop objecting?

I can only assume that you either have no understanding of the
real problems and priorities faced by many developers in the
world,

I certainly have no understanding of a web developer/designer who would
make an informed decision to do significant harm to their clients.

or that you must dismiss generalized solutions in order to
justify your own work to yourself.

The only people I need to justify my work to are my employers. And given
the pay rise they offered me last week I have to conclude that they are
more than happy with it and definitely don't want me to even think about
working for anyone else.

Incorrect.

Many people can achieve the level of understanding that I,
you, or anyone else has. I understand that many people
don't _want_ to, and many people don't have _time_ to, and
many people have higher priorities. I'm not superior, and
they aren't stupid. They just aren't focused on the same
things as I am, and I see no reason to tell them that they
need to be (as you do).

So having characterised the "average web developer" as a headless
chickens incapable of making informed decisions about the actions they
take, you are now admitting that there is no problem with a lack of
ability.

So we a left with people not learning javascript because they don't want
to. Which is not a problem, they can still practice the skills they do
have. But not wanting to learn a skill is not a reason for attempting to
practice it anyway, and no excuse for the harm that is the likely
consequence of doing so.

Richard.

 

[Matt Silberstein]

On Thu, 27 Oct 2005 23:09:14 -0500, in comp.lang.javascript , "Matt
Kruse" <[email protected]> in <[email protected]>
wrote:

[snip]

You are solving the specific case each time a new one comes up. I find it to
be more challenging, rewarding, and beneficial to try to solve the general
case (as much as possible) and then apply it to the specific case at hand.

This is great as long as you know the appropriate general case. And
that you can only learn by doing some specific cases and making some
guesses about the future. I frequently find that I have improperly
generalized some routine, that I guess wrong about what I was going to
need.


[snip]

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Matt Kruse]

Indeed, writing
re-usable context specific components as and when needed may mean
never having to tackle the more obscure possible permutations at all,
while the quest for the general algorithm pre-supposes the handling
of all such permutations form the outset.

You imply that a "general" solution must consider every possible
permutation. I disagree.
In fact, a "general" solution need only be tested in the situations that it
claims to cover, which is no more work than testing your separate
components.

It is perhaps significant that you have decided to pick on this
particular task, as you appear to be getting increasingly bitter about
the fact that nobody seems willing to help you write a general
position/dimension reporting algorithm.

I'm not bitter in the least. I think it's an interesting and challenging
topic, and one that would benefit from discussion.

Consider some of the factors involved in the general
position/dimension reporting algorithm:
<snip long list of 'issues'>

I'm not sure that much of what you listed even applies. When the browser
lays out the page, it calculates the offsets for the element, given its
position and display type. The programmer doesn't need to evaluate all these
permutations, since the browser already does it.
See my test page at:
http://www.mattkruse.com/javascript/ObjectPositionTest.php

It covers some of your conditions, and seems to do so quite easily. I plan
to add more test cases when I have time to see where it begins to fail.
Although, I feel that most typical test cases are probably already covered
by the code in the above page.

I believe that you are greatly over-exaggerating the effort required to
develop a general solution that covers a wide variety of situations, since
you've probably never looked into it. If a situation is encountered that
isn't covered, support for it can be added. Just as you would manually write
code to cover the situation in your 'swappable components' model. Except
with the general solution, you're just adding conditions rather than
re-writing a function.

But that is one of the problems with the genial algorithm, you
have to account for all of the possibilities or it is not truly
general.

General != Exhaustive
Although the closer you can get to exhaustive, the better.

Tomorrow? Real web sites are not radically re-designed at the drop of
a hat.

I am entertained by the fact that you have defined what a 'real' web site is


I know plenty of 'real' web sites that change their design regularly, or
even allow the end-users to alter the design. I know 'real' web sites that
are just wrappers for content that users or customers supply. If they wish
to provide javascript functionality, it needs to be able to handle a variety
of situations, without knowing in advance what the situation will be.

I tend to find that when I want to know the position and
dimensions of an element I want that information about a group of
element more frequently than 15 times a second (preferably 24 times).

I've never had such a requirement. *shrugs*
I imagine if you have a demand for this kind of performance, you might find
the general solution to be slow, and investigate ways to speed it up or
start from scratch.

But even so, how many real world examples are there of people
providing professional technical and design services without their
accepting a need to understand what they are doing?

Many. And many are quite successful.
But that doesn't really matter in this discussion.

 

[Thomas 'PointedEars' Lahn]

I was following this discussion and wondering: what in the name these
fisherman's talks have to do with the announced topic?

Don't even try to bother to understand it. Most certainly it will go over
your head.

My wild guess would be [...]

Of course, this is the only level of thinking you appear to be capable of.


PointedEars

 

[Richard Cornford]

You imply that a "general" solution must consider every
possible permutation.

If I only implied it then I am not being sufficiently clear. I
unequivocally assert that a general algorithm must consider every
possible permutation, or is it not a general algorithm.

I disagree.
In fact, a "general" solution need only be tested in the
situations that it claims to cover,

What is the claim being made when you attach the label "general" to an
algorithm?

If I write:-

function getYPosition(elRef){
return 27;
}

- and state that it only covers the situation when the element is 27
pixels from the top of the page I can then label it a "general"
algorithm and expect to be taken seriously?

No amount of weasel-words will render that extremely context-specific
(and 100% successful and accurate within its stated context) function
"general".

which is no more work than testing your
separate components.

A restricted context algorithm is not harder to test than a restricted
context algorithm. But in your previous post you were asking me what
happened when someone changed the context so that it fell outside of the
restrictions. To which I replied that because the restrictions on the
context in which the component would operate were known up-front they
know that they have to change the component. While the pretence in
labelling restricted context algorithm as "general" will leave them
expecting it to cope, and probably unsure of what exactly it was that
stated to fail following the change of context.

I'm not bitter in the least.

Then why all the whining and name-calling?

I think it's an interesting and challenging topic,
and one that would benefit from discussion.

It has been discussed. You weren't very interested in listening to what
was said in that discussion so there doesn't seem much point in
repeating it.

I'm not sure that much of what you listed even applies.

That is precisely that attitude that makes further discussions of the
subject with you pointless. You are offered the clues and instead of
doing some work to find out why they are significant you would rather
dismiss their relevance entirely.

When the browser lays out the page, it calculates the offsets
for the element, given its position and display type.

And when a browser calculates an offset where is it an offset from?

The programmer doesn't need to evaluate all these
permutations, since the browser already does it.

To calculate the absolute position of an element the programmer needs to
understand the significance of the various values the browser provides.

See my test page at:
http://www.mattkruse.com/javascript/ObjectPositionTest.php

LOL, you are not even trying.

It covers some of your conditions,

My conditions?

and seems to do so quite easily.

Superficial testing often results in inaccurate perceptions. I saved
your HTML locally, added one style attribute, setting one CSS property,
to one element on the page and suddenly your little marker is half a
page away from where it was supposed to be. Frankly, I am already using
components that I would never dream of describing as "general" that
already handle more possible (and actually likely) permutations that
your code would.

I plan to add more test cases when I have time to see
where it begins to fail.

Good, because the more time you send only looking at cases where it
works the more misplaced confidence you risk placing in a very
inadequate algorithm.

Although, I feel that most typical test cases are probably
already covered by the code in the above page.

I have been maintaining all along that the majority of real contexts can
be accommodated by relatively simple algorithms. Indeed, you are
attempting to allow for scrolling elements within a page, and so doing
extra work. I think that the majority of real contexts don't have
scrollable elements within a page so in most cases that extra code
doesn't have to be included/executed either.

I believe that you are greatly over-exaggerating the effort
required to develop a general solution that covers a wide
variety of situations, since you've probably never looked
into it.

Excellent reasoning. You know that I write DHTML that reacts in real
time to the re-flowing of documents so you conclude that I know nothing
about what it takes to determine the position and dimensions of elements
within a document.

If a situation is encountered that isn't covered, support for
it can be added.

And added, and added, and added, and added, until you actually are
covering all of the possible permutations, and have a chunk of code so
big and so slow that it becomes self evident why this entire strategy
was a bad idea form the outset.

Just as you would manually write code to cover the situation
in your 'swappable components' model.

Except that having observed that all conditions cannot apply to any
specific context at the same time it is clear that when a new condition
is encountered the need to add code to accommodate it is likely to
coincide with the possibility of removing/excluding code that does not
apply. So while the collection of components is likely to expand the
individual components do not have to become ever more complex.

Except with the general solution, you're just adding
conditions rather than re-writing a function.

If you ever get around to trying you will find plenty of need for
re-writing, but even if you could just add code that isn't necessarily a
good thing as it means that the totality must always get larger and
slower in the process.

General != Exhaustive
Although the closer you can get to exhaustive, the better.

By which you mean; if totally exhaustive then totally general.

Which is true. The question is what perverse use of English allows the
use of the label "general" with an algorithm that is not exhaustive.
This is more of your "partial solution" nonsense. But we are dealing
with computer programming here; the world of relentless, deterministic,
mechanical logic. Computers are not impressed by rhetoric.

I am entertained by the fact that you have defined what a 'real'
web site is

And the definition of 'real' that I stated was?

I know plenty of 'real' web sites that change their design
regularly,

You do appear to associate with some staggeringly inept web developers.
Thinking here seems to be that re-designing a web site is so expensive
and time consuming that doing so at intervals of less than six months
would be pouring money down the drain.

or even allow the end-users to alter the design.

Alter the design or alter their presentation? A design that allows the
user to alter their presentation is still a known design, and so
provides a known (if broad) context.

I know 'real' web sites that are just wrappers for content that
users or customers supply.

A design that allows the user to supply the content is still a known
design. And whatever wraps will constrain whatever is being wrapped, to
some degree or another.

If they wish to provide javascript functionality, it needs
to be able to handle a variety of situations, without
knowing in advance what the situation will be.

Don't be silly. Allowing a remote user total control over a web site is
a recipe for disaster.

I've never had such a requirement. *shrugs*

Oh you have had that requirement, you have just ducked it with talk of
'partial solutions' and things that are 'good enough in most
circumstances'. If you ever get to the point of being able to write GUI
components that are as potentially fluid as the pages that they may find
themselves used on you will rapidly see more value in fast algorithms
than general ones.

I imagine if you have a demand for this kind of performance,
you might find the general solution to be slow, and
investigate ways to speed it up or start from scratch.

What I investigate is strategies that deliver the results.

Many. And many are quite successful.
But that doesn't really matter in this discussion.

You edited out (again without marking the edit) my second, and more
important question, which was; "And how many clients of such
professionals would not have exactly that same expectation?". Clients do
expect individuals who purport to offer professional technical and
design services to have an understanding of what they are doing. And
that is not an unreasonable expectation, even if disappointed by some
(maybe, in your world, many) unscrupulous individuals.

Richard.

 

[Lee]

John G Harris said:

What a very silly thing to say.

It seems very reasonable to those of us who care about readability.

What is the symbol for milliwatts?

It is "mW".

However, readability is much more important in the context of
documentation than in a dialog like that example.

I would have said:

The parseInt() or parseFloat() function should be used instead.
(except of course, that it should not).

 

[Matt Kruse]

I unequivocally assert that a general algorithm must consider every
possible permutation, or is it not a general algorithm.

Semantic games bore me. Stop playing them.
To me, you are describing an "exhaustive solution".
To me, a "general solution" is one which is written so as to not be specific
to a single situation, but can be applied to a number of different
situations (but not necessarily all).

You understand what I mean. If you would like to use different words to
describe what you know I am talking about, let me know what your preferred
words are. Then maybe you can stop arguing about words and start discuss the
concepts behind them.

And when a browser calculates an offset where is it an offset from?

Depends on the browser, of course. And the page contents.

My conditions?

Yes, the long list of things that you said could be applied to a given page
to make a general position-finding function impossible. Things like adding
borders, margins, etc. My example page has test cases for some of those
things, and no extra consideration was needed to handle them correctly.

I saved
your HTML locally, added one style attribute, setting one CSS
property, to one element on the page and suddenly your little marker
is half a page away from where it was supposed to be.

What exactly was it that you changed?
Oh, wait, let me guess... "I'm not going to tell you, because you don't
deserve my help." Right?
Making empty claims is rather dubious.

Frankly, I am
already using components that I would never dream of describing as
"general" that already handle more possible (and actually likely)
permutations that your code would.

Even if you do have such components, they're useless to anyone but yourself,
since you refuse to share your work with the world. You just brag about it.
How nice of you.

I have a time machine, you know. I'm just not going to show it to you or
anyone else. Anyone smart enough to know how to handle a time machine should
be able to build one on their own.

Which is true. The question is what perverse use of English allows the
use of the label "general" with an algorithm that is not exhaustive.
This is more of your "partial solution" nonsense.

I'm just going to ignore your semantics arguments from now on. You often
prefer them to arguments about real concepts. One might take you for quite a
linguist, given how often you choose to argue about semantics, and how many
extra unnecessary words you choose to use in your posts to this group.

You do appear to associate with some staggeringly inept web
developers.

I prefer to think that you associate with some staggeringly atypical web
sites and developers, probably at a size and cost that most people won't
ever touch. You do appear quite naive of the situations that many developers
find themselves in, and you seem to lack the ability to see the world
through anyone's eyes but your own.

Thinking here seems to be that re-designing a web site is
so expensive and time consuming that doing so at intervals of less
than six months would be pouring money down the drain.

I re-designed a site the other day and it took about 2 hours. Since it was
all PHP with templates, headers, footers, etc, the site had a whole
different look and feel in a short amount of time. Amazing, isn't it?

You edited out (again without marking the edit) my second, and more
important question, which was

<snip>

 

[Richard Cornford]

Semantic games bore me. Stop playing them.

You certainly don't seem to like being asked to pin down the precise
meaning of the statements you make.

To me, you are describing an "exhaustive solution".

I would not use the word 'solution' here at all, because in the context
of problem solving I regard a solution as an absolute, and so not
requiring qualification. But we seem to agree that an algorithm that
exhaustively covers every possible permutation is a general algorithm.

To me, a "general solution" is one which is written so as
to not be specific to a single situation, but can be applied
to a number of different situations (but not necessarily all).

And yesterday you were saying :-

| In fact, a "general" solution need only be tested in the
| situations that it claims to cover ...

- suggesting that the characteristic that made an algorithm 'general'
were the qualifications that accompanied it. An assertion that became
self-evidently ludicrous when demonstrated to be applicable to a totally
specific function.

Today you assert that the algorithm becomes 'general' when it applies to
more than one situation. This is a similarly hopeless criteria for
labelling an algorithm general as:-

function getYPosition(elRef){
return elRef.offsetTop;
}

- applies to more than one situation, but is a long way from deserving
the label 'general'.

You understand what I mean.

I understand a meaning of the sequences of words that you are using.
What I am not seeing is how they can be usefully applied to the practice
of writing computer software. Mostly because the terms that could be
precise are constantly undermined with questionable qualifications.

If you would like to use different words to describe
what you know I am talking about, let me know what your
preferred words are.

I am a linguistic nominalist so I don't really care about the terms
used. You can make-up and use entirely new terms for all I care, the
only impotent consideration is the we both understand how the terms used
relate to the other terms in statements that employ them. If we cannot
share an understanding of how a term is being used we cannot communicate
and use that term at the same time.

Your use of 'solution' is a good example. I may not approve of your
definition but I can understand it, and so I can understand the
statements that you make that employ it. Because you understand that
when I use the term 'solution' I am referring to 'that which negates the
problem as analysed' you can understand my use of the term 'solution'.
And because I understand that when you use the term 'solution' you mean:
'that which may or may not negate the problem as analysed, but sounds
positive regardless', I can understand your sue of 'solution'. So, for
example, when you write "partial solution" I know hat you mean the
category of solutions that do not negate the problem as analysed but
still sound positive.

Those mutual understandings facilitate communication.

What I am asking for here is that you explain what it is that you mean
when you use the term 'general' (which seems quite significant when you
assert that you are seeking general solutions/algorithms).

But lets not get hung up on the term 'general' as such. Instead lets
ditch the loaded term and substitute the arbitrary term 'x', and analyse
the relationship between x and algorithms more abstractly:-

The a-priory assumption is: -

1. x is a quality that an algorithm may or may not have.

And the axiomatic 'truths' are:-

1. An algorithm that is totally specific to a single context
and task does not exhaustively cover all possible
permutations (and the inverse).

2. An algorithm that exhaustively covers all possible
permutations has the quality x.

3. An algorithm that is totally specific to a single context
and task does not have the quality x.

Unfortunately the statements are not enough to deduce a definition of x.
To that end another statement needs to be added, and given that x
appears to relate to specificity-exhaustiveness we can expect this
statement to be couched in those terms.

One obvious candidate is that; 'An algorithm has the quality x if it is
not totally specific to a single context and task'. The second and third
statements above can be deduced from this assumption and the remaining
one and so they can then be removed. And the new assumption becomes the
definition of x.

The other obvious candidate is that; 'An algorithm does not have the
quaintly x if it does not exhaustively cover all possible permutations'.
Again the second and third statements can be deduced from this
assumption and the remaining one. And this assumption becomes the
definition of x.

The remaining, and unavoidable, possibility is that an algorithm's
possession of the quality x relates to something other. That a fourth
statement needs to be added defining a relationship between
specificity-exhaustiveness and x, or fourth and fifth statements, one
relating x to something else and the other relating that something else
back to specificity-exhaustiveness. This (these) addition(s) (if
satisfactory) should again allow statements 2 and 3 to be deduced.
Possibly, but not necessarily, when combined with the first.

So, any statement (or consistent sequence of statements) that,
independently of, or when combined with, the first statement made above,
allows the second and third statements above to be deduced is a
satisfactory definition of x.

Relating this back to the applicability of the term 'general'. Today you
have gone for; "To me, a "general solution" is one which is written so
as to not be specific to a single situation, but can be applied to a
number of different situations (but not necessarily all)". Thus 'all
algorithms are general if they are not totally specific to a single
context/task'. I don't like that definition because it is the most
inclusive definition possible, and leaves the term 'general' meaning
very little. But if that is the meaning you would like attached when you
use the term 'general' then that is fine. Say so and we can have an end
of it. Though don't be too surprised if you are taken at your word.

As I have said, I prefer the most exclusive definition; 'all algorithms
are not general if they do not exhaustively cover all possible
permutations'.

On the other hand I am happy to entertain any other definitions of
'general' that prescribes a cut-off somewhere in the spectrum between
the totally specific and the exhaustive. The important thing is to be
able to look at any algorithm and ask 'does this algorithm qualify for
the label "general" by the definition of general being used?' with the
expectation of being able to answer 'yes' or 'no'.

Then maybe you can stop arguing about words and
start discuss the concepts behind them.

Put the concept behind being 'general' into words that say something
about the subjects to which you want to apply the label and maybe the
concept can be discussed.

Depends on the browser, of course. And the page contents.

And the CSS suggestions applying to the elements and their ancestors (as
defaulted or assigned).

Yes, the long list of things that you said could be applied
to a given page to make a general position-finding function
impossible.

If you go back and read what I actually said you will find that I was
listing some of the factors that have to be taken into account in order
to make the general (by my preferred definition of the term) position
finding algorithm possible.

Things like adding borders, margins, etc. My example page
has test cases for some of those things, and no extra
consideration was needed to handle them correctly.

That is right, keep looking at test cases where the code works and
patting yourself on the back for their success. After all, you had your
general (by your apparently preferred definition) position finding
algorithm even before you realised a need to take scrollable elements
into account.

What exactly was it that you changed?

I changed the value of one applicable CSS property on one element. You
will only find out where your code breaks by trying to break it.

Oh, wait, let me guess... "I'm not going to tell you,
because you don't deserve my help." Right?

Why do you act offended when I won't help you? All else being equal, am
I likely to go out of my way to help someone who insults me?

Making empty claims is rather dubious.

And disregarding warnings without testing is rather dangerous.

Even if you do have such components, they're useless to anyone
but yourself,

And my employers.

since you refuse to share your work with the world.

You are not the world.

You just brag about it. How nice of you.

You won't goad me into sharing anything with you but the warnings I have
already given you. You don't seem to appreciate it but the reason that
you are interested in knowing the algorithms that I use for this task is
that I have already trodden the path that your have barley started
along.

You think my code might help you along that path, it won't. I came to
the point of being able to see that the path was a dead end, turned back
and took an alternative route. The code I use now deliberately
side-steps the issues inherent in the general position/dimension finding
problem, and in doing so it delivers results. But those issues cannot be
side-stepped on the rout you have chosen.

I have a time machine, you know.

<snip>

Excellent, problem solved then. All you have to do is go forward in time
to just after you publish the totally exhaustive general
position/dimension finding code, make a note of it, return home and
publish it. Then the only remaining question is whether I was right and
the result is too big and slow to be viable in any but the least
demanding circumstances.

Richard.

 

[John G Harris]

<[email protected]> writes

What a very silly thing to say.

It seems very reasonable to those of us who care about readability.[/QUOTE]

Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.

However, readability is much more important in the context of
documentation than in a dialog like that example.

I would have said:

The parseInt() or parseFloat() function should be used instead.
(except of course, that it should not).

But this makes you vulnerable to charges of being a pedantic twit, the
kind who gives bad advice, the kind of bad advice that leads to
unreadable documentation.

(We'll excuse the 'e' of "except" as a typing error).

John

 

[Matt Silberstein]

You certainly don't seem to like being asked to pin down the precise
meaning of the statements you make.


I would not use the word 'solution' here at all, because in the context
of problem solving I regard a solution as an absolute, and so not
requiring qualification. But we seem to agree that an algorithm that
exhaustively covers every possible permutation is a general algorithm.

There is no such thing as an (existent) absolute (and, yes, I will
gladly get into an involved ontological discussion and will bring up
Augustine at the drop of a hat) nor are there meaningful solutions
that deal with "every possible" permutation for significant problems.
The perfect is the enemy of the good. Engineering, and programming is
a branch of engineering not of math, deals with making good enough
cost effective solutions for the actual problem someone has. We try to
generalize solutions, but that requires knowing the appropriate
generalization. Having a function ReturnFour when you need to add 2
and 2 is nonsense. But so is something that can do complex arithmetic
and add vectors and matrixes and such when all you need is normal
arithmetic. Sometimes it is better to significantly restrict the
domain, this allows better performance and more appropriate routines.

[snip]

Relating this back to the applicability of the term 'general'. Today you
have gone for; "To me, a "general solution" is one which is written so
as to not be specific to a single situation, but can be applied to a
number of different situations (but not necessarily all)". Thus 'all
algorithms are general if they are not totally specific to a single
context/task'. I don't like that definition because it is the most
inclusive definition possible, and leaves the term 'general' meaning
very little. But if that is the meaning you would like attached when you
use the term 'general' then that is fine. Say so and we can have an end
of it. Though don't be too surprised if you are taken at your word.

General and specific are not absolute notions but, rather, relative
concepts. A routine can be more general than another and more specific
than yet another. (This is not commutative since we can measure on
multiple dimensions.)

[snip]


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Matt Kruse]

I changed the value of one applicable CSS property on one element. You
will only find out where your code breaks by trying to break it.

You're so predictable.

You claim that you break someone's code, but refuse to tell them how or
where. So no one knows if you really found a problem or if you're just
blowing smoke. Which is how you like it, because to you it's all about
bragging and telling others how stupid they are. Good for you!

You think my code might help you along that path, it won't.

I think you _might_ have some solutions which _might_ me resolve quirks in
browsers, etc.
Or maybe not. I've looked into your code and found problems with some of it
before, so I'm not confident that looking closely at your methods would even
provide me with something valuable.

I'm more interested in discussing the issues and challenges involved with a
group of developers. On this topic and others. I'm actually not all that
interested in your specific solutions, because although you might be
technically skilled, you're just not that pleasant of a person.

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/31/2005 11:45 AM:

VK wrote:

I was following this discussion and wondering: what in the name these
fisherman's talks have to do with the announced topic?

Don't even try to bother to understand it. Most certainly it will go over
your head.

My wild guess would be [...]

Of course, this is the only level of thinking you appear to be capable of.

It is ad hominem moments like this that make people wonder about you
Thomas. Skip them and everyone will benefit.

 

[Randy Webb]

Matt Kruse said the following on 11/1/2005 3:53 PM:

I'm more interested in discussing the issues and challenges involved with a
group of developers. On this topic and others. I'm actually not all that
interested in your specific solutions, because although you might be
technically skilled, you're just not that pleasant of a person.

Any chance of a shorter URL to
http://www.mattkruse.com/javascript/bestpractices/
?

 

[Matt Kruse]

Any chance of a shorter URL to
http://www.mattkruse.com/javascript/bestpractices/
?

Yup,
http://www.JavascriptToolbox.com/bestpractices/

I'm (very slowly) designing the new site and updating my code and examples
along with it. For now, it redirects to my personal site, but I prefer to
use the new url because that's where things will stay permanently.

 

[Richard Cornford]

There is no such thing as an (existent) absolute

Absolutely none?

(and, yes,
I will gladly get into an involved ontological discussion
and will bring up Augustine at the drop of a hat) nor are
there meaningful solutions that deal with "every possible"
permutation for significant problems.

You have just introduced a category of problems that you have classed
'significant'. If you now define a 'significant' problem as one for
which it is not possible to deal with every possible permutation in a
meaningful solution you will have made a statement that is automatically
true, but not really worth much.

I suppose that in the context of the discussion to date the question
would be whether creating a general position/dimension reporting
algorithm is a 'significant' problem, and/or whether that algorithm
could take into account all of the possible permutations. I am fairly
sure that the variables, and the values of those variables, that
influence the position/dimensions of an element in a browser's DOM are
finite and knowable. It remains unclear whether a script executing in a
browser can identify, deduce and/or distinguish those variables/values.
I used to think that distinguishing some of the influencing variables
from each other was impossible. I have since noticed that there is a
possible way into that problem, and so that it could be possible to take
all of the possible permutations for that algorithm into account. But I
have never actually tried because the way in that I noticed is so
processing intensive that I doubt that the outcome would be worthwhile.

The perfect is the enemy of the good.

I like to think of the concept of perfect providing direction for the
better.

Engineering, and programming is a branch of engineering

That is disputed, there are plenty of experienced programmers who see it
as closer to an art.

not of math, deals with making good enough
cost effective solutions for the actual problem someone has.

Absolutely. But a solution that is 'good enough' is a solution to the
problem. It may not be the only solution to the problem, the best
solution to the problem, or an ideal solution to the problem, but being
good enough makes it a solution to the problem. And if a solution is
acceptable ('good enough') and is being described as a 'partial
solution' to some stated problem then the problem has been incorrectly
identified, and it is the problem for which the solution is acceptable
that was really the problem.

It seems to me that if programming is to be an engineering discipline
then accurately analysing the problems to be solved is a pre-requisite,
And precisely and unambiguously stating that problem should be a
considerable contribution to identifying a solution.

We try to generalize solutions, but that requires knowing
the appropriate generalization. Having a function ReturnFour
when you need to add 2 and 2 is nonsense. But so is something
that can do complex arithmetic and add vectors and matrixes
and such when all you need is normal arithmetic.

So there is a worthlessly trivial extreme and a pointlessly over the top
extreme. They don't exclude the possibility of covering all of the
factors pertinent to the problem.

Sometimes it is better to significantly restrict the
domain, this allows better performance and more
appropriate routines.

Which is one of the advantages of the strategy that I have been
proposing. You observe that any real context does not include all of the
factors that may apply in the general context, and only code for the
factors that do apply in the specific context. But do that in a way that
allows the context specific code to be swapped for more appropriate code
if and when the context is changed.

[snip]

Relating this back to the applicability of the term 'general'. ...

General and specific are not absolute notions but, rather,
relative concepts. A routine can be more general than another
and more specific than yet another. (This is not commutative
since we can measure on multiple dimensions.)

The ability to be more (or less) general, and more (or less) specific
does not preclude the possibility that general and specific are both
absolute. And neither does the fact that both may be applied to the same
subject when describing different aspects of that subject.

Richard.

 

[Lee]

John G Harris said:

Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.

You're not in a majority, you know. What seems like utter
nonsense to you is a well established standard.

But this makes you vulnerable to charges of being a pedantic twit, the
kind who gives bad advice, the kind of bad advice that leads to
unreadable documentation.

(We'll excuse the 'e' of "except" as a typing error).

The typing error was actually the period after "instead".
The parenthetical remark is a continuation of the sentence.

 

[Matt Silberstein]

Absolutely none?


You have just introduced a category of problems that you have classed
'significant'.

I am not interested in perfect solutions to trivial problems.

If you now define a 'significant' problem as one for
which it is not possible to deal with every possible permutation in a
meaningful solution you will have made a statement that is automatically
true, but not really worth much.

Significant problems are one where you have to think about and the
results matter. It is a term of art, this is not a philosophy
discussion.

I suppose that in the context of the discussion to date the question
would be whether creating a general position/dimension reporting
algorithm is a 'significant' problem, and/or whether that algorithm
could take into account all of the possible permutations. I am fairly
sure that the variables, and the values of those variables, that
influence the position/dimensions of an element in a browser's DOM are
finite and knowable. It remains unclear whether a script executing in a
browser can identify, deduce and/or distinguish those variables/values.
I used to think that distinguishing some of the influencing variables
from each other was impossible. I have since noticed that there is a
possible way into that problem, and so that it could be possible to take
all of the possible permutations for that algorithm into account. But I
have never actually tried because the way in that I noticed is so
processing intensive that I doubt that the outcome would be worthwhile.


I like to think of the concept of perfect providing direction for the
better.

Concept of? Perhaps. But it is not an valuable goal.

That is disputed, there are plenty of experienced programmers who see it
as closer to an art.

Not a contradiction. Engineering has lots of art involved. Even "real"
engineers, structural and all that, still has art involved.

Absolutely. But a solution that is 'good enough' is a solution to the
problem. It may not be the only solution to the problem, the best
solution to the problem, or an ideal solution to the problem, but being
good enough makes it a solution to the problem. And if a solution is
acceptable ('good enough') and is being described as a 'partial
solution' to some stated problem then the problem has been incorrectly
identified, and it is the problem for which the solution is acceptable
that was really the problem.

A good enough solution has to deal with enough of the cases that will
occur, not everything that ever might happen. I can make a totally
secure computer. Just remove the network cable. Remove USB ports.
Remove serial and parallel ports. Remove the modem. Remove the
keyboard and mouse and display. And take a way the power cord and
smash the hard drive. Ok, so maybe that is not applicable, I just like
to write it.

It seems to me that if programming is to be an engineering discipline
then accurately analysing the problems to be solved is a pre-requisite,
And precisely and unambiguously stating that problem should be a
considerable contribution to identifying a solution.

Which does not mean dealing with everything and anything that could
happen.

So there is a worthlessly trivial extreme and a pointlessly over the top
extreme. They don't exclude the possibility of covering all of the
factors pertinent to the problem.

And "pertinent" is the question that matters. I saw you writing about
absolutes and all factors, not all pertinent or figuring the
appropriate general case.

Sometimes it is better to significantly restrict the
domain, this allows better performance and more
appropriate routines.

Which is one of the advantages of the strategy that I have been
proposing. You observe that any real context does not include all of the
factors that may apply in the general context, and only code for the
factors that do apply in the specific context. But do that in a way that
allows the context specific code to be swapped for more appropriate code
if and when the context is changed.

[snip]

Relating this back to the applicability of the term 'general'. ...

General and specific are not absolute notions but, rather,
relative concepts. A routine can be more general than another
and more specific than yet another. (This is not commutative
since we can measure on multiple dimensions.)

The ability to be more (or less) general, and more (or less) specific
does not preclude the possibility that general and specific are both
absolute. And neither does the fact that both may be applied to the same
subject when describing different aspects of that subject.

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Richard Cornford]

Richard Cornford wrote:

I am not interested in perfect solutions to trivial problems.

Another class of problem labelled 'trivial'? I assume these two classes
would be exclusive but not exhaustive.

Significant problems are one where you have to think about
and the results matter.

As reasonable a definition as most others. So something like doing basic
arithmetic accurately, which might seem trivial, becomes significant if
you are doing it in the context of a banking or and aeroplane
fly-by-wire system, because the results will matter.

It is a term of art, this is not a philosophy
discussion.

So Augustine is no longer weighting in the wings then?

Concept of? Perhaps. But it is not an valuable goal.

Surly that depends on how easy it is to achieve. There is no problem in
accepting that perfection is impractical and/or unachievable in many
cases, but sometimes (if possibly rarely) the objectively prefect may be
trivially achieved. In which case why not?

A good enough solution has to deal with enough of the cases
that will occur,

Where 'enough' is determined by the actual problem.

not everything that ever might happen. I can make a totally
secure computer. ...

You could, but given that your totally secure computer is a pretty
useless object, was creating a 'totally secure computer' really the
outcome of the problem analysis or just a vague first attempt by someone
at stating the problem domain?

Which does not mean dealing with everything and anything that
could happen.

No, but it does mean at least having a go at identifying everything that
is relevant to the real problem (and those things that may appear
relevant but are not).

And "pertinent" is the question that matters. I saw you
writing about absolutes and all factors, not all pertinent
or figuring the appropriate general case.

<snip>

And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can be
drooped unaltered into any web page context at all and will then
successfully function as expected. And his expectation is that the
person doing the dropping will not have any technical understanding of
what they are doing and so will be incapable of doing anything about it
when his products do not work as expected.

That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot be
dropped into any web page context. With the latter case suggesting that
Matt should state the restricted contexts in which the code can be
successfully used, and that the individual employing the code should be
able to recognise whether those restrictions are satisfied in their
particular situation (problematic given the pre-supposition that this
individual has no understanding of the technologies they are using).

Of course that is just the logic of what Matt purports to be doing. When
'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks like a
marketing exercise rather than the altruistic contribution to the
betterment of the web development world he sometimes makes it out to be.

Which significantly alters the problem analysis, as then it is only
necessary to produce code that gives the impression of being general to
a sufficiently large number of individuals (who will never (mostly could
never) try to test that claim) to produce a revenue stream sufficient to
fund the exercise. Unfortunately that revenue stream comes form
voluntary donations and google adds. The latter requiring him to
constantly direct people to the pages on which those adds appear and the
former necessitating the maintenance of the pretence that the whole
exercise is altruistic. Hence; his desire to paint himself as the
champion of the common web developer, man of the people and victim of an
oppressive elite. His dislike of having the meaning of his statements
questions, his unwillingness to elaborate upon them and his reluctance
to say whether the clients of a professional should have a reasonable
expectation that that professional understands what they are doing. Of
course all of these things must also be denied in order to maintain the
pretence, but that's just marketing.

Richard.

 

[John G Harris]

Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.

You're not in a majority, you know. What seems like utter
nonsense to you is a well established standard.[/QUOTE]
<snip>

Are you sure your majority insist that a rule making paragraphs easier
to read justifies destroying the meaning in some infrequent cases?

Incidentally, there's a rule that proper nouns have a leading capital,
words like Lee, London, eBay, and parseInt.

John

 

[Matt Kruse]

Let's clear things up...

And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can
be drooped unaltered into any web page context at all and will then
successfully function as expected.

'Ideally', yes, that would be nice. Realistically, no. That's not the goal.
The goal would be able to have code which works when dropped into the
majority of typical situations.

And his expectation is that the
person doing the dropping will not have any technical understanding of
what they are doing and so will be incapable of doing anything about
it when his products do not work as expected.

If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the code. If
it is likely that the condition is common to more than just a single
situation, then it could be considered for addition.

That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot
be dropped into any web page context.

Perhaps you used wrong words, but that is not true at all.
Even if all factors are not considered, it might work correctly in the
majority of contexts.
Your point, I assume, is that unless all contexts are considered, then it
could not be dropped into ALL web page contexts. Which is, of course, true.
But since that is never my goal, I have no problem with that.

With the latter case suggesting
that Matt should state the restricted contexts in which the code can
be successfully used, and that the individual employing the code
should be able to recognise whether those restrictions are satisfied
in their particular situation

It's impossible to list every context where such a generalized solution will
work. It might be possible to list all the conditions that are considered in
the code, although I don't think most people would find value in that.
Instead, it would be best to list the contexts where the code does _not_
work, so a user can identify if such a context exists in their case.

When 'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks
like a marketing exercise rather than the altruistic contribution to
the betterment of the web development world he sometimes makes it out
to be.

I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case. For example, if you
have an IE-only app and you want to get the color applied to an object, you
could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}

This solution is not generalized at all. It returns the value of one
attribute, and only in some user agent(s).

The term 'general' is relative. A 'more general' solution would take into
account multiple user agents:

function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue('color');
}
return null;
}

A even more 'general' solution would consider the case of a null object,
etc, but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an argument, so
the method could be reused for obtaining any style attribute:

function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue(property);
}
return null;
}

An EVEN MORE 'general' solution might take into consideration some specific
browser quirks, or NN4, etc.

I would consider the improved 'getObjectColor' function to be a general
method of obtaining the color of an object. But the 'getObjectStyleValue'
method is even better, since it's a general method to obtain any style
value.

None of these are 'exhaustive' solutions, however. There are certainly cases
and browser quirks which are not considered. However, these functions in
their finished form would surely provide the desired functionality for most
people in most contexts, so they could be presented as a 'general' solution.

The goal of building 'general' solutions is to provide functionality that
works in the majority of contexts that arise in typical development. The
goal is never to build an exhaustive solution which covers all possible
situations. That's not possible in most cases. (In cases where it is
possible, it is certainly a good goal!)

Your insistance that a 'general' solution must be 'exhaustive' is incorrect
(or at least, not the typical opinion). I've checked with a number of other
developers in a forum I participate in, and they all agreed that they do not
necessarily consider a 'general' solution to address every possible need
which might arise.

So, when I attempt to build a 'general' solution for finding the position of
an object, for example, I'm attempting to address the majority of typical
contexts in which it would be used. So most people, under most conditions,
_could_ in fact drop the library into their code and have it work correctly.
In other libraries, I have built in functionality which will be used by some
people but not others, because I thought that the need for the functionality
was typical enough to warrant inclusion. In other cases, people have made
specific requests that I did not include because I didn't think most people
would ever have the need for the feature.

If exceptions happen (and they will) then I would hope that the person
finding it would tell me details and provide a test case so I could
determine if the need is typical enough (in my own opinion) to be included
in the general library and should be fixed, or if their context is so
specific to their situation that they would need to write specific code for
their case. Of course, when people such as yourself claim to find an
exception and refuse to provide details or a test case, that doesn't help to
make the general routine more solid. In fact, since you refuse to provide
any evidence, I'm not sure I even believe you. It's easy to make empty
claims. *shrug*

A 'partial solution' is valuable because it solves a specific case and can
be used in a more general solution. For example, the code using currentStyle
to find the style applied to an object is a 'partial solution' because it
does solve the problem for a subset of all cases. Combined with other
'partial solutions' they form a more general solution which is more
valuable.

A 'partial solution' can also be a library in itself. For example, finding
the position of an object. By itself, it provides no functionality to the
user. It must be used with other code to achieve some bigger goal. But it
can be used as a black box to solve the problem of finding the position of
an object, so the coder doesn't need to go into detail programming that
portion of the bigger picture.

<snip about my 'advertising' and supposed real motivations>

Nothing will change your opinion of my efforts, Richard, so what I write
won't even matter.

But, the truth is that when I direct people to my stuff, it's always because
it _specifically_ addresses their needs, and I think they will benefit from
it. I don't advertise. If you have specific code which solves their specific
problem, you may post it. If I have already written a solution which solves
their problem, I may direct them to it.

I happen to offset the cost and development time with donations and google
ads, although I certainly do not 'come out ahead' in the game. If I were
trying to make a profit, I would be charging for my work rather than giving
it away with almost no useage restrictions. My goal is to provide solutions
which help average web developers perform complex tasks which they may not
be able to do themselves. I get personal satisfaction knowing that I've
helped thousands of people solve their problems when people like you would
have told them that they didn't even deserve to be helped. If I'm ever seen
as 'promoting' my stuff, it's because I want people to be made aware of
packaged solutions which can solve their problem, rather than being faced
with people telling them how stupid they are, or resorting to finding
terrible code at some copy-n-paste javascript site.

If you don't believe me, that's fine. I don't care.