semi/signal

Something I’ve been doing for a while in my web development work is applying separate classes, interaction classes, to DOM elements that interact with Javascript. Basically, an interaction class is applied to any DOM element touched by Javascript code – an element bound to an event handler, an input element with it’s value being read or written, an element selected for animation, etc. The goal being to de-couple styling from interaction, allowing style changes to not interfere with JS code, and vice-versa.

Below is a bit of code to demonstrate what I’m talking about. As a convention, I apply a “ia-” prefix to my interaction classes.

• btn-primary has the CSS rules for styling the anchor as a button
• ia-begin-testing is bound to a JS event that triggers some arbitrary “begin testing” action

If the future, if I want to change the button to a link (remove the btn-primary class), change it to a secondary button (btn-primary to btn-secondary), or change styling in any other way, the Javscript code is unaffected and requires no changes.

In addition, the ia-begin-testing class can also be applied to other elements (another button, a link, an anchor wrapping an image, etc.) and is automatically bound to the same interaction functions, without writing additional JS DOM selection code. The ia-begin-testing class can also be removed, or changed to another interaction class, and the styling on the button remains the same.

While IDs and data attributes are also good choices for architecting this sort of style/interaction separation, I like classes for 2 reasons:

• Selection via class is relatively fast across all browsers compared to selection via data attributes
• Compared to IDs, classes can be re-used allowing the same interactions to be shared by multiple elements (e.g. a button and a link can both trigger the same function)

One of the reasons I wrote this post is as an alternative to the the “grouping of selectors” approach presented in Chris Coyier’s Can You “Over Organize” JavaScript? article. With interaction classes, there’s little need for grouping selectors. Aside from the benefit of de-coupling styling and interaction, you get the advantage of a single class (ia-whatever), on whatever and however many elements, mapping all said elements to their necessary JS functions. With grouping of selectors, some sanity is brought to the scattered DOM selection code, but you’re left with the burden of maintaining a pool of different element IDs, classes, etc.; a chore that only gets harder as the codebase grows and changes.

The .NET Framework has no methods to get the MIME type of a file and, as I was in need of such functionality a while back, I’m glad I found this post on CSharpFriends.com (UPDATE: removed link, CSharpFriends.com is dead) which presents a switch statement that maps numerous filename extensions to the appropiate MIME type.

I was somewhat dismayed that someone mentioned using the system registry to lookup the MIME types, and the OP seemed to have gone with this method. Using the registry cuts down your codebase, but that’s little more than a convenience; there are some important issues that pop up when using the registry in this situation:

• It only works if the file extension is known to Windows; either the version of Windows the app is running on knows of the file extension or an application puts the file extension into the registry.
• It binds (read: couples) your app to a third-party component, in a situation where there is no need to.
• It locks you into a specific platform (i.e. it won’t work with Mono). Even if it’s not a major issue, there’s no reason to lock your app to a certain platform when you don’t have to.

UPDATE: As CSharpFriends.com is dead, the code I derived from the original post is below. The FromFileName() function will take a filepath, get the extension from the filename, and return the MIME type of the file.