Tag: CSS

Neat ways to write BEM without being verbose

BEM + SASS

I love naming classes using BEM, which is a good way to indicate what classes represent (and where to find them in your project), without forcing it into a hierarchy that will cause problems later if you have to change the markup.

Problem is, it can get a bit verbose though.  Especially if you’re being super specific with your names. Writing CSS selectors for long class names is repetitive and annoying. So here’s 2 tips for making it easier using SCSS: Continue reading Neat ways to write BEM without being verbose

Keeping CSS classes together by usage

I’ve written before about keeping your CSS grouped by component, so that styles for a specific part are not distributed wildly around the project and difficult to find.

This is normally done because of media queries. A common thing people might do is to split the stylesheet into 3 chunks. Styles for mobile, styles for tablet, and styles for desktop (or more, depending on how many breakpoints you decide to have). But I prefer to put all styles for a specific component in one place, to save you chasing these around. Even if it does mean having loads of media query declarations. But that doesn’t matter! (I use variables for these anyway). Continue reading Keeping CSS classes together by usage

Don’t scrimp on classes if it means making convoluted CSS

I’ve been reading Harry Robert’s chapter in the “New perspectives on Web Design” book today (he even signed it for me, which was hilarious because apparently nobody had ever asked him that before!), and there’s a great bit talking about reducing the amount of DIVs to create clean markup, and how it’s just cutting off your nose to spite your face.

The pursuit of clean markup and semantic classes and all that came with it was well-intentioned but helped no one. It led to verbose, difficult to maintain, tangled style sheets. The price of omitting a few classes was having to write giant, convoluted selectors to target these orphaned, unnamed DOM elements. As the saying goes, we robbed Peter to pay Paul. We were writing clean markup at the cost of writing verbose, messy and convoluted CSS. We just moved the mess somewhere else.

  • Harry Roberts, New perspectives on Web Design

Avoiding location-based inheritance in CSS

I had a thought today on a personal HTML/CSS project about how to style a light button in a dark container, and how to style a dark button in a light container.

Should I use CSS inheritance to make the button the appropriate colour in each area? That makes sense right? It means I can write HTML not really caring about the styles, and let the CSS do the rest.

But then I worried about what happens if I use the button elsewhere, out of the container. If the coloured container provides the styles, I’ll need at least some base styles on the button. And which one should be the default? Light on dark, or dark on light?

Let’s say light container is the default, so the button by default is dark.

What about then when we want the button on a different coloured background, maybe a red container inside the dark container. We’d have to override the button’s default styles to make it dark on light, then override these again to show as [I dunno, yellow?] on the red background.

I know the “C” in CSS stands for cascade, but this can get out of hand!

There’s a good article about this I found today, which has this great line that I need to repeat over and over.

…your styles will be more flexible and less prone to breaking if you avoid relying on location inheritance.

Read the rest of the article here. It takes you through a good use case of how inheritance can cause problems. It also talks about how “multiple inheritance” can also get out of hand, and solves it with SASS extends, although I prefer more of a BEM approach, but the idea of being very specific about your styles is the same.

A vertical-align mixin that changed my life

Aligning something vertically has always been a PITA in CSS, and in recent years I’ve used display:table-cell to achieve this, which is added to the parent object of the one you want to vertically align.

This method works ok mostly, but display:table-cell isn’t what you always want on an element, leading you to have to create another element which wraps your vertically-aligned one (and I don’t like having too many elements!).

I recently found these 3 lines of css, which work really well at aligning an element vertically:

.element {
  position: relative;
  top: 50%;
  transform: translateY(-50%);
}

And stick these into a mixin, and you can import them into any style, like this:

@mixin vertical-align {
  position: relative;
  top: 50%;
  -webkit-transform: translateY(-50%);
  -ms-transform: translateY(-50%);
  transform: translateY(-50%);
}

.element p {
  @include vertical-align;
}

I’ll leave this here for when I need to copy & paste this into my next project!

Credit: I found this snippet here.

My favourite CSS comment style

I wish I could say this post was an intellectual discussion on the the importance of creating guidance through your code. But it isn’t.

I’m posting it because I want a handy place to keep my favourite CSS comment style. Which is this:

/* ====================================================
CSS comment
======================================================= */

I like to use this as a separator for each section because it’s nice and clear.

If you’re interested how I like to split up my CSS, I’ve written an article about that (click here).

I use BEM – A good clear naming convention

It’s not the most exciting skill in the world, but I like to think I’m pretty good at naming things. That’s because it’s so damned important to be clear and concise, or you risk confusion.

That’s why I use BEM.

Bem is great, although can get a bit wordy with massive long class names. But I try not to let it. It’s great because you can declare a reusable component, for example:

search {}

search__input {}

search__btn {}

search__label {}

And then use a standard BEM modifier (“–“) to make alternate versions, just by adding a new class:

search–vertical {}

…inheriting most of the styles but adding some overrides.

The best thing about BEM though is the specificness, and you’re absolutely certain the class hasn’t been used elsewhere. For example if I found a class like “full-width” I wouldn’t dare touch the css for it, in case it was inherited by something else tucked away on the website. But I know that “search–full-width” It’s pretty clear what that class is for and where it’ll be used. It’s just clear naming really.

My CSS layout – group by component, not by screen-size

I read an interview with Eric A Meyer today, who is supposedly the “Godfather of CSS wisdom”, and one thing that stuck out for me is how he structures his CSS files. He says:

I usually organize my CSS by section of the layout, so the header styles are all together at the top of the CSS, the page-content styles are in the middle, and the footer styles come at the end. Then I do my media-query blocks, with the same internal organization.

No, no, no Eric! The first bits seem fine, but don’t group your CSS by screen sizes into different media queries! I have to say I’m a little bit confused why anyone would do it that way, splitting your entire stylesheet into sections wrapped in different media queries. It’s like building the website multiple times over.

I tried to explain this in an older article (see it here), but wasn’t too clear so I’ll have a go at explaining the reasons why I think you should avoid grouping by screen size, and what I do instead, which I actually think is much easier (although obviously do whatever suits you and your project!).

1) Working on the file – and tracking down the distant sections you need

Okay so I’m assuming you’ve got a mobile-first website (and if you’re not using mobile first, you should be!). And if you’re doing it Eric’s way you’ve got at least 2 separate chunks of CSS, styles for mobile (including default styles), and the styles for desktop separately. Between them you might also have media queries for in-between, tablets or small browser windows on desktop. So if you’re using Eric’s method, to change any component on the page, say… the footer, you’d have to skip between distant sections of the same document to add styles.

2) What if you want to target a different screen size?

Okay so you have the very specific styles for mobile, tablet, small and large desktop screens. But what about this, a new device comes out which your client/boss tells you is a big deal. The website HAS to look awesome at this particular size and aspect ratio. Not just acceptable – awesome.

So Eric’s method, he has to create an entire new media query section, slipping it in between the others. What does this do to your mobile first approach? Well you’ll have to leech some of the styles from the larger media query perhaps, and maybe add a few more very specific ones for that size range. Seems like your nice flow of mobile first to larger has just got a bit more bumpy.

My flow – 1) Generic to specific

The method I use was taught my CSS Wizardry’s Harry Roberts in a workshop in London a few years ago. I’ve changed it slightly to suit me, but I think the flow is pretty solid.

He starts with a triangle, because that’s a good way to imagine the best way to write CSS, from the most generic to the most specific, ending with some “trumps” which is essentially allowing for some hacks right at the end.

harry roberts css flow

His triangle needs a bit of explaining – Settings & tools are where you’d define variables and include CSS mixins, maybe your frameworks. Objects and components are things which are reusable throughout the website. Harry explains the rest here, go read that because it’s excellent, and it allowed me to come up with what works for me…

My flow – 2) Files I include

  • Framework
    • For me this is Bootstrap
  • Variables
  • Mixins
  • Animations
  • Global styles (fonts etc)
  • Components
    • Header
    • Footer
    • Menus
    • etc
  • Specific layouts
    • Home
    • About
    • etc

This order allows you to build reusable components, then if you need a specific alternative for a certain page, you can make a slightly more specific version without having to create a brand new version.

An example of this is all buttons (I like to use the class .btn) might be the same size colour and padding, except on the login page where you can make them all a bit bigger easily using a bit more specificity.

.login-layout .btn {}

Including separate SCSS files

Each of the above is a separate SCSS file, included into the styles.scss, which is where I’ll have global styles for typeface, font sizes, all the basic stuff for the entire site. This works for every project I’ve done recently.

I compile all of these into a single css file, including the entirity of Bootstrap which I do so I can extend some of its classes and use its mixins. It’s all included in the order above, with the most generic items able to be extended further down the line.

One cool thing about SCSS is that if you prefix the filename with an underscore, it doesn’t try and compile the file separately, it know it’s an include file only.

But what about the media queries?

One thing I didn’t mention in the list above is the media queries. That’s because I don’t have a specific place for those. They’re intermingled around the entire thing. If you’re not used to that, you might think it madness. But honestly it feels a lot more organised than the alternative. If you want to work on the _header.scss, all the header styles are right there in one place, and you don’t have to go chasing them down.

I use BEM too, but I’ll explain that in another article!

All media queries in one place? That’ll be confusing surely?

image

I downloaded HTML5 Boilerplate today to use on a new project. In the CSS it has a section titled “Media queries”, I assume encouraging developers to put all their media queries here.

All media queries in one place?! I think it makes sense to put the media queries as close as possible to the rest of the styles. I don’t want to go hunting somewhere else for a media query about the navbar, keep it next to the styles for the navbar, surely? That way you’re keeping all relevant styles close together.