That question hitted me yesterday...

A bit of explanation...
I'm currently designing a demo site build around an XML+XSL framework I've been working a bit lately.

As I love (and really love, not just like) javascript and DOM scripting, I thought to myself that it would be really cool, if we could separate javascript as we could do with css.
I mean, no <script> elements anywhere else than defining the source files in the header.

For that, I decided to tag my HTML elements with specific attributes.
My different JS objects are then scanning the dom tree, to detect which elements are tagged, and applies them specific behaviors, and sometimes even totally rewrite them.

For exemple, I've wrote an js object, that will fetch every div's with an js:tab="name of tab" attribute, and it will create a tabbed composant with every div's tagged like that.
It don't just add an tabbed header, it re-create an tabbed structure, while deleting the original elements from the DOM tree.

It works perfect, it's clean in the HTML source and it degrade very well, as someone without JS enabled will just have a series of div on screen.
You can see it live there:
http://dating.webalis.com/signup.php

I know, the html is not valid, but it's because when I force the server to transform XML+XSL in HTML, it don't follow the specified doctype.
If anyone have infos about how you can force the PHP5 XSLT engine to XHTML rather than HTML output mode is welcome...

But, of course, I have now a HTML source that is no more w3c compliant, because js:tag is not a recognized attribute.

So, even if for myself my mind is well set on that subject, I'm curious to hear about yours.
If you could integrate something like that in your pages, would you mind loosing w3c compliance for the benefit of this ?

For scripts like this, I use the class name. Class names allow multiple classes per tag ( e.g. class="tab coolClassName" ). It's nice and compliant and fits with the fact that the objects are within a logical class named "tab" while allowing proper CSS via "coolClassName". For example, on http://www.memberscript.com/signup.php (a client's site), you'll notice that typing in a box beyond it's boundary stretches the box automatically, but if the INPUT tag's class name includes "no_resize" (no example on that page) then the javascript ignores that field for automatic resizing.

I thought of that too, and hesitated a bit.
But what I was looking to was to separate javascript, not to mix it with css...

I wanted to have the datas (XML), the presentation (XSL+CSS) and the "front end" logic (JS) each separated from each.

As I said, loosing w3c compliance in that way is no big deal to me. The document stay semantically clean and well formated.
This looks even like a hole in their credo, as we are allowed to add namespaces, but the document don't validate anymore after that....

Web standards are a guide. Some major web sites have hundreds of validation mistakes - that certainly isn't good. If you conform to most of them, then you're doing alright. I try to make my sites validate, but if they don't, it's not a massive problem. Getting them as close to web standards as possible should be the key.

One problem that always annoys me when I'm making sites is that you can't place a <div> inside of an <a> tag. This is usually to get a workaround for the IE6 transparent PNG bug - I place an image inside of the <a> tag, then block this with CSS for IE6, then apply a background to the <div>. The <a> is there for logos and things so people can go back to the home page at the click of a button. I know this isn't great web standards, but it's hardly affecting the browser at all and will enhance, not impair, the user experience.

Whym: Have you considered handling the div's onclick event?

Custom name spaces are painful. I've done some experimenting with them, and could never get what I wanted, which is a bit different from your example, but not all that much.

I would pretty strongly consider different class names, since you can use a list of them. On the other hand, you could more cleanly separate the markup from the script by defining which elements should be acted on in your script, rather than by attaching different attributes to them. That obviously doesn't make sense ... but it's arguably the 'cleanest' method. With that in mind, I think I've got to agree with Daniel and say web standards are great advice, but not law. If a page doesn't validate, but does everything that's needed, that might be a better solution...