It doesn't, of course, but that wasn't the point. We're talking about
two different ways to set up a handler for the "load" event - one of
them is defined by the HTML standard, the other falls into an completely
different area which has never been officially standardized, but is
nevertheless heavily used and well supported.
And shouldn't that be the end of the discussion?
Both have their minor pros
and cons, and I'm trying to understand why you and Thomas think that one
is superior to the other.
I think you said it fine yourself (above).
The lack of a standard would have been an
argument in your favor if you didn't already use the same unstandardized
mechanism (DOM-0 events in scripts) in other places.
I think you'll find that I avoid attaching listeners to the window
object whenever possible. The most critical listener (load) is the
last one I would trust to the window object. Unlike documents and
elements, there is no standard for the window object. That's why -
for example - some browsers feature document.addEventListener, but not
window.addEventListener.
Another way to answer your question is that a de-facto standard will
beat an official standard any day if it better reflects the way things
actually are.
But it doesn't in this case.
But this line of arguing is going to get me bashed as an
evil "pragmatist", which I would find humorous, but isn't the direction
I'd like this discussion to go
Yeah, the most recent exhortation to "be pragmatic" I read came from
Thomas Fuchs. He was advocating CSS parse hacks over IE conditional
comments. And, of course, the Dojo authors use that word a lot. Bad
company.
One possible reason is that many developers dislike mixing logic and
presentation.
To the extent that *one* attribute on the body is a deal-breaker?
That's the sort of silliness that I associate with the "unobtrusive
Javascript" movement. There are other examples as well. If a script
will only ever be associated with a single document (and the two are
typically changed in tandem), it makes no sense to put that script in
a separate file, except in some blind rush to be "unobtrusive". It's
cargo cult behavior; chanting buzzwords instead of thinking.
The three typical (textual) components of a document -
HTML, CSS, and scripts - are complimentary, and they each have a
different focus:
HTML - structure and content
CSS - design (usually visual)
JS - additional functionality and interactivity
Yes and there are exceptions to the "rule" that says they must all
reside in separate files.
As a related note, I see a lot of frameworks (e.g. Dojo) that
incessantly break up every feature into the separate files. I once
asked the Dojo developers why they did that, seeing as the "base" Dojo
build invariably requires about a dozen of them (requiring developers
to wait for twelve synchronous XHR requests each time they refresh).
Their "answer" was that it was the only "sane" way to do things.
People who are used to working with templates will tend to avoid
inserting too much logic (JS) into the template (HTML).
One attribute?
onload="if (typeof bodyLoad == 'function') { bodyLoad() }"
Works whether they create a bodyLoad function or not. The trouble is
that many developers will see such a thing as "ugly" (as if aesthetics
trump logic). Of course, many developers are in the wrong business.
Keeping them
separate makes maintainance easier: you don't have to look all over the
place to find out which scripts work together, or where events may be
triggered.
How is it any easier to find a script in another file than in the
document itself? If you are referring to documents with tons of event
handler attributes, I am certainly not advocating anything like that.
You seem to use "unobtrusive" as a kind of epithet (like "pragmatic"),
Look how those words are thrown around and used to justify bad
decisions.
but there is a reason why developers are finding this type of design
appealing, and it's not just because of some new buzzword.
Most Web Developers desperately want absolute rules as they don't
require any thinking. If you start questioning the rules they've
built up, it makes them go ballistic. Buzzwords are their rallying
cries. Am I just being harsh or are the majority of Web developers
irretrievably ignorant and incompetent?
I realize that it's not practical to keep them completely separate all
the time, especially when doing so would mean adding awkward and
unnecessary code.
Right. Or extra http requests.
I use onclick in anchors and buttons quite a lot,
In some contexts it makes sense.
I
add ids and classes to my HTML elements which have nothing to do with
the document's structure,
I don't use classes for anything but CSS. Of course, ID's often are
often dual-purpose (for styling and scripting). But I don't see how
any of that relates to the document's structure (other than the
presence of the attributes).
and I use inline CSS in some plaves.
As in style attributes? Those I avoid entirely. Inline style blocks
are fine though (assuming they are only relevant to a single
document).
There are
many exceptions. The onload attribute might just be one. However, I'm
still not convinced that it has any real advantages over window.onload.
Still?
For you and me, sure. Most people have never heard of them. Some of them
edit our stuff after we leave. Best not to give them any bad ideas.
I document my stuff before I leave; that way there are no
misunderstandings (unless future developers fail to read the
documentation). There's only so much you can do though. I once
revisited a project to find that a simple form validation I wrote had
been littered with dojo.query calls and at least one line that blew up
in IE7 (and IE8 compatibility mode). When I asked about this, I was
told that using the elements collection of forms was "old fashioned",
queries were "more concise" (despite requiring the behemoth Dojo
library) and testing "ancient browsers" like IE7 was a "waste of
time". Thankfully management sided with me on that one.
Of course, that was a contrived example to illustrate the point.
When it comes to making points, I prefer less contrived examples.
Shouldn't be a problem, because you're rarely going to have both.
More like you are never going to have both because one cancels out the
other. If you avoid window.onload, you avoid that problem. It's much
easier to tell at a glance if a document runs a script on load by
looking at the body element. Wading though extraneous "unobtrusive"
scripts to find window.onload assignments is far more trouble.
Like everything else we add to the 'window' object. I don't see a
problem with that.
It's just an example of a side effect.
In this case, it may even be beneficial, because now
we have a reference for our event handler.
How does that help?
To be quite honest, I never
thought of checking if the 'window' object already had an onload
property before one is set explicitly.
You have to when lots of "unobtrusive" scripts are mashed together (as
is often the case on the Web). You end up with a daisy-chain of
calls. Wouldn't it be much simpler to have an array of functions that
are called by a "bodyLoad" function that is "attached" with an event
handler attribute.
In any case, this is unlikely to
cause trouble.
What is unlikely to cause trouble? If you step on an existing
window.onload property, that's likely to be big trouble.
See above for my thoughts about "unobtrusive" code and a possible reason
why window.onload may be preferable.
See above for my responses.
