Say you have a module. Every site has modules, right?
<div class="module">
</div>
Perfect! We did it!
But now, a New Circumstance™ comes along. This module isn’t going to work exactly as is. It’s pretty close, but in this New Circumstance™ the module is going to need some extra bottom margin.
How do you handle that? Let’s explore some ways.
Body class affects it
Are all the modules on a particular page or area of your site like this? Perhaps you can add a class to that page (or area):
<body class="books-page">
...
<div class="module">
</div>
.module {
/* normal style */
}
body.books-page .module {
/* variation styles */
}
You don’t really need to tag qualify the .books-page
, but I often do because it’s no big deal in this circumstance and reminds me what’s going on.
Sass is useful in these circumstances because the nesting kinda ties the room together.
.module {
/* normal style */
aside.books & {
/* variation style */
}
}
Totally new class
Perhaps the new style is different enough that you are going to call it something different.
<div class="solitary-module">
</div>
.module {
/* normal style */
}
.solitary-module {
/* alternate style */
}
If the style are pretty similar, you could:
.module, .solitary-module {
/* normal style */
}
.solitary-module {
/* variation styles */
}
Which is exactly what @extend does in Sass:
.module {
/* normal style */
}
.solitary-module {
@extend .module; /* could be a %placeholder selector */
/* variation style */
}
Double up classes
Perhaps you create an additional class, but that class isn’t meant to work on it’s own, it’s just a variation.
<div class="module module-books">
</div>
.module {
/* normal styles */
}
.module.module-books {
/* variation styles */
/* you don't HAVE to double up the classes here in the CSS, but it enforces the connection (while increasing specificity) */
}
Data-attribute variations
I don’t think this is particularly common, but I kinda dig it.
<div class="module" data-variation="books">
</div>
Attributes are like classes (same specificity) but can have values.
.module {
/* normal styles */
}
.module[data-variation="books"] {
/* variation styles */
}
Reads pretty well.
Inline styles
Is this variation rare? Perhaps just an inline style will work.
<div class="module" style="margin-bottom: 40px;">
</div>
Typically frowned upon (not reusable), but if it’s a one-off thing, it does the job.
Shame.css
You can always deal with it later with shame.css!
<div class="module chris-did-this">
</div>
/* I will totally deal with this later I promise */
.chris-did-this {
/* variation styles */
}
How do you do it?
Data attributes are meant to carry data, so using it to style things feels weird.
I’m personally for the “add extra class” (double up) for different variations idea. It just feels “right” and keeps the modular aspect.
I agree with you that data attributes are meant for carrying data, but It can also be used for styles as we want to reduce the number of classes we add to the dom, and many a times a data attribute can be helpful to make the code more semantic.
Anything that makes the code less, and cleaner should be preferred.
Personally I use the “add extra class” or “body class effects it” variants. Their simple and keep you from cluttering up your style sheet. However if I find myself doing this more than a couple times I go back and recreate it to be more flexible.
The nifty thing about data attributes is that you can completely skip adding the class and just leverage attributes.
For example, this could be a default module:
And this could be a fancy module:
The CSS is pretty straightforward:
You can also make your own custom module-specific “classes” by using the
[~=]
selector:It appears that some of my code blocks weren’t quite right
The default module is:
and the fancy module is:
Hmm, I quite like this idea..
The thing is, are these data attributes more semantic than classes, or are they less? Also, when do you choose which one to use?
I am personally a fan of the “Totally new class” method as the logic is similar to OOP principals, where the formatting of the class name would be
.super-class--sub-class
.This allows regular class names to use hyphens while the double hyphen signifies that the super class is being extended by a sub class, which is where rules can be added and rules inherited from the super class can be overridden.
Bad idea. People will think that you are using BOM and get confused that you are not using it.
Cheers.
I have to agree that I don’t think it’s a great idea and doesn’t really imply OOP inheritance principles. Think of a Java class for instance. It’s been a while, but iirc its something like public Mustang extends Car{} (I’ve been in C# for years but many languages use something close to that syntax). What you’re implying is almost the reverse and without a preprocessor would be the complete opposite of inheritance since you’d have to maintain two CSS classes when the base class changes.
That said, I’m a fan of the human readable double class style. With programming languages yes the base class comes last and in markup it comes first but its not a complicated concept to grasp and closer in line with what programmers are used to, and eventually we want to move into a world where we separate concerns where the people working on the styles don’t need to be the people writing HTML as well. The less complicated we make applying styles (class plus class plus class equals result) rather than looking through a style guide for the specific class for an emphasis button with a red background, for instance.
Plus, you’d be creating a lot of barely used classes and increasing payload for very specific instances instead of promoting reusable components.
Edit (am I missing something or can I not edit my original post from my tablet?)
I see what you’re doing won’t really break inheritance rules, although it does complicate them by creating several variants end users need to dig through to get what they need over combing classes. It also creates a lot of overhead for little return. I do apologize for wrongly implying that you’d need to change base and sub classes using your model but still stand firm that the more specific sub modules become the more maintenance will be required by needing to add new classes for each instance instead of having a disposal of common classes to build modules upon. Forgive me, I’m on a tablet and its 2am. But I still maintain my stance ^_^
Thanks for the feedback. Constructive criticism is always good, and I do admit this model doesn’t work well for all projects and I’ve many times needed to instead use the double class model.
@wqeqwewq I’m not familiar with the term BOM and a google search revealed very little. If you’re referring to something like BEM I do see your point and it could be confusing, but is only an issue if working with a team or releasing something to the public web development community.
@Eric Points well taken, however aside from the philosophy behind the naming and formatting of these two examples I see no technical difference:
.baseclass--modifier
and.superclass--subclass
As for the order of the super class and sub class, you are correct. PHP, Java, and ActionScript (among others) all use the syntax structure ofSubclass extends Superclass {}
. I am well aware of this and format the css classes this way intentionally because, for me at least, it’s quicker and easier to tell what a class is doing and keeps things organized in the css file.As for the issues that arise as modules become increasingly complex, thus necessitating an entirely new sub class, you do make a good point – more overhead for little return. One way to overcome this is to use a mixture of the double class model (as utility classes) with the super/sub class model.
When working with a team or releasing to the public I certainly adhere to the style guide and formatting model already in place, but for my personal projects this model works well for me. That said, I appreciate your comments and will have to rethink if this model is best for me.
Sorry, meant BEM not BOM:
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
Most of the time I “double up classes,” though I rarely adopt that level of specificity in my CSS if I can avoid it (the exception being states of a class, a la
is-active
). If I feel the new pattern is similar now, but has a high risk for splintering off in dramatic ways in the future, I’ll throw caution to the wind and duplicate stuff in a wholly separate pattern. But that happens less often.And I’m also not averse to adopting the ol
shame.css
technique now and again, especially when deadlines are looming. “Real artists ship” and all that.Guys, this is exactly why we have “Utility classes”.
To just add a margin, yeah. But utility/helper classes are not to extend other classes.
Yes, exactly. I should have been more specific that I meant that for exactly this example.
For a few minor tweaks that might be a one off, I use utility classes. If I feel like I am adding to many and it is a style that will be used more than once, make it a component modifier or a new component.
Each situation calls for different solutions. Knowing the right one to choose comes with experience and maintaining large projects for extended periods of time.
Nicolas Gallagher gave a great talk at CSSconf AU about this and how to be careful about your abstractions.
That was my exact first thought. Have some utility classes that have a standardized “spacing” amount for margin. Make it a variable in Sass/Less. I even use a half-spacing variable as well in the event the normal margin spacing variable is too large.
I’ve used the double class plenty of times, but if you ever end up with more than a few variants, it would often get painful to manage, especially if you ever want to edit the base.
Nowadays I might wrap the module in a div and style that div, but my favorite way to handle this is have:
(using less)
.module-styles(){
margin: awesome;
border: snazzy;
…
}
.module-foo{
.module-styles();
margin: ballin’;
}
.module-bar{
.module-styles();
margin: stellar;
}
your rendered CSS has redundant styles, but if your app is performance sensitive to that in 2014 I have no idea what you’re doing. by doing a style override in the “semantic” class definitions, you don’t have to reason about class specificity, just style order, which I find much simpler.
If you use BEM style (which I like to call GRM – group, role, modifier :)):
http://codepen.io/anon/pen/dqGyr
I came across this not too long ago, this is how I do it:
Is there a reason for double-declaring it like this:
Maybe a fallback for older browsers?
(got this from 24ways btw. If anyone’s interested, here you go: http://24ways.org/2012/a-harder-working-class/)
@Ralfff, the reason for that is because if in the css which was loaded on the page (could be a 3rd party css too) you’ll happen to have something like
.awesome-modules
or.user-feedback-module
then your styles ([class*=module]
) will get applied and you’ll have to redefine them. Though if you’ll follow naming convention which BEM (again I call it GRM :)) is using (http://bem.info/method/definitions/, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) where you divide css classes naming in 3 parts:.group--role__modifier
, for example (just from top of my head :)):.button, .button__primary, .button__primary--alternative, .button--icon, .button--icon__arrowUp
, it is quite unlikely that you’ll run in such a situation.I can guess that you might be confused – it is quite unlikely that I’ll run into a situation like that, and if it’ll happen, then I can adjust styles for that particular situation. That is very true, when you work on a project with 1-2 front end people. In my case I’m working on a project with ~30 developers and all of them could contribute to css, so it is very important for us to make have these conventions. But if I’ll leave the project and start working on my own, I’ll still be using GRM.
@everything, sorry for confusion, I guess it is common to use
--
for modifier and__
for element separators, and in the examples I reversed them :)And the reason for double-declaring is that I want the styles to apply only to elements which match
.module
+ elements where that module has a modifier[class*=module__]
will be applied to.module__books, .module__whatever, ...
.Ah, alright, makes sense. Seems like I’ve got some “rewriting my framework” to do.
I’m working mostly small to medium projects (2 devs) and am familiar with the BEM Method. My CSS is loosely based on that, but never got around using
__
and--
. Just the single dash works for me.Thanks Sergey.
Why not use an ID instead of a class for the body style?
IDs are evil. Nuff said.
IDs are too specific and hard(er) to overwrite. Classes do the exact same thing.
I totally dropped IDs in my CSS.
I still use them as Anchor in HTML and for jQuery.
If I have to use them for Styling (e.g. styling WP-Plugins or someone else’s code) I target them with the attribute-selector [id=”name”], so they have same specificity as a class.
“Nuff Said” is evil.
@Ralfff Clever method for avoiding a specificity nightmare with WP-Plugins by using the attribute-selector. Thanks for sharing!
Ha, no problem. But to be fair, I’m not that clever, Harry Roberts is:
http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/
Additional class! Been used to doing that for some time now.
…and lol @ shame.css haha
I would double up on classes, In Chris’s example the module is identical apart from the fact it has some extra margin bottom. It’s really an extension of the module object so in my opinion this is the way to go.
** … **
Third time lucky… I go for the class of alpha to keep the classname from being tied to the content, we never know if it might get reused for something entirely different in the future.
Double-up those classes, with a few naming conventions. Last year’s Smashing Mag article on the London Times’ site redesign prompted me to detail my approach and naming conventions.
Mostly with an extending class the BEM style
Sometimes over the body or HTML element class, e.g. when using WordPress, the body classes are inserted automatically for a particular page and when I’m just too lazy to add additional parameters to my server-side code.
When adding to the body or HTML Element, I create a mixin to make changes easier and less errors while using.
Mixins come with a price of additional bytes (which of course could not be critical). What do you think about my solution: https://css-tricks.com/design-pattern-breaks/#comment-1584654?
It depends on the purpose of module. If the module is something really self-contained that could be used on many pages and in many contexts, then it probably shouldn’t include any layout-type rules at all. Layout rules would be things like float, width, margin.
I would nest those portable modules inside of more generic layout modules which would be used for inter-module positioning. The HTML looks uglier and can border on div-itis, but the CSS is pretty clean and portable.
Congrats on being the first person making sense :) I’ll just add the example:
Currently I try to use double up classes without repeating parts of the name.. Something like
Thus I have to be more specific in the first place.
It’s far away from being perfect, but I like the readability…
I’d double up the classes but make sure those classes were modular. I’d use OOCSS to do this, adding a class of .mbm (margin-bottom: $medium)
I’m thinking about this many time. Now I use the BEM “way” using class=”module–solitary” and then in the .less file:
Vito
Most commonly use
body.contact .aside_module
. But I’m really not above doing inline styles, or even “ blocks, as there’s usually not enough bytes to weigh down my page and definitely not enough to justify an additional request. I always like making my stylesheets as universal as possible, so inline styles also lets me keep my stylesheets clean.I try to use
[data-*]
for Javascript only.I’ma read that shame.css article now. Sounds like that might be a good way to go.
I go with an additional class and the @extend in Sass. Feels right, simple and easy to update/remove.
I usually try to double up on classes, unless it’s a one off in which case I’ll either do a quick inline style or something a little more shameful like you demonstrated above. I come across a lot of cases in my work where margins need adjusted though so I’ve got some generic margin styles too. I usually have something like the following available:
Where m stands for “margin”, “p” for “padding”, “t” for “top, etc
.mt10 { margin-top:10px !important; } .m10 { margin:10px !important; }
The !important is only there because I work on a lot of other peoples code where the inheritance isn’t usually known off the top of my head, so these quick fix classes can save a lot of time on spacing issues.
I tend to double up classes
.module.module-books
. But recently my mark-up has starting looking a bit messy, I seem to need about 7 classes sometimes, which I’m not too into. This is mainly on.grid
elements though. Suppose the module could be a.grid
too though…Most of the time I use the “double up” classes. If it just needs 1 commonly used property (like a margin-bottom), I typically just create a helper class
.md
(for margin down) for it and add it to the html, if it’s an actual variation, I go for.module-variation
.I sometimes use body classes, but mostly just for javascript..
I usually use a modifier class. Never used inline style!
It depends, if I only need to add some margin bottom, I usually have a number of helper classes like .margin-bottom, .margin-bottom2x, .margin-top, etc.
Then I just add the modifier class.
Add an extra class! In the past I might have done a module extension, but lately I’ve been loving the Inuit style helpers. So instead of adding a
.module-books
I’ve been adding stuff like.push--bottom
(I’ve been using Inuit 5; https://github.com/csswizardry/inuit.css/blob/master/generic/_helper.scss)The key here to this New Circumstance™ is that the extra bottom margin will probably be a design pattern that happens again. This kind of abstraction while almost too simple has been really helpful for me.
I vote to use a new style! And if you’re using SASS, import the base style’s properties.
The double class is nice for organization, but I’m sticking to my first line.
I’d do something like this. If its just a change of color, padding etc..
I try to use the block element modifier methodology. In this instance, I’d probably have the base
.module
class and then for the additional margin I would do something like.module--dbl
(or something similar, depending on how much more margin and whether or not it is margin all around or just on a specific side (top, left, bottom, right).You could always name the module semantically:
“
Then in scss:
.user-biography { @extend %module; padding-bottom: $bigPadding; }
Hey Chris, great post!
What I usually do is doubling up classes, I personally call them “modifiers”. I think it stays very maintainable this way, and it plays nice with Twitter Bootstrap.
However I like the Data-attribute variations, they’re pretty neat. It’s pretty much like the AMCSS style, from GitHub: http://amcss.github.io/
Has anyone tried this style before?