It's not obvious at all that "unobtrusive" coding has advantages. First of all, the line between HTML and what they call "behavior" is vague: many, if not all, presentation elements contain built-in behavior of some or other form, for example take any form element. JavaScript code that we write extends or customizes this behavior, rather than creates it from scratch.
Second, when we read raw HTML it's better to see explicitly that the behavior of a given element is customized. Even a small hint of customization in a form of a function call from within onClick, for example, would be a sign that a given element is different from the standard one.
Finally, less code always means easier to understand and easier to debug. There is no excuse for writing more, no matter how you call your technique, if there exists a simpler and clearly more concise way of implementing the same functionality.
Damnit, there's no reason to downvote this man. He may not be right, but he's not detracting from the conversation.
A rebuttal: Unobtrusive coding has many clear advantages - not the least of which is the fact that your js files can be cached, increasing the loading speed of your app.
And more code in, say, a library can mean less domain-specific code that has to be maintained, making your app easier to understand and debug. I use YUI, jQuery, and the module pattern to create surprisingly concise and easy to understand js files. They're pretty much all cacheable, they're easy to read, and most importantly, related things are all in the same place.
This is actually kind of key for debugging. If you want to find out where the function call attached to a dropdown's onChange event, you check the YAHOO.Company.page.init() function. That's just where it is. You don't have to sort through reams of HTML to find the dropdown. This is better still if you have a function that prints multiple instances of that dropdown - the events are all attached, line-after-another in the js file, not hidden in a function somewhere in a different language.
Certainly there's downsides to it, but there's a lot to gain.
I should have made myself clear: I'm not against moving JS code to a separate file and I understand the benefits of caching.
My point is, some hint of change for a given element must be given where it's declared, for example as a function call in onChange. This function itself can be defined anywhere, preferably in a separate file. Why - because when building a web app you usually look at the page and decide to modify the behavior of an element. In a good WYSWYG editor it's just one click, and you see that there's custom code attached to one of the events of that element.
With "unobtrusive" style it's not obvious at design time whether an element has standard behavior or not, unless you know the code well, I mean, every bit of code in all modules.
I'm not sure that's 100% true. Some development idioms have you staring at HTML all the time, others don't: take a look at the arc code behind YC for a good example. Likewise view-based architectures like rails spend more time worrying about how to invoke/include the view than they do tinkering with the presentation internals.
And that "hint" that you want can be gotten many ways, it doesn't have to be a hard-coded event handler. Make it a class, for example. Or better, a class on the containing element (a collection of category selectors, whatever). That's even clearer than the event handler, because it's a statement of pure semantics.
You can make just as obtrusive Javascript using jQuery as much as you can with any JS library, the point is that you should be doing unobtrusive Javascript.
If you want to get an array of all the table cells in a table, you're probably using the DOM to store data, instead of display data, which is bad IMHO.
I prefer having the data in js, pointing to nodes in the DOM, or containing IDs that may need adjustment, updating.
Or you're adding rollover events to the table, or styles to the table.
Also, the DOM's not a bad place to store data. Why duplicate it elsewhere if it's already in-place in a table? This allows you to say, gracefully upgrade your simple HTML table to a YUI DataTable if your user has javascript enabled.
That's like using a video cards display ram to do inter process communication, or store other program data.
Sure though, if you want to add things to a table once loaded to be unobtrusive I can see that use. Although then I'd say just give them sane IDs, and have a js array with the IDs you need to update.
Second, when we read raw HTML it's better to see explicitly that the behavior of a given element is customized. Even a small hint of customization in a form of a function call from within onClick, for example, would be a sign that a given element is different from the standard one.
Finally, less code always means easier to understand and easier to debug. There is no excuse for writing more, no matter how you call your technique, if there exists a simpler and clearly more concise way of implementing the same functionality.