Web dev – Page 4 – David Ball's blog

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

Leaving Silktide

So Monday was my last day working for Silktide. I’ve been there 10 years, so the move to a new company will no doubt be a shock to me!

Especially as I’m going back to agency work. Something I’ve not done in about 4 years since Silktide decided to give up on web design.

In 10 years I’ve seen the company change from web agency, into a software company working only on our own products. I miss working with clients, working on short projects you can hand over to a happy client. My problem with working on software is that you’re detached from the customer (unless obviously you’re in a role that deals with them). So it’ll be nice to speak to smart people and help them achieve whatever it is they need a web agency for.

The best time since the move to software was when we turned Nibbler (the free website testing tool) into a social experience, where users could claim websites and add to an online portfolio. Some users really loved it, especially the leaderboard showing the top 10. It was nice to get involved in that community and get to know users. That’s the sort of thing that really gets me excited, seeing people enjoy using a product I’ve worked on, and getting useful feedback. Unfortunately though, the decision was made to strip Nibbler back to be much more simple where there’s zero interaction.

Working on a string of projects that will never see the light of day, and one which the threat of it being discontinued hanging over it like the sword of Damocles saps quite a lot of my morale, so I’ve not been enjoying my work for quite a while, which is why I’m glad to be moving back to a type of work which I think will make me happier.

I’ll miss all the guys there a lot though, they’re a great, very talented bunch. And the office banter is fantastic. Hopefully I’ll still see them often, as I’m only moving a couple of doors down.

So, two life changing things in the space of a month, getting married, and switching jobs! Both took a lot of preparation and stress, which is now mostly almost over.

Desk dinos & robots

I had a fairly substantial collection of robots and dinosaurs on my desk. I’ve brought them home. Not sure now what to do with them!

Leaving presents

I love the Lego games, and was so happy to get this as a leaving present from the Silktide gang. I was going to do something more productive in the time before I start my new job, but I’ve now constructed this. It’d be rude not to play at least just a little bit…

This is my other leaving present. Jess bought me a “SquattyPotty”. I had no idea what it was until I watched the hilarious video (here).

The science is sound, and Jess is clearly looking out for the health of my colon, but I had absolutely no idea how to react when given this as a present.

Nobody has ever given me a pooing aid before.

Out of software

Biggest irritation right now, I don’t have an Adobe Creative Cloud licence at home, so can’t use Photoshop or Flash, and I wanted to use this time for working on a fun side project. It costs more than I’m willing to pay for only working on hobby stuff, dammit!

What I will be doing though is learning Zurb’s Foundation. I’ve always been a fan of Bootstrap, and this looks similar, so shouldn’t take long to learn.

My opinions on using or not using Bootstrap

I found an article today titled “Strapless” by Aaron Gustafson (read it here) with some arguments for not using Bootstrap in your project. I use Bootstrap all the time, and I feel it saves a lot of time when starting a new project. Here’s my opinions on his points:

1. Bootstrap doesn’t solve your problems. Design is problem solving. The design decisions made by the creators/maintainers of Bootstrap solve their problems, not yours. You may share some of those problems—a need for responsive layouts, for example—but not others. You need a system that is tailored to solve your problems and only you (and your team) know what those problems are. Have you ever tried on an article of clothing that’s “one size fits all”? How well did it fit your body type? Unless you are absolutely average in all respects, probably not all that well. Solve your problems with your own Bootstrap-esque pattern library.

I actually agree with this point, but Bootstrap is a starting point, not a full solution. I like it because I can get something working really quickly, and can make the structure of a page, then refine it and change the look and feel later.

2. Bootstrap offers more than you’ll need. Bootstrap contains a lot of components and design patterns. It was created to address a wide array of project needs

Okay yeah, it is a bit bloated. It’s crammed full of stuff that you might never need – but actually that’s something I really like about it! If you suddenly need to add a carousel, there’s one built in. If you suddenly need to add a responsive wrapper for a Youtube video, it’s there. If you suddenly need to add a modal, it’s there. Same for lots of other really standard stuff.

Plus as long as you’re using the Bootstrap SCSS files and not the final exported version, you can pick and choose which sections you want, and comment-out the ones you don’t need. Here’s the _bootstrap.scss file for one of my projects where I’ve just uncommented the components that aren’t needed. These won’t be compiled into the final css, so there’s no bloat. But I can add them back in really easy if I need them.

If this isn’t how you include Bootstrap, you should (IMO anyway), and here’s an example project to get your started.

3. Differentiating yourself from you competition is harder. Bootstrap sites have a very common look to them.

Yeah but a Bootstrap site doesn’t have to look like a Bootstrap site! It’s a starting point, a framework. Sure if you keep the default theme, it will look like a Bootstrap site, but you can expand on that and add your own styles.

The major benefit I find is that it makes your markup standard, which means anyone who’s familiar with the Bootstrap classnames will save time when switching between projects and having to figure out how it all works!

Check out the rest of Aaron’s arguments here.

Working with modular “local” styles in ReactJS

At work we’re building our latest software product using ReactJS, and have chosen to do the frontend styles a little differently to what I’m used to, using “local styles” which is a way to modularise your CSS.

So instead of having all styles in one place and separated from the markup, this builds “components”, which is markup and styles all together. I have mixed feelings about this, the strongest that all the markup is kept in JavaScript, which I find horrible. Just horrible, to work with.

But I’m on the fence about local styles (if you’re not sure what I mean, here’s an article explaining the methodology).

Sometimes doing it that way is useful, but sometimes time consuming for not much benefit. So here’s a few opinions now I’ve had some time to work with it for a good few weeks.

Good things about local styles in ReactJS

You can copy a component from one project to another and it’ll have all the styles that’s associated with it. Not that I think this is something we’ll ever do, because every project will probably have a new design.
Forces you to put all styles associated with the component in the same place. This includes media queries, including print styles. Although this might get a bit cumbersome when styling other ways a component is displayed, like different coloured themeing, or when exported for PDF.
The classnames will be abstracted when the project is built, so they’ll be super small. Not bulky long BEM names like “header-wrapper__options-wrapper”. For example that’ll probably be compiled to “jk34a” or something even tinier, but still have the correct styles applied.
It frees up the global namespace. So you can use classnames like “options” or “list” without fear you’ll inherit styles from elsewhere.
You can use SCSS. Everyone should be using SCSS though, because it’s awesome.
CSS is inserted inline at the top of the document which saves the user having to download separate files. It’s messy, but reducing the number of files to download is great for speed.

Bad things about local styles in ReactJS

It takes longer to do stuff. This might be debatable, so I’ll say it takes ME longer to do stuff. Because the markup is split up into different files and distributed all over the place, it can be really difficult to chase down the bit you need (which might be a component in a component in a component), and work out quite how it works. Because the HTML is inside JavaScript, it won’t always be in the correct order either.
Difficult to bake Bootstrap into the project. I like to work by @extending parts of bootstrap into styles, to save having to write things over and over. It makes it much more DRY. But the way our project works (and this could just be down to our implementation) I can’t easily extend Bootstrap’s useful classes, instead having to recreate them, which is annoying and less DRY.
You have to import everything. Each component has a list of files it imports at the top, which is great to be specific, but also dead time-consuming when you have to do it over and over and over. Using relative paths too, which takes waaay too long to find where you need to import from the current file’s location. Also that makes me really worried for if we ever need to change something’s path.
You have to write “className=” instead of “class=”. This isn’t much of a problem but really irritates me and warps my brain. I’ve started writing “className” in other projects accidentally!
Some react components use global styles, and that ruins our attempt to keep it local. We use the react-bootstrap library which does everything with global styles. Which means we have to write :global in a local style. Seems to defeat the purpose!
Because the css is inserted inline, it’s difficult to find and look at the generated styles. SCSS is great, but sometimes you need to look at what it’s doing to make sure it’s not generating something incredibly long. At jQuery conf, @MDO said he accidentally generated an unnecessary 1000 lines of css just through making 1 change in the SCSS, and I want to make sure I don’t do the same!
Impossible to use descriptive BEM notation because JavaScript doesn’t like the “–“, although this could just be our implementation. This means I find the markup slightly less clear to understand. Although some people might like it.
I need the help of the programmers much more. Because the components are all created in JavaScript, it can be difficult to do something really simple like just add a class where I need to without asking who coded it, and how it works.
The CSS isn’t cascading, or a sheet, so we should rename it from css to just “s”. So because of the way local styles work, they’re all individual blocks of styles, so don’t cascade. And because it’s all inserted inline, it’s not a sheet either.

One of my biggest struggles is keeping it DRY, even though everything is modularised. You can do this by @extending common shared styles. For example we have 2 separate components that need a circular green icon with an arrow. What I’d normally do in this case is create base styles for it, and extend it in both components. Local styles still allows us to do this, but it defeats one of the main purposes, which is to keep all styles for a component contained within.

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.

Adding to Bootstrap’s breakpoints variables

In Bootstrap projects you can use the default breakpoint sizes as variables, like this:

/* ================================================
Screen sizes
=================================================== */

$screen-sm-min: 768px;
$screen-md-min: 992px;
$screen-lg-min: 1200px;

$screen-sm-max: 767px;
$screen-md-max: 991px;
$screen-lg-max: 1199px;

…which is useful when writing media queries, like this:

@media (min-width: $screen-sm-min) {
    .upload-item {
        font-size:1.2em;
    }
}

@media (min-width: $screen-md-min) {
    .upload-item {
        font-size:1.5em;
    }
}

I could have chosen any sizes as breakpoints really, but it made sense to match them to the default grid sizes in Bootstrap (col-sm-6, col-md-6 etc).

Although sometimes I find the size range before $screen-sm-min a bit too large, especially when you think about the range of phone sizes. So I add an additional:

screen-s-min: 500px;
screen-s-max:499px;

SCSS boilerplate with Bootstrap baked in

I know starter projects using Bootstrap are common enough, but I’ve added to the plethora this week by adding my own to Github in a public repo.

What is it?

It’s a dead basic project using Bootstrap which compiles all of Bootstrap’s SCSS plus your own SCSS styles into a single CSS file. It’s component-based, so useful features like buttons, forms, etc are in separate scss files for ease of finding. Because it’s all compiled as one big project using SCSS, you can @extend Bootstrap’s classes so you don’t have to add all their zillions of classes all over the place, cluttering your markup.

All the files are in the hierarchy I wrote about in this article.

Why?

I’ve been working on a few projects recently that all needed a sensible starting place. It saves all that setup time I guess. It’s not like this is amazing or anything. It’s just how I’ve started every project lately so thought it was handy.

Limitations

Bootstrap are bringing out new versions all the time. Therefore it won’t be long before my repo is out of date. I’ll maintain it for as long as it’s useful to me, but if you’re going to use it, check for a new version of Bootstrap first and potentially copy the files across. I always leave the Bootstrap folder untouched in every project, extending or overwriting the classes if I need to change them, in case the originals need to change.

See the GitHub repo 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!