Hey all,

 

Does anyone have any tips for keeping your code clean, in particular CSS but not limited to just CSS. I always have the same issues I will start out with a nicely formatted Style sheet and as I add more styling before I know it the damn thing is a mess. I have been using LESS for a while now hoping that it will help by splitting the styling down into separate files, but rather than 1 messy file I have several.

 

Am I just a messy coder?

Have a read through this http://cssguidelin.es/ and follow it, it's pretty much a coding standard for CSS.

 

I use BEM heavilly and in my Sass I put each new BEM block inside it's own file, I have a heriarchy of folders in order of specificty it looks something like this

Sass--
      |
      |--Settings--/
      |
      |--Tools--/
      |
      |--Resets--/
      |
      |--Base--/
      |
      |--Objects--/
      |
      |--Components--/
      |
      |--Trumps

You could also look in smacss system, although the one I use above is called ITCSS thought up by CSS guru Harry Roberts, I recommend you read through his articles. http://csswizardry.com/

Thanks for that Robert,

 

Looks Like I have a lot of reading ahead

Have a read through this http://cssguidelin.es/ and follow it, it's pretty much a coding standard for CSS.

 

I use BEM heavilly and in my Sass I put each new BEM block inside it's own file, I have a heriarchy of folders in order of specificty it looks something like this

Sass--
      |
      |--Settings--/
      |
      |--Tools--/
      |
      |--Resets--/
      |
      |--Base--/
      |
      |--Objects--/
      |
      |--Components--/
      |
      |--Trumps

You could also look in smacss system, although the one I use above is called ITCSS thought up by CSS guru Harry Roberts, I recommend you read through his articles. http://csswizardry.com/

 

Literally the same as Robert in terms of the ITCSS structure. It saves potential headaches with specificity. I use the Suit CSS naming convention though, instead of BEM. I find it a bit more readable on larger codebases, but it's all preference.

 

The important thing is not to go too overboard making CSS abstract. It's easy to do at first, but it can cause some big headaches later on. Instead, try to work out which parts should be re-used, and bits that shouldn't. For example, there are times where sharing a class can cause problems, especially if you need to make an adjustment without it affecting the entire site. Sometimes you want that behaviour, other times you need a bit of CSS to form a standalone block that has one purpose only. Here's an example of both:

 

http://jsfiddle.net/xn8knL8m/

 

There are times though, when it's appropriate, and won't cause damage to use these utility classes. I use them occasionally for things like text alignment or border radius. It's just a matter of finding the right balance.

 

http://csswizardry.com/2015/03/can-css-be-too-modular/

 

In both cases you should be using classes, not ID's.

Been a bit of a debate recently on Twitter about using IDs in CSS. The problem is specificity. But sometimes it's nice to know an element is unique from your CSS. But I still don't think you should use the id selector to select that id. You can always use an attribute selector like

 [id="uniqueElement"] {
  /* Styles */
}

to show uniqueness without hurting specificity - an attribute selector has the same specificity as a class.

 

 

CSS is very easy to learn, but very, very difficult to master, especially in terms of maintainability and organisation, which is why there's so much debate around the subject, and somebody like Harry Roberts can make a fortune consulting large organisations and agencies on how to manage CSS.

Been a bit of a debate recently on Twitter about using IDs in CSS. The problem is specificity. But sometimes it's nice to know an element is unique from your CSS. But I still don't think you should use the id selector to select that id. You can always use an attribute selector like

 [id="uniqueElement"] {
  /* Styles */
}

to show uniqueness without hurting specificity - an attribute selector has the same specificity as a class.

 

 

You could always add an ID without styling it. That's what I do to with Javascript, but I don't apply CSS to that element, and always use a js- namespace to let any other developers know it's purely for JS and doesn't contain styling.

<div id="js-TweetButton"></div>

 

 

You could always add an ID without styling it. That's what I do to with Javascript, but I don't apply CSS to that element, and always use a js- namespace to let any other developers know it's purely for JS and doesn't contain styling.

<div id="js-TweetButton"></div>

 

I mean to reference an ID within CSS - sometimes (rarely) it is useful to indicate that an element is unique in your CSS.

 

I use IDs often in my JavaScript. I usually just namespace class based js-hooks because every ID should be a JS hook, unless it's the oddity mentioned above I may give it a css prefix.

 

Generally though the rule never use IDs in CSS is the most sensible thing to follow.

Edited August 10, 201511 yr by rbrtsmith

The important thing is not to go too overboard making CSS abstract.

That is so true. I've been struggling a lot with getting the balance right because I was under the misconception that the more abstract the CSS was the better.

As a result my mark up would end up with a crazy amount of class names for each element, making it almost imposible to keep track of which elements would be affected when changing a property.

It takes time and experience to get the balance between abstract and specific style rules right and I still struggle once in a while.

That is so true. I've been struggling a lot with getting the balance right because I was under the misconception that the more abstract the CSS was the better.

As a result my mark up would end up with a crazy amount of class names for each element, making it almost imposible to keep track of which elements would be affected when changing a property.

It takes time and experience to get the balance between abstract and specific style rules right and I still struggle once in a while.

 

That's where naming conventions like BEM http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ SMACSS https://smacss.com/ come in, Harry Roberts had written a huge amount of very, very in depth articles all about this subject. In short lots of classnames is not necessarily a bad thing, classnames do not affect semantics, SEO and the filesizes is gzipped to smithereens because they are so often repeated. - read his posts and you will understand, it took me some time to get my head around the concept.

If a pattern or abstraction is likely to be reused in any form then you should always use an abstract naming convention. The number of times I've made some say testimonial modules and then the client wants some other modules that look almost exactly the same - only they're not testimonials. This happens way more frequently that I'd like, and if you don't go in and refactor then the codebase will become increasingly confusing.

 

The way I found was to create low level abstractions and put them together like jigsaw puzzles, they are easier to name: I have a flag object http://rbrtsmith.com/2015/02/developing-the-flag-object/ which I use everywhere, take a look at my examples for just some of it's many uses,

I have grid classes, that can be combined with a matrix class that add vertical gutters to the grid, or any element that has vertical spacing,

I have an island that is an area of boxed off content

I have a bare-list that is an unordered list but with all styling stripped

inline list, same as bare list but inline,

a bunch of nav classes

the list goes on.. You can say combine the bare list with a matrix, or nest flags inside each li, make each li and island and so on.

 

Of course you will occasionally get something that doesn't quite fit the objects you created, something with very specific styling, but I still try and thing of an abstract name in case it does get re-used. but this doesn't work out in all cases so sometimes I am forced to name it based on it's content.

 

N.B. by abstract classname I mean it describes what it does in terms of architecture NOT what content it contains

 

And I will reiterate there's nothing wrong with lots of classnames, Harry Roberts mentioned above is regarded as one of the industry leading experts in managing CSS on large codebases and you will see he uses many abstract classes in his projects - but they are still highly organized and easy to understand.

Edited August 11, 201511 yr by rbrtsmith

I think he was referring to abstracted CSS, not class names. The difference being that you have a large set of classes that aren't tied to one particular component or object. They are seen as abstract because there's no easy way of knowing where they came from, or what the impact would be removing it from a stylesheet.

 

In your example, this would be like the flag object made up entirely of utility classes (like .display-table, .width-full). That's where it gets extremely difficult to make changes or refactor, because your classes could be used on a large amount of other elements. Instead it makes more sense to do like you have, and make the flag object it's own thing, then you can safely adapt the classes on that, and know it won't affect something like a header by accident. It's still re-usable, but it's also easier to maintain.

 

There's a fine line, and I do also use utility classes. You just have to be careful not to overuse them. With UI it's often suitable to break something out into it's own thing, if it's used often, or forms a common pattern across the site. If you look at Twitter, they use a card component everywhere. That's not something you would want build up entirely of loose classes.

 

A lot of early CSS frameworks used to come up with poor naming conventions and insisted on loosely coupled classes everywhere. Some of them still do it, and if you've ever had to re-factor one of those, it's a real nightmare. The result would be something like <div class="f-l col-12 col-primary ta-right">

I have a load of utility classes too, all wrapped in @if statements, otherwise the filesize gets much bigger. I also have to battle not to use them too often because at the time they are very, very useful but like you say can clutter the codebase if used too heavilly, finding where to draw the line can be quite difficult, I just try to be sensible with my useage.

 

For example my default styling on h1, h2 etc headers might be to have margin top and bottom, but some headers don't require margin top - so a helper would come in and fix it. flush--top is my helper for margin-top: 0 If all these headines with no margin tops had a border on the bottom for example, then it might be best to take away the flush--top class and create an abstraction to remove the margin and add the border.

 

This is what makes CSS hard, it's very grey unlike say JS where we can follow set rules that cover (almost) every situation.

I have a load of utility classes too, all wrapped in @if statements, otherwise the filesize gets much bigger. I also have to battle not to use them too often because at the time they are very, very useful but like you say can clutter the codebase if used too heavilly, finding where to draw the line can be quite difficult, I just try to be sensible with my useage.

 

For example my default styling on h1, h2 etc headers might be to have margin top and bottom, but some headers don't require margin top - so a helper would come in and fix it. flush--top is my helper for margin-top: 0 If all these headines with no margin tops had a border on the bottom for example, then it might be best to take away the flush--top class and create an abstraction to remove the margin and add the border.

 

This is what makes CSS hard, it's very grey unlike say JS where we can follow set rules that cover (almost) every situation.

 

I do the same with the margin thing you talked about. If it's a single class, I don't see any problem with it, it's just when people build entire bits of UI using utility, or loosely coupled classes. Sooner or later that's going to become a nightmare to refactor, and will often result in developers adding in things like helper classes to overwrite the behaviour, because it's easier and breaks less stuff.

 

I've seen people do this, and I've done it myself too. It's not fun.

@@Jack, you are spot on with your definition of abstract CSS and the problems it might cause. For me it's easy to loose overview on how many elements you will actually affect by deleting or adding rules to an "abstract " class.

 

@rbrtsmith: I'd like to thank you for the links and references you posted. I'm not used to working with BEM or any other naming conventions, though I am familiar with the concept and probably will have to adapt it as I have recently accepted to manage the front end development/ design in a team. This role is new to me so your links and recommendations are very helpful.

Edited August 12, 201511 yr by Nillervision

@@Jack, you are spot on with your definition of abstract CSS and the problems it might cause. For me it's easy to loose overview on how many elements you will actually affect by deleting or adding rules to an "abstract " class.

 

@rbrtsmith: I'd like to thank you for the links and references you posted. I'm not used to working with BEM or any other naming conventions, though I am familiar with the concept and probably will have to adapt it as I have recently accepted to manage the front end development/ design in a team. This role is new to me so your links and recommendations are very helpful.

 

You're more than welcome I highly recommend you try and read as much of csswizardry as you can, almost all my opinions regarding css are influenced by what I learnt from that site, Harry Roberts is an absolute genius when it comes to writing scalable CSS.