Week notes: Forbes, withdrawal symptoms and a touch of classes

Just as the party gets into full swing, January storms into the room, unplugs the stereo, disco lights, and starts shouting something about acting your age.

Yes, Christmas is over. Much as those who have undergone amputation can suffer from "phantom limb", I'm suffering from "phantom beer" and "phantom confectionary". I tried to go cold-turkey, but then... oh just make your own jokes, I can't be bothered.

Lanyrd (that's us!) turned up in Forbes' Five UK Tech Companies to Watch in 2012. If you're keeping up to date with this blog then I guess you're already watching us, well done! You'll be able to say you knew us before we were cool. Unless we're already cool, in which case, yey!

We've spent the week adding the finishing touches to a NEW FEATURE (codenamed 'Meat mallet'), which promises to do particular thing it does in appropriate ways. Watch out for a post on that next week.

Markup-dependant JavaScript

We had a little discussion this week on how we might solve the issue of changing markup and breaking script. Imagine a bit of markup like this:

<img class="avatar">

That later changes to...

<div class="avatar"><img></div>

Not an uncommon thing to do, probably because the extra element is needed for style reasons. However, if JavaScript was using 'avatar' to select images, stuff is now broken.

Both Natalie and I are used to working on smaller projects, where you'd get around this by having a little bit in your brain that shouts "Ohh, I think JS uses this" and fixing it. But Lanyrd's CSS & JS is now too big to entirely fit in both of our brains.

When I add a new class to an element, it's pretty easy to search though the CSS files for ".whatever" to ensure my new class is unique. JS is more tricky, as ".whatever" could be an object property, or the class name could be constructed from sub-strings.

I asked the Twitters what they thought and turns out a lot of people don't share class names between JS and CSS, instead opting for something like:

<img class="avatar js-avatar">

...where one class is used for styling, and the other for JS. When the code was changed for style reasons, it would become:

<div class="avatar"><img class="js-avatar"></div>

The repetition isn't great, neither is having very similar class names on separate elements, but it works.

The separation left a bad taste in our respective mouths, so we're trialling a different system, using documentation rather than separation:

<img {#js#} class="photo {#js#}avatar">

'{#' and '#}' open and close single line comments in Django's templating language, so those little tokens don't hit the browser.

The above signals that the JS depends on the "avatar" class name and the "img" tag name. The "photo" class name isn't used by JS, and can be (re)moved without worry. This doesn't mean you can't change/move the "avatar" class, but acts as a reminder that the JS will need updating and testing too.

Obviously the best way of dealing with this is to have a sturdy suite of tests that will quickly identify markup that looks wonky to JS, but in the mean time the documentation will do. Since it's a trial, we're happy for it to fail, we'll let you know if it does.

Do you have a similar or alternative system? Let us know in the comments!

You need to sign in to comment on this entry


Time 4:32pm

Date 6th January 2012


Stay in the loop

Subscribe to our blog

Stay in the moment

Follow us on Twitter