3

Being a front-end developer working in a team, I have found myself solving a recurring problem many times. For example, much of our frontend javascript code is written using jQuery and CSS selectors (mostly targeting a CSS "class"). The problem is, is that many times another developer that is fixing some CSS code will remove a class or will change the DOM element nesting it under another element making the JS code break.

To prevent this, my idea was to use/add a "data-js" attribute to each element that we want to use for Javascript. However I am not sure about the performance of a jQuery selector written like this:

$('[data-js="my_js_selector"]').click();

Another idea I had, was to add a js-specific class to a dom element that is somehow manipulated by Javascript:

<a href="lol.com" class="js-link">link</a>

and then calling it simply with $('.js-link').click()

It would be very nice that you could only look into HTML and tell that some element has some Javascript manipulations attached without actually looking into the JS code.

Is this a good idea? Or are there some other best practices to separate JS-triggering from CSS styling?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Max101
  • 593
  • 1
  • 5
  • 18
  • Have a look here re perf: http://stackoverflow.com/questions/6533285/jquery-select-by-class-vs-select-by-attribute – SW4 Mar 27 '14 at 15:17
  • 5
    it is bad for performance!!! if you don't have any choice a prefixed class name like `js-classname` can be used – Arun P Johny Mar 27 '14 at 15:17
  • see http://jsperf.com/id-vs-class-vs-tag-selectors/2 – Arun P Johny Mar 27 '14 at 15:19
  • You shouldn't let them change the classes you specify. Classes became markers as well with jQuery, so they become like values expected in a variable. A GOOD practice is to respect, and enforce respect, to the used classes and their purpose. Use unique and weird class names, a ".wierdClass" selector for your features, and kick their butt if they don't respect your classes. Classes in a site MUST be a convention previously defined. – Luis Masuelli Mar 27 '14 at 15:22
  • The real solution to your problem is team discipline. Luis Masuelli is correct to a point. A functioning front end team of developers will code to a specific standard, certainly where class interoperability in markup is concerned. That said, randomly removing classes because they don't fit "your" code style is dumb in team environments. If you must, a prefix to your classes indicating they are JS is preferable above other options. – David Barker Mar 27 '14 at 15:28
  • David & Luis, Thanks for your answers. I do agree with you on the discipline fact, however, as projects grow larger, and projects specs change (with some project owners quite often), changes in the frontend are a must, but what is the best practice to be able to make "style" changes without affecting the functionality ('JS')... That is more the point of my question. Cheers! – Max101 Mar 27 '14 at 16:54
  • What makes you think that `[data-js="my_js_selector"]` is a 'JavaScript selector'? It's a [CSS 2.1 attribute-selector](http://www.w3.org/TR/CSS21/selector.html#attribute-selectors), so the entire question seems based on a flawed understanding of the subject, and also highly subjective and opinion based. @Arun: what's bad for performance? I think I'm missing your point, and perhaps something in the question itself? – David Thomas Mar 27 '14 at 18:27
  • 1
    Hi David. No one was born with infinite knowledge. I wouldn't be asking this question if I knew the answer. Nothing makes me think that the data-js is a javascript selector, it was as I said, just an idea, and "flawed understanding of the subject" is why I am asking the question yes. – Max101 Mar 28 '14 at 09:26

1 Answers1

1

In Scalable and Modular Architecture for CSS (SMACSS), Jonathan Snook teaches that a "state" class such as the one you proposed with .js-link is the best approach.

The relevant discussion is in the section on State Rules:

Sub-module styles are applied to an element at render time and then are never changed again. State styles, however, are applied to elements to indicate a change in state while the page is still running on the client machine.

For example, clicking on a tab will activate that tab. Therefore, an is-active or is-tab-active class is appropriate. Clicking on a dialog close button will hide the dialog. Therefore, an is-hidden class is appropriate.

This contradicts what two commenters said. CSS code and classes should be flexible; CSS developers should be able to refactor and improve code without worrying about breaking functionality not related to presentation.

The point made by @ArunPJohny supports the state class approach. Engines are unfortunately not optimized to recognize data- attributes any more than they are to recognize arbitrary custom attributes, such as foo-.

cantera
  • 24,479
  • 25
  • 95
  • 138