Monday, May 9, 2011

Initialization, JavaScript and HTML/CSS friendly behaviors

Way back (early 2009) I started a Stackoverflow question about this very same topic. I didn't find the answer I was looking for but recently I've managed to put some pieces of the puzzle together.

Normally, I'd rely on the HTML id="" property to be a known value and get at it using getElementById or $("#id"). I've never liked this approach but what are you supposed to do? This is how 99.99999% percent of the people I know do it and they think it's fine. Fine!? It's a freaking atrocity. I know it's very subtle but if you think about what your doing, your effectively duplicating knowledge everywhere, filling up your global namespace with a bunch of identifiers and having to go through hoops just to do parametrized initialization.

I think we can do better.

Oh, and If you haven't already gone there, that Stackoverflow question contains a bit of code I wrote as an example and answer to my own question. On how to go about this in an unobtrusive way.

It sort of began with the realization that jQuery addClass, hasClass and removeClass can be used to toggle a Boolean value. The state of this Boolean is reflected in the presence of a CSS class. Without thinking about it, I had stumbled on a system for handing visual states. When these CSS classes represents meaningful visual state information you can use them to style your JavaScript (or augment) using established CSS rules. These things fit well together.

All my client-side validation does is that it toggles an error CSS class at some place and I have a planned out HTML fragment with additional classes that let's me apply a style to the validation state without meddling with the original script.

I started using this more and more and it's truly an ingenious marriage between two technologies but I was still bugged that I couldn't do the same with client-side behavior, or so I thought.

By simply rethinking the way we've (or the way I've done it so many times in the past). I started thinking about CSS classes as more than visual state. What if I reserved a CSS class for a specific behavior?

By reserving certain classes for use with specific HTML fragments I can create very rich client-side behavior without violating the DRY principle, encapsulation or relying on other ugly hacks. Say good bye to printing ("<%=...") strings in JavaScript and hurray for that!

What you do is that you pick a CSS class to identify the HTML fragment and then use HTML5 data to attach properties (think of 'em as parameters). From within a document ready function, using jQuery, you query the document for all the CSS classes and do your initialization here. You have a reference to the DOM node, data availability (parametrization) and complete encapsulation (no publicly visible interface, except for the data members).

The Stackoverflow question contains a simple sample where I use this trick to add regexp validation using CSS classes and HTML5 data only (assuming that the script is already written). I can reuse this code in many different places without having to go back to my JavaScript or "hook up" these things thanks to the wonders of jQuery and CSS selectors.

I think this is something truly beautiful.

No comments: