CSS Best Practices – Find Yours

I have been on a best-practice research rampage lately and wanted to take a few minutes to share some of the things that I have found in regards to CSS best practices. I will show some of the research I found and some of the common themes.

CSS Best practices

In my search for making good decisions, I thought it was important to try and find what other people are doing. I have talked about ‘being part of the conversation’ before and a good start to finding what I think is right is to look at what other people feel is right. That does NOT mean I need to follow what other people do, but it can give me the basis making my own informed decisions.

What are other organizations doing in terms of CSS Best Practices?

I found four online CSS style guides and CSS best practices that seemed like really good sources to begin forming my own thoughts.

Google’s Style Guide – – Because Google.

Code Guide by @mdo This person is one of the creators of Twitter Bootstrap and current Director of Design at GitHub.

Code Guide by Harry Roberts – the guy behind @csswizardry.

Air BnB

I am sure there are others out there, but these are all legit CSS style guides from prominent entities in the tech industry.

What do these example CSS best practices teach us?

One thing I was interested in was finding what is common among all of these style guides? If these widely regarded entities generally agree on something, it would seem appropriate to at least look at the similarities.

Here is a list of items that seem to be agreed on in at least ¾ of the style guides

  • Soft Tabs. They’re the only way to guarantee code renders the same in any environment. 3 of the 4 recommended 2 spaces. One recommended four.
  • When grouping selectors, keep individual selectors to a single line. 2/4 indicated that in some cases (only one selector and attribute), single line css could be used.
  •  
    
    /* Bad CSS */
    .selector, .selector-secondary, .selector[type=text] {
      padding:15px;
      margin:0px 0px 15px;
      background-color:rgba(0, 0, 0, 0.5);
      box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
    }
    
    /* Good CSS */
    .selector,
    .selector-secondary,
    .selector[type="text"] {
      padding: 15px;
      margin-bottom: 15px;
      background-color: rgba(0,0,0,.5);
      box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
    }
    

    .selector {padding: 15px;}

  • Include one space before the opening brace of declaration blocks for legibility.
  • /* Bad CSS */
    .selector{
      padding:15px;
    }
    
    /* Good CSS */
    .selector {
      padding:15px;
    }
    
  • Place closing braces of declaration blocks on a new line
  • Include one space after : for each declaration, but none before.
  • End all declarations with a semi-colon. The last declaration’s is optional, but your code is more error prone without it.
  • All class names should be lowercase-hyphen (although 2/4 recognizes/encourages BEM and OOCSS naming conventions. The other two do not mention them.) Google does not explicitly call this out for classes, but “All code has to be lowercase: This applies to HTML element names, attributes, attribute values (unless text/CDATA), CSS selectors, properties, and property values (with the exception of strings).”
  • Comments – use them. Everyone includes that comments are needed and that it should be done in a consistent manner, but they each have slightly different comment styles.
  • Javascript hooks. 3/4 Javascript hooks in selectors to separate presentation from functionality from document “.js-“. Google does not call out specific js-hooks, but does talk about “Separating structure from presentation from behavior is important for maintenance reasons.”
  • IDs. 2/4 say never use IDs in css. 1/4 say to avoid using them. 1/4 (Google)makes no comment.
  • 4/4 have some verbiage about avoiding qualifying selectors and avoiding specificity (als0 related to ID item) . The more specific a rule is, the more fragile it tends to be and more labor intensive for the browser. 3/4 seem to have a preference to classes in lieu of any dom elements and Google doesn’t really mention much about it.
  • They all talk about appropriate class naming. Trying to avoid presentational naming and more reflects the purpose of the element. Brief as possible, but long as necessary.

What am I supposed to do with these CSS best practices?

Well, use them. They don’t NEED to be a part of your CSS best practices, but use them to understand what other people are doing and to be intentional about how you and your organization writes CSS. Even among the linked style guides, they each have some sort of discussion about consistency and working together to make a choice or respecting the formatting of the environment you are working in.

Be Part of the Development conversation

Today, I am just going to talk about growing as a developer and working to be a part of the development conversation. I re-entered the development world approximately two years ago by attending Dev Bootcamp. I have grown in those two years, but also know I have a lot left to learn…. Well, I will never stop learning. And part of my goals is to constantly be growing my craft. To effectively do this, it is imperative to be continually looking at technologies to make sure that I am part of the conversation.

I am not talking about becoming an expert in everything, as that is not possible, but have enough understanding about a group of technologies, techniques, libraries, etc to be able to have a relatively informed discussion about them… even if it means knowing enough to admit that you just don’t know.  Know enough to be a part of the conversation. We are in a field that is continually changing (even if many of the ideologies remain relatively stable) and it is important to be able to evaluate some of the things that come into popularity.

Be a part of the development conversation

Be on the Internet to see the development conversation

Maybe the visual things are not your expertise (they sure aren’t mine), but take some time to look at the layouts of popular websites and how they look. Form some opinions about what is good and bad practice. In this case, it should not take much for a base level of thought, as most of us spend most of the day on the Internet. Similarly, we should be able to be a part of the conversation with our code.

Read blogs and consume online resources to understand the development conversation

I listen to a few podcasts every week (Developer Tea, Tech News Today) and once a week I catch up on what I already did not know via a search for the weeks most popular programming/technology things, usually through a curated multi-subreddit. Some things I don’t read in detail, but if it interests me enough I do. There are plenty of resources available. Consume them.

Use technologies to feel the development conversation

Often, I find myself working on mini side projects or experiments to further my knowledge or just to try something out. Those are great places to just dive right in and try to implement something that you have not used before, but might want to learn a bit about. For example, I have been trying to improve my lint game, so started researching JS linters, CSS linters and tidyhtml… in doing so, one of the things that have been on my list for quite a while are exploring task automation, which I have loosely known the fore runners in popularity to be Grunt and Gulp.

With a little bit of Googling and documentation, I had my little automation stack up and running. While I had a vague idea of what Gulp was and while I have never had to use it during my day job in the past, now I have a bit of experience with it.  When the topic of Gulp comes up, I will be able to at least have a sense of what they are talking about and some of the experiences I had while trying to use it. All it took was a little bit of extra effort on what I was going to be doing anyways.

Will I use it in the future? I think I will end up using this one, but there are plenty of libraries that I test with that never go past the “testing” phase.  Get out there… experiment.

Look, if you were looking to be in a career where everything stays the same, you might have chosen the wrong one. Things can change rapidly in the development world and while your employer may work to facilitate your growth, it ultimately is your craft and your career to grow. Help yourself and be a part of the conversation.

Helvetica Hate – Is it deserved?

It seems that a person can find no shortage of Helvetica hate and this is nothing new. Here, here, here and here are all some pretty scathing opinions of Helvetica usage, but doesn’t anything with some popularity also have it critics? I recently had my own issue with using Helvetica (Helvetica Neue, to be specific) and have come to the conclusion that there is no reason to hate Helvetica, or any font, but be aware of your use cases! Like anything, use helvetica where it’s appropriate. I will share my small experience and hopefully reinforce that there is no need for all the helvetica hate.

Why the Helvetica hate?

There are some very legitimate reasons to be hesitant about blindly using the font. For example, while the Helvetica font comes standard on Macs, it does NOT on Windows, so unless you are serving up the font via your server, you need to be a careful about your font stack. Also, be forewarned that this is NOT a free font.  You need to pay to use it. Finally, Helvetica was not created for the web and it can look really terrible in small font sizes. There are certainly other reasons, but those are the two that are most apparent to me and might be where some of the Helvetica hate is earned.

To get into the nitty gritty of what I found while using Helvetica Neue, I was implementing a page that had a bold version of the LinoType Helvetica Neue font. At smaller font sizes, on many Windows pages, the font appeared unacceptably blurry. Of course, on my machine and other Macintosh’s, it looked like its beautiful self.  Here is the difference:

screen capture of font difference mac and px showing why the Helvetica hate
Mac on left – Windows on right

As you can tell, using this Helvetica font had a HUGE difference in appearance, depending on what machine a user is looking the copy on. To be fair, I am also looking at this in BrowserStack, but it was reported to me elsewhere… this font looks bad when viewing it outside of my little Mac world!

I did experiment with this and it seems that the problem was not nearly as noticeable for larger font sizes and it did not seem to impact all of the letters. In this case, however, there just was such a tight space in the letter “s” for this smaller font size that using this version Helvetica Neue Bold was not an appropriate font choice.

What was my solution to stop the Helvetica hate?

I found a slightly different Helvetica Neue font to use and slightly changed the font-weight property. I changed this on the global css, so anywhere that this specific bold Helvetica Neue, it now uses a slightly different version of Helvetica. It still wasn’t perfect, but got me a little bit closer.

What I learned

  1. Maybe a bit more thought should be put into whether Helvetica should be used.
  2. There is no real reason to hate Helvetica, just use it in the right places at the right time.
  3. Windows does not have Helvetica natively installed. I did not know that!
  4. Some people really have Helvetica hate. Lots of emotion for a font. Almost creepy.

If I were to summarize who loves using Helvetica fonts according to Google search, it would be hipster, Mac fanboy, designers who have no awareness others. OK, there may be some cliché sort of half-truths to this, but I think that ultimately, all font choices have a time and place. It is up to you to understand the pros and cons of using Helvetica or any font. Don’t have Helvetica hate… embrace it when appropriate.