That function is more of a "dragging has stopped" function, it doesn't
provide any hooks to allow a user (developer) to do thinks like add
functions to call when dragging has stopped or identify if the dragged
element has been dropped over a drop target, and so on.
Very true. As the author tells us:
"This example only scratches the surface of drag and drop. [snip]
Moreover, one often wants to drag from one place to another, instead
of just randomly. [snip] Simplicity first!
!!
"Determining what elements one is dragging over is tricky, because the
onmouseover event does not fire if the cursor is over the element
being dragged."
The author did as he said he would, imo: "Drag and drop is a topic
that can be explored to great lengths somewhere else; all you need to
know about it here is that you left-click-and-hold on one 'draggable
element', and then move your mouse with the left button down: the
element you clicked on follows your mouse." He then goes on to
implement those three functions.
I hope I'm wrong, but it /sounds/ like you are criticizing the article
because it doesn't treat stuff outside its stated scope, sort of like
criticizing an algebra I book because it ignores calculus. Maybe you
mean only to suggest that one needs a lot more study to fully
understand d-n-d, as I think, too. The author agrees: "This example
only scratches the surface of drag and drop...."
For me, who wanted to get drag-and-drop, however rudimentary, working
on his web page, the article was right on. I can wait to perfect it
later.
Anyway. I appreciate the issues you raise, which all deserve study and
a lot of thought.
I'm not sure I'd call it a plight, more a condition. Javascript is a
constantly moving target, even if the underlying language and public
specifications like the W3C DOM stuff stood still, there are new
browsers coming out all the time with bigger, better, faster
implementations.
Yes, yes, good! I thought you meant just that. It's a fascinating
topic, this business of never being quite caught up, of always having
some finite further distance to travel/learn, because the goal is
always receding: the DOM will never stand still; browsers will always
improve; Achilles will never catch the tortoise.
So it is the plight of anyone interested in writing javascript if
their objective is anything other than short term support for a small
number of current browsers.
Yeah, but that /must/ be the objective for a developer who wants to
get paid, right? The backstop is that today's javascript code will
'always' work (we trust). Even if advances make it obsolete,
deprecated, dumb, despisèd and rejectèd, whatever.
Writing an article requires the author to study aspects of the topic
that they hadn't thought of before (often because of "dumb" questions
by novice readers - the kind that quickly expose the depth of the
authors knowledge),
Aagghhh! Please! Don't remind me
or thought they knew thoroughly but realised they
didn't. The process of researching and writing a lucid article is a
great learning experience and I suspect a reason why written
assignments are highly regarded as a teaching tool.
Absolutely! We never know what we don't know. Also the reason that we
gotta' code to learn to code.
It is probably also one reason why blogs are so popular - the authors
benefit as much as, or more than, the readers.
For sure, and blogs are popular with me partly because I can have the
pleasure of pontificating with relatively few of the consequences I
can expect in, say, my kitchen
-- pete
