1 Here's one we made earlier...

I’ve been poking into this method of seperating the functionality from the markup too. I scan the document for certain key classnames and I add fun little event handlers accordingly. You might want to have a look over here: http://www.woollymittens.nl/content/weblab/lib_classbehaviour

posted at 09:57 am on February 1, 2005 by Woolly Mittens

2 "class attribute should only be used for CSS"

I’m interested in hearing more reasoning about why “the class attribute should only be used for CSS,” as I’ve used classes for unobtrusive JavaScript for a while now and find it to be an incredibly useful technique.

It seems like it’s not worth the hassle to create a custom DTD just for the sake of adding custom attributes. What’s really that wrong with using classes?

posted at 10:05 am on February 1, 2005 by Adrian Holovaty

3 Excellent!

I hope you can hear my applause in the Netherlands, PPK. This is why I respect you so much, for insight like this. Great!!

posted at 10:24 am on February 1, 2005 by Dante

4 No class for JS, yet a custom DTD?

Isn’t this a bit of a slippery slope? What is the point of writing to standards if you are just inventing your own? I agree with Adrian, it doesn’t make sense to go to the trouble of reserving Class attributes for CSS while creating ficticious attributes just for your javascript.

posted at 10:33 am on February 1, 2005 by Jacob

5 Making event listernes with standards-compliant co

“y[i].onmouseover = addBehavior” is non-standard (doesn’t comply with ECMAScript or W3C DOM). The right way to do it is to use addEventListener(). Internet Explorer doesn’t support addEventListener(), though (as most web developers know, it lacks support for a lot of W3C-standardized stuff). The solution is to try the standards-compliant way first (which modern browsers such as Firefox, Mozilla, Konqueror, Safari, Opera, etc. support), and – if that doesn’t work – fall back to the non-standards-compliant method:

try { y[i].addEventListener(‘mouseover’, addBehavior, false)
}
catch (exception) { y[i].onmouseover = addBehavior
}

posted at 10:36 am on February 1, 2005 by Jonas

6 Agreed with Adrian

Adrian’s question is my question: I’d like to see some more reasoning behind why the currently-valid class attribute shouldn’t be used for scripting.

The separation of structure/presentation/behaviour doesn’t appear to benefit any more from custom attributes than it does from ‘misused’ classes. The spec — http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 — clearly states that the class attribute may be used for style, but also that it’s open for general usage. The latter implies to me that using it for scripting is not a huge stretch.

Further, saying that custom attributes clear up the issue of stating ‘deploy behaviour here’ that classes introduce is simply untrue. The same argument applies equally to both applications. Your final result in both cases is an indication point in the markup for your script to tie into, you’re simply introducing new syntax.

Your suggestion of custom attributes and a custom DTD forms a perfectly valid, future-compatible solution. I just think it seems more trouble than it’s worth.

posted at 10:38 am on February 1, 2005 by Dave S.

7 Oh, and...

Good article, by the way. I’m glad we’re talking about this.

posted at 10:39 am on February 1, 2005 by Dave S.

8 Custom DTD's, ALA is great

I’ve struggled with this very problem and because I didn’t want to add custom attributes I opted for the class method. I don’t think I would have ever thought of creating a custom DTD, but now that the point has been made it seems like a no-brainer.

I always felt as though it was always a hack to use class names for custom Javascript behavior, this easily solves the problem. I don’t agree that adding a custom DTD to extend the XHTML DTD is bad, I think that is the entire idea behind the the standard allowing the ability to specify your own DTD.

Great work Peter-Paul, this really opens a lot of doors for interactive forms and such.

posted at 10:42 am on February 1, 2005 by Justin Perkins

9 Classes vs. custom attributes

Dave, Adrian, Jacob,

The reason I use custom attributes is exactly the one outlined in the article: it may become too complicated to read out all required information from the class attribute, and besides the required JavaScript code becomes simpler.

I have a form validation module that reads out a custom attribute I may define on any form element:

validate=“required numerical date”

which means: “this field is required, it must contain a number and it’s part of a date”. My module reads out all values the custom attribute and then performs the necessary checks one by one: first required, then numerical, then date.

I can be certain that all values of the validate attribute have something to do with the form validation process, but I cannot be sure of all the values of the class, which will probably contain one or more CSS triggers.

It can probably be done, but I feel my solution is more elegant. Feel free to disagree, of course. This is a subjective argument and cannot be conclusively proven one way or the other.

Dave:
“Further, saying that custom attributes clear up the issue of stating ‘deploy behaviour here’ that classes introduce is simply untrue.”

Correct, and I didn’t say that.
They clear up the issue of sending extra information (“maxlength is 300”) to the script, something that can be done with classes, but not as easily or as elegantly.

posted at 10:48 am on February 1, 2005 by ppk

10 The main advantage of using custom attributes...

The main advantage of using custom attributes is that, as the article explains, it allows you to have multiple values passed to your triggers. For example, using custom attributes, you could define a number of validation rules for each form element, like ‘require 2-10 integers’, which would be pretty messy using the class attribute. So in my opinion, only in the simplest of cases is a custom DTD more trouble than it’s worth…

posted at 10:51 am on February 1, 2005 by mateo m

Discussion Closed

New comments are not being accepted, but you are welcome to explore what people said before we closed the door.

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)