Thoughts On Modular Design: Click Events And Depth Of Applicability

Posted: 04 Feb 2013 05:30 AM PST

Last week when talking about css click events I asked whether or not we should use them. I suggested the answer lies in how they hold up to Javascript click events when it comes to maintainability and that the question was worthy of a deeper look. Since then, I’ve been thinking about how one might look deeper.

My initial thought was to compare both methods for their depth of applicability and based solely on the results, determine a winner. It’s what I mostly want to attempt in this post.

However, I’m not sure that alone is enough to make this determination in general. Remember this started by wondering about how css click events move behavior into css when we’ve been told for years that behaviors belong to Javascript. Is depth of applicability enough to determine if we should break the separation of structure, presentation, and behavior layers?

My thoughts keep reaching for the word modular and I’d like to use this post as a jumping off point for a longer discussion about modularity in web design. I don’t know if that discussion is necessary to answer the question about click events, but I think it’s a discussion worth having in general.

Billiar balls photographed to show depth of field

Depth of Applicability

You might remember last year I posted a series of articles about changing our css practices. I looked at topics like object oriented css, SMACSS, and DRY CSS, among others. One of the concepts I came back to a lot in the series was how much we couple our html and css and how we can and should reduce that coupling.

In SMACSS, Jonathan Snook snook refers to this coupling as the depth of applicability; the number of generations of html affected by a given css rule.

The greater the depth of our css selectors, the more they are tied to a particular html structure, and the less reusable, and maintainable they are. Ideally we want to reduce the depth of applicability in order to decouple our html and css and so create more modular sites.

For example the selector below has a depth of applicability of 6. It only affects a very specific html structure. We couldn’t easily add the same styles to another span in the document, without another selector.

1	body.article #main #content #intro p span { styles here }

Imagine instead adding a class of “class” for lack of a better word to the span we want to style

1	.class { styles here }

Now we have a depth of applicability of one. It’s no longer tied to any html structure. We can move the class to any element in our html and have the same styles apply. You can’t always drop the depth so low and we don’t necessarily want classes everywhere, but hopefully you can see how the second selector is much more flexible and modular.

It more easily allows us to take a set of styles and convert them into templates for reuse across the one site or across several sites. Again we don’t want classes everywhere. We’re looking to strike a balance between things like maintenance, performance, and readability in our code.

Some things we can do include:

Use child selectors — to limit the scope of selectors to direct descendants instead of all descendants
Use class selectors — to reduce the need for descendant selectors of any kind
Use naming conventions — for more for readable code

With that said how do css click events compare with the javascript they’re replacing where depth of applicability is concerned?

Click Events: CSS and Javascript

Some css click events use only a pseudo selector on the element you want to style and so have a depth of applicability of one. More commonly a pseudo selector is used to to capture the click event and then a sibling element is styled.

The Checkbox Method

Here’s the code I used last week to show the checkbox method.

1  2  3

<label for="toggle">Click Me</label>  <input type="checkbox" id="toggle">  <p class="alert">Some alarming information</p>

The css below requires a depth of applicability of 2 for the click event to work. The default element only has a depth of 1, but to style that element after the click requires a second element that’s a sibling of the element we wish to style

1  2  3  4  5  6  7

.alert {    display: none;  }    :checked ~ .alert {    display: block;  }

Additionally we would hide the input, creating a bit more code overall.

1  2  3  4

input[type=checkbox] {    position: absolute;    left: -999em;  }

Again most of the other css click events work similarly with the same depth of applicability of 2.

Javascript

The simplest way to do the same thing as above with Javascript is a small function to add and remove a class to the element we wish to style.

1 2	<a href="" class="toggle">Click Me</a> <p class="no-alert">Some alarming information</p>

The css below shows a depth of applicability of 1 in both selectors. There’s also no checkbox to hide.

1  2  3  4  5  6  7

.no-alert {    display: none;  }    .alert {    display: block;  }

What is required that wasn’t in the css click event is the Javascript. Here’s some jQuery that can do what we want.

1  2  3  4  5  6  7  8  9  10  11  12

$(document).ready(function() {    $('a.toggle').click(function() {      if($(this).siblings('p').hasClass('no-alert')){        $(this).siblings('p').removeClass('no-alert');        $(this).siblings('p').addClass('alert');      } else {        $(this).siblings('p').removeClass('alert');        $(this).siblings('p').addClass('no-alert');      }      return false;    });  });

The above would also require including jQuery, which you may or may not already be doing. Of course, the above code could be rewritten using Javascript only without the need to include the jQuery library.

Which is Preferred?

Where does the above leave us? The css click event uses a bit more html and css (to hide the checkbox) and also has a depth of applicability slightly greater. The Javascript method on the other had requires Javascript (possibly a library like jQuery depending on how you work with Javascript).

With or without jQuery, the Javascript probably takes a little longer to run (doubtful much, but some) and I suppose runs the risk of the browser not supporting Javascript. Then again the css click event above won’t work in every browser so this is probably a wash.

Overall it doesn’t strike me that the css click method is going to be less maintainable than the Javascript method. There are some pros and cons to each and neither truly outshines the other. We’re not talking huge differences.

Given the above I’ll likely use css click events without worrying that I’m making my code any less maintainable or modular.

Concluding Thoughts

Ok, there’s nothing particularly earth shattering above. I doubt you needed me to run through any of this to determine if you were going to use a css click event or not. I’ll even admit my analysis above may not even be all that great and there are other factors I’ve probably failed to mention.

I mostly wanted to compare the css and javascript click events for modularity as a jumping off point for a greater discussion of modularity in web design. This post is mainly to get both of us thinking about the subject.

Exactly where I’ll head with these posts is something I don’t quite know yet. Here’s what I’m thinking. I want to look at content as a starting point and think about why and how we can make it more modular.

From there I’d like to branch out into the design and think about creating modular design patterns that we can reuse on a single site and across sites. Finally we can consider how we might develop these design patterns. I expect I’ll revisit OOCSS and SMACSS and some of the other topics I looked at last year. I’ll probably end up by taking a deeper look at using Sass as a preprocessor for css.

Just some ideas. I’m not really sure where any of this is heading yet, but I thought I’d share where I’m thinking of going. If you have some ideas for topics you’d like to see, feel free to share in the comments below.

The post Thoughts On Modular Design: Click Events And Depth Of Applicability appeared first on Vanseo Design.