Should I avoid using jQuery selectors on CSS classes that are defined in style sheets?

Question

I am concerned with using CSS classes that are defined in style sheets with my jQuery selectors. The reason for this is when a CSS class is defined in a style sheet there are many reasons for a developer/designer to change the name of the class or how it is used in the html that is detached from the jQuery selector that also uses the class. There is nothing obvious that tells the developer/designer that they need to account for JavaScript functionality when making this change.

Would it be better to just avoid coupling jQuery selectors with legit CSS classes, but instead use CSS classes that are not tied to any styles and have a say a prefix like 'j_' that makes it's purpose obvious that is to be used exclusively as a jQuery selector? This would make the coupling less fragile at the cost of an extra class name in the markup. This would also make validation engines that find undefined classes less useful but the prefix would hopefully make it obvious that those classes serve a purpose as jQuery selectors.

....

I understand that CSS classes should be named based on their functionality. I do not however believe that naming the class that way solves the problem. Developers/Designers will still change the name even though their new name is still describing the same functionality, or they may modify where it is used. In these cases it is not obvious that these changes will impact the JavaScript functionality.

Answer 1

I vote for the lean approach. If you have good class names that make sense for CSS and jQuery--use them. If the names don't make sense for jQuery, then add new ones or rename the existing classes.

If you are worried about developers breaking the script by renaming classes, then just add a note to the CSS that they need to search for jQuery references when changing class names.

Answer 2

The css class name should describe the function of the element, not the style that it applies to it. If you have a sidebar that is floated to the left, call the class sidebar, not leftFloat. This way you can put the style of the sidebar in the sidebar class in css and apply whatever jquery functions you need.

Edited to clarify one of the comments: You shouldn't have to rename the classes or id's of the elements. If you have a sidebar, then maybe it changes to be a toolbar instead, or a top navigation. Does it matter that it is still called a sidebar? The user never notices. Or you could give everything really abstract names, like navigation-pane and main-content.

I started a webapp with jQuery for internal use last week, and I've changing the name of only one id, because I needed to generalize it more. Apart from that every class and id kept exactly the same name.

Answer 3

I tend to agree with you: it’s better to separate the “visual” classes from the “functional” classes.

But there may be some cases where class name makes it obvious that a class has some functional effects. For example, an .input-edited class may be set by jQuery and styled with CSS at the same time.

Answer 4

Try using more varied selectors as well. If the markup isn't going to change much but your class names might, try to use class selectors as little as possible. If your classes aren't going to change much, but your markup will, use more classes. Really, your jQuery selectors should be just as semantic as anything else you write. Readability counts.

Answer 5

It's good to respect the separation of concerns. But for this to work, elements should be named semantically, by the role they play on the page.

Good:

<div id="nav">...</div>
<div id="sidebar">...</div>
<ul class="productsList">
  <li>...</li>
</ul>

Bad:

<span class="Verdana11">...</span>
<div class="blueBox">...</div>
<ul class="bulletedList">
  <li>...</li>
</ul>

Etc. Notice that the elements are named based on what function the element serves on the page. Styles will change -- you can count on it. But the roles shouldn't (barring a redesign of the site, which necessarily means you'll be re-coding anyway). So a sidebar will always be a sidebar regardless of whether the font-size changes or whether the border gets removed at some point down the line.

As you write your scripts, you should be targeting elements based on class names that won't change. This is only possible if you've named your elements semantically -- and your co-developers should be doing the same.

Answer 6

I think it is absolutely fine to use same classes for CSS and scripts.

Imagine

<div class=css-class>
  <div class=script-class>
    <address> <!--for semantic "this is my homepage"-->

isn't it ugly enough? One div is slightly better. One address is slightly even better. One class is slightly even better.

Problem "they change classes" is solved by comments, tests and careful editing.

Answer 7

I agree with the guys saying that CSS classes should be semantic and not representing visual appearence, but I still think your question is great concerning the "true" separation between layout and behaviour.

I think it would be best to put classes that are only used by a script inside a separate stylesheet. Include that through JS (as it is not needed if JS is not available). Example would be ".hover" or ".current", obviously only if that is done through scripting, for example effects on blocklevel elements. On inline elements you'd probably just use the CSS pseudo class.

As a HTML/CSS developer I might sometimes fringe when people say "Oh, there already is a CSS class, I can just hook in on that", but its totally alright. After all the class attribute is not exclusive to CSS. It is a HTML attribute. Regarding the fear of deleting CSS rules that are still used in JS, lets be honest: With CSS on large sites you can never be totally sure were it is used, no matter if its in JS or HTML.

Answer 8

I think your problem is purely conceptual. The class attribute in HTML does not define a CSS class. It defines the element's semantic class. It just so happens that CSS uses these classes to apply styles (in much the same way as jQuery selectors use them to apply other functionality). There is nothing preventing you from having classes that aren't defined in a stylesheet, or that have no style information at all. As such, all classes should be considered a part of the code, not the styling. The code dictates the classes, the CSS just piggybacks on the semantic markup to apply styles. Thus the CSS should never be dictating class names, and no designer should ever be changing the class names. I realize that at first glance this probably sounds very much like the other answers that (very correctly) advise you to "use semantic names", but there is a subtle conceptual difference here: the classes are the masters, the CSS styles are the slaves.

References: this website makes my point quite clearly; w3schools also mentions it briefly.

Answer 9

I was going to post this as a comment on Marius' excellent answer, but it started to get long in the tooth and I wanted to add an example.

Don't think of them as "CSS classes". They aren't. Classes are part of the HTML specification and are in no way more associated with CSS than with JavaScript.

Classes exist to add information to HTML elements. Is it a news item? Is it a widget? Is it disabled? HTML has no way to specify these properties save with classes. Some classes have style information associated with them (news items should have their titles, publish dates, and bylines nicely formatted), some have functionality associated with them (widgets need initialized), and others have both (elements become disabled programmatically and should be hidden or "faded").

There is absolutely no reason not to use the same classes in CSS and JavaScript — as long as both are appropriate to the information that the class represents.