I know with OOCSS classes are preferred rather than IDs for styling,
but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED
for JS hooks? I'm not really very familiar with JS, so not sure if
this is a ridiculous question or not :)
I typically prefer IDs as hooks because it helps to keep my classes clean. Sometimes if a class is expressly used as a JS hook, then one might forget that it is in fact being put to good use.
There have been times at work where someone new comes in after the initial page creation and attempts to "clean up" the code, and removes the class that was the JS hook thinking it did nothing since it wasn't associated with any CSS styles.
On Tue, Jan 10, 2012 at 8:06 AM, Rick Lowes <rlo...@gmail.com> wrote: > I know with OOCSS classes are preferred rather than IDs for styling, > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > for JS hooks? I'm not really very familiar with JS, so not sure if > this is a ridiculous question or not :)
> -- > You received this message because you are subscribed to the Google Groups > "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
Well, ID's are great for JS hooks as they are faster (due the native getElementByID) although this consideration is maybe less of a concern in more modern browsers.
The obvious benefit when using classes is that you can have multiple hooks… this can be useful for setting the state of a widget.
On Tuesday, 10 January 2012 at 14:06, Rick Lowes wrote: > I know with OOCSS classes are preferred rather than IDs for styling, > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > for JS hooks? I'm not really very familiar with JS, so not sure if > this is a ridiculous question or not :)
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com (mailto:object-oriented-css@googlegroups.com). > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com (mailto:object-oriented-css+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> Well, ID's are great for JS hooks as they are faster (due the native getElementByID) although this consideration is maybe less of a concern in more modern browsers.
> The obvious benefit when using classes is that you can have multiple hooks… this can be useful for setting the state of a widget.
> -- > Ad Taylor > @iamadtaylor
> On Tuesday, 10 January 2012 at 14:06, Rick Lowes wrote:
>> I know with OOCSS classes are preferred rather than IDs for styling, >> but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED >> for JS hooks? I'm not really very familiar with JS, so not sure if >> this is a ridiculous question or not :)
>> -- >> You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. >> To post to this group, send email to object-oriented-css@googlegroups.com. >> To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
I say, use whatever you want (elements, ids, classes) and keep doing so until _real_ problems occur or you have a site to test on. Premature optimization is bad often than it is good.
With a good testing environment, http://benchmarkjs.com/ or some benchmarking with console.log( new Date().getTime() ) can make it possible for you to decide what is best.
I have worked with sites with HTML documents counting 10k+ elements, on those it was really important to choose the correct hooks. Typically, though, 10k+ elements are extreme and "normal" sites are not really in any need of premature optimization.
> I know with OOCSS classes are preferred rather than IDs for styling, > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > for JS hooks? I'm not really very familiar with JS, so not sure if > this is a ridiculous question or not :)
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
On Tuesday, 10 January 2012 at 14:56, Ytterström Anders (Adeprimo) wrote: > I say, use whatever you want (elements, ids, classes) and keep doing so until _real_ problems occur or you have a site to test on. Premature optimization is bad often than it is good.
> With a good testing environment, http://benchmarkjs.com/ or some benchmarking with console.log( new Date().getTime() ) can make it possible for you to decide what is best.
> I have worked with sites with HTML documents counting 10k+ elements, on those it was really important to choose the correct hooks. Typically, though, 10k+ elements are extreme and "normal" sites are not really in any need of premature optimization.
> Personally I prefer IDs for unique stuffs. Best of all, though, is to skip JavaScript as long as possible. :)
> /ay
> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
> > I know with OOCSS classes are preferred rather than IDs for styling, > > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > > for JS hooks? I'm not really very familiar with JS, so not sure if > > this is a ridiculous question or not :)
> > -- > > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > > To post to this group, send email to object-oriented-css@googlegroups.com (mailto:object-oriented-css@googlegroups.com). > > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com (mailto:object-oriented-css+unsubscribe@googlegroups.com). > > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com (mailto:object-oriented-css@googlegroups.com). > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com (mailto:object-oriented-css+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
I don't think being consistent with classes vs ID's is premature optimization. Refactoring CSS is incredibly difficult since there isn't any kind of automated testing (that I know of) to check that nothing breaks across browsers when changing HTML, CSS, renaming classes, changing specificity, etc.. there are a lot of variables at play.
Conventions and consistency are why frameworks (including OOCSS) are so popular.
My advice is to use CSS classes - and to a lesser extend elements - for styling hooks. And use ID's and classes prefixed with something like "js-" for Javascript hooks. If you are consistent with never styling ID's or the "js-" classes then it will be much easier to refactor later on. Especially not styling ID's helps avoid specificity wars, while using them for JS hooks takes advantage of the very fast native getElementById selector.
If you're familiar with HTML metadata, I'd bet a contributing factor why microformats were abandoned for HTML5 schemas (schema.org) was that microformats confused metadata with presentation. It was too easy to use the microformat classes for styling which made it much more difficult to change presentation or content without breaking one or the other.
Separation of concerns is a good thing.
2012/1/10 Ytterström Anders (Adeprimo) <Anders.Ytterst...@adeprimo.se>
> I say, use whatever you want (elements, ids, classes) and keep doing so > until _real_ problems occur or you have a site to test on. Premature > optimization is bad often than it is good.
> With a good testing environment, http://benchmarkjs.com/ or some > benchmarking with console.log( new Date().getTime() ) can make it possible > for you to decide what is best.
> I have worked with sites with HTML documents counting 10k+ elements, on > those it was really important to choose the correct hooks. Typically, > though, 10k+ elements are extreme and "normal" sites are not really in any > need of premature optimization.
> If you want to read about it, consider Souders saying about it, for > example:
> Personally I prefer IDs for unique stuffs. Best of all, though, is to skip > JavaScript as long as possible. :)
> /ay
> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
> > I know with OOCSS classes are preferred rather than IDs for styling, > > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > > for JS hooks? I'm not really very familiar with JS, so not sure if > > this is a ridiculous question or not :)
> > -- > > You received this message because you are subscribed to the Google > Groups "Object Oriented CSS" group. > > To post to this group, send email to > object-oriented-css@googlegroups.com. > > To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
I'd say that after working in OOCSS for more than 2 years now, a general rule that works for me is to: 1. create default styling for all html elements 2. extend the defaults with custom styles using classes 3. use ID's sparingly, but there are places where they make sense. Where you only want one instance per page. (layout code)
Now I say this only tailored toward CSS. When doing Javascript, I usually ID the container of the code I'm working with, so I can take advantage speedy selectors (although I haven't tested nor looked into that speed)
> I don't think being consistent with classes vs ID's is premature optimization. Refactoring CSS is incredibly difficult since there isn't any kind of automated testing (that I know of) to check that nothing breaks across browsers when changing HTML, CSS, renaming classes, changing specificity, etc.. there are a lot of variables at play.
> Conventions and consistency are why frameworks (including OOCSS) are so popular.
> My advice is to use CSS classes - and to a lesser extend elements - for styling hooks. And use ID's and classes prefixed with something like "js-" for Javascript hooks. If you are consistent with never styling ID's or the "js-" classes then it will be much easier to refactor later on. Especially not styling ID's helps avoid specificity wars, while using them for JS hooks takes advantage of the very fast native getElementById selector.
> If you're familiar with HTML metadata, I'd bet a contributing factor why microformats were abandoned for HTML5 schemas (schema.org) was that microformats confused metadata with presentation. It was too easy to use the microformat classes for styling which made it much more difficult to change presentation or content without breaking one or the other.
> Separation of concerns is a good thing.
> 2012/1/10 Ytterström Anders (Adeprimo) <Anders.Ytterst...@adeprimo.se> > I say, use whatever you want (elements, ids, classes) and keep doing so until _real_ problems occur or you have a site to test on. Premature optimization is bad often than it is good.
> With a good testing environment, http://benchmarkjs.com/ or some benchmarking with console.log( new Date().getTime() ) can make it possible for you to decide what is best.
> I have worked with sites with HTML documents counting 10k+ elements, on those it was really important to choose the correct hooks. Typically, though, 10k+ elements are extreme and "normal" sites are not really in any need of premature optimization.
> Personally I prefer IDs for unique stuffs. Best of all, though, is to skip JavaScript as long as possible. :)
> /ay
> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
> > I know with OOCSS classes are preferred rather than IDs for styling, > > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > > for JS hooks? I'm not really very familiar with JS, so not sure if > > this is a ridiculous question or not :)
> > -- > > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > > To post to this group, send email to object-oriented-css@googlegroups.com. > > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
On Wed, Jan 11, 2012 at 2:05 PM, Dave Gregory <screwle...@gmail.com> wrote: > I did a blog post about this about a year ago..
> I'd say that after working in OOCSS for more than 2 years now, a general > rule that works for me is to: > 1. create default styling for all html elements > 2. extend the defaults with custom styles using classes > 3. use ID's sparingly, but there are places where they make sense. > Where you only want one instance per page. (layout code)
> Now I say this only tailored toward CSS. When doing Javascript, I > usually ID the container of the code I'm working with, so I can take > advantage speedy selectors (although I haven't tested nor looked into that > speed)
> On Jan 10, 2012, at 7:39 AM, Aeron Glemann wrote:
> I don't think being consistent with classes vs ID's is premature > optimization. Refactoring CSS is incredibly difficult since there isn't any > kind of automated testing (that I know of) to check that nothing breaks > across browsers when changing HTML, CSS, renaming classes, changing > specificity, etc.. there are a lot of variables at play.
> Conventions and consistency are why frameworks (including OOCSS) are so > popular.
> My advice is to use CSS classes - and to a lesser extend elements - for > styling hooks. And use ID's and classes prefixed with something like "js-" > for Javascript hooks. If you are consistent with never styling ID's or the > "js-" classes then it will be much easier to refactor later on. Especially > not styling ID's helps avoid specificity wars, while using them for JS > hooks takes advantage of the very fast native getElementById selector.
> If you're familiar with HTML metadata, I'd bet a contributing factor why > microformats were abandoned for HTML5 schemas (schema.org) was that > microformats confused metadata with presentation. It was too easy to use > the microformat classes for styling which made it much more difficult to > change presentation or content without breaking one or the other.
> Separation of concerns is a good thing.
> 2012/1/10 Ytterström Anders (Adeprimo) <Anders.Ytterst...@adeprimo.se>
>> I say, use whatever you want (elements, ids, classes) and keep doing so >> until _real_ problems occur or you have a site to test on. Premature >> optimization is bad often than it is good.
>> With a good testing environment, http://benchmarkjs.com/ or some >> benchmarking with console.log( new Date().getTime() ) can make it possible >> for you to decide what is best.
>> I have worked with sites with HTML documents counting 10k+ elements, on >> those it was really important to choose the correct hooks. Typically, >> though, 10k+ elements are extreme and "normal" sites are not really in any >> need of premature optimization.
>> If you want to read about it, consider Souders saying about it, for >> example:
>> Personally I prefer IDs for unique stuffs. Best of all, though, is to >> skip JavaScript as long as possible. :)
>> /ay
>> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
>> > I know with OOCSS classes are preferred rather than IDs for styling, >> > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED >> > for JS hooks? I'm not really very familiar with JS, so not sure if >> > this is a ridiculous question or not :)
>> > -- >> > You received this message because you are subscribed to the Google >> Groups "Object Oriented CSS" group. >> > To post to this group, send email to >> object-oriented-css@googlegroups.com. >> > To unsubscribe from this group, send email to >> object-oriented-css+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> http://groups.google.com/group/object-oriented-css?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Object Oriented CSS" group. >> To post to this group, send email to object-oriented-css@googlegroups.com >> . >> To unsubscribe from this group, send email to >> object-oriented-css+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
Oh, yeah js- for JavaScript hooks is one of my favorites too.
I'm not sure if it's completely relevant to this topic, but I really like this presentation on using JavaScript with OOCSS. It describes extending OOCSS with live behavior classes.
> I don't think being consistent with classes vs ID's is premature optimization. Refactoring CSS is incredibly difficult since there isn't any kind of automated testing (that I know of) to check that nothing breaks across browsers when changing HTML, CSS, renaming classes, changing specificity, etc.. there are a lot of variables at play.
> Conventions and consistency are why frameworks (including OOCSS) are so popular.
> My advice is to use CSS classes - and to a lesser extend elements - for styling hooks. And use ID's and classes prefixed with something like "js-" for Javascript hooks. If you are consistent with never styling ID's or the "js-" classes then it will be much easier to refactor later on. Especially not styling ID's helps avoid specificity wars, while using them for JS hooks takes advantage of the very fast native getElementById selector.
> If you're familiar with HTML metadata, I'd bet a contributing factor why microformats were abandoned for HTML5 schemas (schema.org) was that microformats confused metadata with presentation. It was too easy to use the microformat classes for styling which made it much more difficult to change presentation or content without breaking one or the other.
> Separation of concerns is a good thing.
> 2012/1/10 Ytterström Anders (Adeprimo) <Anders.Ytterst...@adeprimo.se> > I say, use whatever you want (elements, ids, classes) and keep doing so until _real_ problems occur or you have a site to test on. Premature optimization is bad often than it is good.
> With a good testing environment, http://benchmarkjs.com/ or some benchmarking with console.log( new Date().getTime() ) can make it possible for you to decide what is best.
> I have worked with sites with HTML documents counting 10k+ elements, on those it was really important to choose the correct hooks. Typically, though, 10k+ elements are extreme and "normal" sites are not really in any need of premature optimization.
> Personally I prefer IDs for unique stuffs. Best of all, though, is to skip JavaScript as long as possible. :)
> /ay
> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
> > I know with OOCSS classes are preferred rather than IDs for styling, > > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > > for JS hooks? I'm not really very familiar with JS, so not sure if > > this is a ridiculous question or not :)
> > -- > > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > > To post to this group, send email to object-oriented-css@googlegroups.com. > > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> Oh, yeah js- for JavaScript hooks is one of my favorites too.
> I'm not sure if it's completely relevant to this topic, but I really like this presentation on using JavaScript with OOCSS. It describes extending OOCSS with live behavior classes.
> On 11/01/2012, at 4:39 AM, Aeron Glemann <aeron.glem...@gmail.com> wrote:
>> I don't think being consistent with classes vs ID's is premature optimization. Refactoring CSS is incredibly difficult since there isn't any kind of automated testing (that I know of) to check that nothing breaks across browsers when changing HTML, CSS, renaming classes, changing specificity, etc.. there are a lot of variables at play.
>> Conventions and consistency are why frameworks (including OOCSS) are so popular.
>> My advice is to use CSS classes - and to a lesser extend elements - for styling hooks. And use ID's and classes prefixed with something like "js-" for Javascript hooks. If you are consistent with never styling ID's or the "js-" classes then it will be much easier to refactor later on. Especially not styling ID's helps avoid specificity wars, while using them for JS hooks takes advantage of the very fast native getElementById selector.
>> If you're familiar with HTML metadata, I'd bet a contributing factor why microformats were abandoned for HTML5 schemas (schema.org) was that microformats confused metadata with presentation. It was too easy to use the microformat classes for styling which made it much more difficult to change presentation or content without breaking one or the other.
>> Separation of concerns is a good thing.
>> 2012/1/10 Ytterström Anders (Adeprimo) <Anders.Ytterst...@adeprimo.se> >> I say, use whatever you want (elements, ids, classes) and keep doing so until _real_ problems occur or you have a site to test on. Premature optimization is bad often than it is good.
>> With a good testing environment, http://benchmarkjs.com/ or some benchmarking with console.log( new Date().getTime() ) can make it possible for you to decide what is best.
>> I have worked with sites with HTML documents counting 10k+ elements, on those it was really important to choose the correct hooks. Typically, though, 10k+ elements are extreme and "normal" sites are not really in any need of premature optimization.
>> Personally I prefer IDs for unique stuffs. Best of all, though, is to skip JavaScript as long as possible. :)
>> /ay
>> 10 jan 2012 kl. 15:06 skrev Rick Lowes:
>> > I know with OOCSS classes are preferred rather than IDs for styling, >> > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED >> > for JS hooks? I'm not really very familiar with JS, so not sure if >> > this is a ridiculous question or not :)
>> > -- >> > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. >> > To post to this group, send email to object-oriented-css@googlegroups.com. >> > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. >> > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. >> To post to this group, send email to object-oriented-css@googlegroups.com. >> To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. >> To post to this group, send email to object-oriented-css@googlegroups.com. >> To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group. > To post to this group, send email to object-oriented-css@googlegroups.com. > To unsubscribe from this group, send email to object-oriented-css+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.
Hi Rick, Class and ID names perform up to 3 jobs: 1. Provide a hook for CSS to apply style rules 2. Provide a hook for JS to find and manipulate the element on the page. 3. A small agreed-upon set of class names can provide extra information about the content a.k.a. Microformats (http://microformats.org/)
My current practice is based on two principles.
*Principle #1: Each class or ID name should do only one job.* While it is possible to re-use a class/ID name for more than one task it's not a good idea because * It couples your HTML, CSS and JS tightly together. As an example, Let's say we have <div class="foo"> and are applying styles to and using it as a JS hook. If we later decide that the .foo{} styles are no longer appropriate for that div but we still want our JS to target it. Now we have to edit our JS as well as our CSS. * It makes the intent of your code harder to deduce for other coders (even the future you).
*Principle #2: Each Job is different* Each Job has different criteria for deciding 1. whether to use a class or ID as a hook 2. how to name your class or ID.
*Job 1. [A hook for CSS]* OOCSS guides you here on how to name your classes and whether to use class or ID. My personal approach (YMMV) is * First style bare elements to provide reasonable defaults (I use normalize.css (http://necolas.github.com/normalize.css/) with a few per-site tweaks) * Use classes (in the OOCSS style) to apply any further styling required. I never mix classes and elements in selectors. Andy Hume has an excellent presentation from SXSW Interactive last year where he discusses this issue with more clarity that I could (audio: http://schedule.sxsw.com/2012/events/event_IAP9410 and slides: https://speakerdeck.com/u/andyhume/p/css-for-grown-ups-maturing-best-...)
*Job 2. [A hook for JS]* I prefix any class or ID I use as a JS hook with 'js-'. Use an ID if you need to uniquely identify the element, use a class-name if you need to target more than one element. Do whatever makes your code the most readable and easy to understand. Only do something different if you find an actual performance problem (see @madr comments on premature optimization earlier in this thread). JS engine and CSS selector performance vary a lot between browsers (and browser versions) so it is difficult to give definitive advice on the performance of classes versus IDs as JS hooks. There are differences but whether they are relevant is harder to answer. The best advice I have seen (and will echo here) is that you don't get to care about CSS/JS selector performance until you have covered *all *the "big win" front-end performance optimizations - proper caching, minimizing HTTP requests etc. -see https://developers.google.com/speed/ for the gory details.
*Job 3 [Microformats]* Rules for naming defined at http://microformats.org/. @aglemann has mentioned that microformats confuse metadata with styling (I happen to agree with this) but they can be used safely & sanely as long as you consider the microformat class names "off-limits" to styling and JS.
On Wednesday, 11 January 2012 03:06:17 UTC+13, Rick Lowes wrote:
> I know with OOCSS classes are preferred rather than IDs for styling, > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > for JS hooks? I'm not really very familiar with JS, so not sure if > this is a ridiculous question or not :)
This is great advice (naturally I agree with all of it ;)
The only thing I would say about #3... is AFAIK microformats are being
phased out in favor of schemas (http://schema.org/docs/schemas.html) which
use custom attributes so you no longer are tempted to style those .fn
classes ;)
In our case we have a #4:
4. Provide a hook for Selenium (automated QA testing) to find elements on
the page.
Which ran into the same problem, where re-factoring CSS or JS
un-necessarily broke the Selenium tests. Initially, I've treated this the
same as JS: use either id's or classes prefixed with ".qa-" - the rationale
there is:
- id's should never be changed. You might add an id to an element that
doesn't have one, but so far haven't come across a case where it was
necessary to rename an id affecting the JS or QA tests.
- CSS won't touch the .js- or .qa- classes. In fact seeing the class there
alerts the developer that there is a test running on those elements so they
will take care not to affect the test.
The downside to this, is we're being very defensive, but ending up with
elements like:
<div class="review js-review qa-review">
etc, which doesn't feel right at all. So the other option would be to not
have specific QA selectors, and just fix the broken tests everytime the
markup changes - which happens to be a lot right now cause we're doing a
re-platforming, but presumably shouldn't happen that often on a mature,
stable site.
On Sat, Jun 30, 2012 at 9:09 PM, Eoin Kelly <eoin.p.ke...@gmail.com> wrote:
> Hi Rick,
> Class and ID names perform up to 3 jobs:
> 1. Provide a hook for CSS to apply style rules
> 2. Provide a hook for JS to find and manipulate the element on the page.
> 3. A small agreed-upon set of class names can provide extra information
> about the content a.k.a. Microformats (http://microformats.org/)
> My current practice is based on two principles.
> *Principle #1: Each class or ID name should do only one job.*
> While it is possible to re-use a class/ID name for more than one task it's
> not a good idea because
> * It couples your HTML, CSS and JS tightly together. As an example, Let's
> say we have <div class="foo"> and are applying styles to and using it as a
> JS hook. If we later decide that the .foo{} styles are no longer
> appropriate for that div but we still want our JS to target it. Now we have
> to edit our JS as well as our CSS.
> * It makes the intent of your code harder to deduce for other coders (even
> the future you).
> *Principle #2: Each Job is different*
> Each Job has different criteria for deciding
> 1. whether to use a class or ID as a hook
> 2. how to name your class or ID.
> *Job 1. [A hook for CSS]*
> OOCSS guides you here on how to name your classes and whether to use class
> or ID. My personal approach (YMMV) is
> * First style bare elements to provide reasonable defaults (I use
> normalize.css (http://necolas.github.com/normalize.css/) with a few
> per-site tweaks)
> * Use classes (in the OOCSS style) to apply any further styling required.
> I never mix classes and elements in selectors. Andy Hume has an excellent
> presentation from SXSW Interactive last year where he discusses this issue
> with more clarity that I could (audio:
> http://schedule.sxsw.com/2012/events/event_IAP9410 and slides:
> https://speakerdeck.com/u/andyhume/p/css-for-grown-ups-maturing-best-... > )
> *Job 2. [A hook for JS]*
> I prefix any class or ID I use as a JS hook with 'js-'. Use an ID if you
> need to uniquely identify the element, use a class-name if you need to
> target more than one element. Do whatever makes your code the most readable
> and easy to understand. Only do something different if you find an actual
> performance problem (see @madr comments on premature optimization earlier
> in this thread). JS engine and CSS selector performance vary a lot between
> browsers (and browser versions) so it is difficult to give definitive
> advice on the performance of classes versus IDs as JS hooks. There are
> differences but whether they are relevant is harder to answer. The best
> advice I have seen (and will echo here) is that you don't get to care about
> CSS/JS selector performance until you have covered *all *the "big win"
> front-end performance optimizations - proper caching, minimizing HTTP
> requests etc. -see https://developers.google.com/speed/ for the gory
> details.
> *Job 3 [Microformats]*
> Rules for naming defined at http://microformats.org/. @aglemann has
> mentioned that microformats confuse metadata with styling (I happen to
> agree with this) but they can be used safely & sanely as long as you
> consider the microformat class names "off-limits" to styling and JS.
> HTH
> /Eoin/
> On Wednesday, 11 January 2012 03:06:17 UTC+13, Rick Lowes wrote:
>> I know with OOCSS classes are preferred rather than IDs for styling,
>> but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED
>> for JS hooks? I'm not really very familiar with JS, so not sure if
>> this is a ridiculous question or not :)
> To post to this group, send email to object-oriented-css@googlegroups.com.
> To unsubscribe from this group, send email to
> object-oriented-css+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/object-oriented-css?hl=en.
I hadn't considered hanging unit tests off separate classes but it makes sense - I'll try to adopt that in future. I know what you mean about
<div class="review js-review qa-review">
not "feeling" right. I used to feel the same way but these days I can't think of a single good reason not to do this (other than some sort of vague guilt about "classitis"). I can't speak for other devs but I grew up learning that classes and IDs should be named based on the content - we were told that class and ID names were an opportunity to endow your content with the magical pixie dust of *semantics*. But semantics is all about the relationship between symbols and meaning. And meaning depends on our audience - *who* is reading the code and *what* are they trying to get out of it. To my mind, our class and ID names are symbols that communicate to two audiences (ignoring microformats as a special case) 1. Our other code (the robots) 2. Other developers
*Nobody else reads or cares about our class and ID names*. For some reason it took me an inordinately long time to accept that last statement (not the sharpest tool in the box sometimes). Even now it still "feels" wrong but I haven't found any compelling evidence against it. And y'know what, our robots (other code) don't care about what names we use either! - the browser would be just as happy with
<div id="iuj" class="xgt fjl">
as long as our CSS and JS use the same symbols. So our only audience for class and ID names are other developers and the *meaning* they want to extract from our code is knowledge of how it is structured and how to safely make changes.
We could create a completely unique vocabulary for each site (rough analogy with an XML approach) but some sort of shared set of symbols that have an agreed upon meaning (the HTML approach) really speeds up communication. A sensible set of prefixes and clear separation of concerns goes a long way towards this I think. To my mind, this is one of the big wins of the OOCSS approach. Looking at
<div class="review js-review qa-review">
again, I can guess that this block is touched by JS and has at least one unit test associated with it and that the dev team that created it have labeled it a "review". Compare this with
<div class="review">
where I only learn that, in the vocabularly of the devs that created this page, this block is described as a "review" which doesn't tell me much, especially as in the real world it's likely to appear as
<div class="review"> <h1>Review</h1> ... </div>
I have heard folks argue that this approach *bloats* the markup - certainly the markup gets bigger *but* (in my experience at least) my CSS is much smaller and I would question how much of a real world performance problem of slightly bigger markup is provided it is served using gzip compression.
On Tuesday, 10 January 2012 14:06:17 UTC, Rick Lowes wrote:
> I know with OOCSS classes are preferred rather than IDs for styling, > but IDs are acceptable as Javascript hooks. However, are IDs PREFERRED > for JS hooks? I'm not really very familiar with JS, so not sure if > this is a ridiculous question or not :)
IDs are indeed preferred for Javascript hooks - they're the fastest way to get a reference to an element (using the document.getElementById() method). However, most modern browsers have Javascript functions that make CSS selector lookups very fast as well, as long as they're not too complicated.
> Hey, I tend to stick with classes using the 'js-' namespace for > javaScript hooks and use data-attributes for DOM interaction.
> On Tuesday, 10 January 2012 14:06:17 UTC, Rick Lowes wrote:
> I know with OOCSS classes are preferred rather than IDs for styling,
> but IDs are acceptable as Javascript hooks. However, are IDs
> PREFERRED
> for JS hooks? I'm not really very familiar with JS, so not sure if
> this is a ridiculous question or not :)
> -- > You received this message because you are subscribed to the Google > Groups "Object Oriented CSS" group.
> To view this discussion on the web visit > https://groups.google.com/d/msg/object-oriented-css/-/jz9sbg6uX54J.
> To post to this group, send email to object-oriented-css@googlegroups.com.
> To unsubscribe from this group, send email to > object-oriented-css+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/object-oriented-css?hl=en.
