Precision Level in CSS

When we’re using relative sizing in CSS, percentages or ems, how precise do we need to be with our fractions? Is there an optimum level?

If we have a font size of 18px (or anything, it’s relative after all) and we want some smaller text at two thirds of its size (12px) then we can express this as .6666666667em or 66.6666666667%. Here I’ve used 10 decimal places to give a very precise fraction but this feels like overkill to me. If I used just 2 decimal places, .67em or 66.67%, is this accurate enough to consistently calculate the desired pixel value. Or should I not worry? It’ll be near enough.

Looking at other developers’ CSS, mainly in tutorials, the general pattern seems to be to use between 4 and 6 decimal places. Looking back through my own code, my preference seems to be to use 6 but I couldn’t tell you why. I’d imagine I’ve just adopted someone else’s coding style. I definitely feel that going beyond 6 seems unnecessary but am not sure how little I can get away with.

Sass is able to perform calculations using fractions. Here’s an example:

$two_thirds: 2/3 * 1em;

.smaller {
  font-size: $two_thirds;

This resolves to .66667em, 5 decimal places. Is this a set precision or did Sass actually calculate it from the root size and decide what precision was needed for it to resolve to an integer? Hmm (rubs chin). I guess that most people let Sass handle this for them and don’t even look at the compiled CSS.

Learning the Right Things

With so much happening so fast knowing what new tech to learn next can be difficult. Where should you invest your time and energy? What if you spend ages learning the shiny new framework and it’s gone within 2 years?

There are a lot of trends and a lot of new-fangled things do come and go. How do you spot the ones that are going to stick around. It’s not easy – you kind of have to go with the flow, not swim against the tide (2 water based metaphors in one sentence, tut).

In front end development there are currently a few big JavaScript frameworks – Angular, React and Vue. It seems obvious to me that none of these are going away any time soon. Which do you choose? It really doesn’t matter. Learning one in depth, finding its powers and limitations, will help you learn the others or other future technologies.

If you’re really not sure where to turn I’d focus on core learning. In the front-end world, learn plain JavaScript. With ES2015 and newer versions than that emerging there’s still plenty to take on and perfect. That knowledge will always be useful.

I guess my short answer would be to favour the evergreen HTML, CSS and JavaScript over associated tech like Pug, Sass, TypeScript, etc. As the core technologies get better over time these current convenience technologies may one day not be needed.

One word answer. JavaScript. :)

What I Learned in 2016 (Part 2)

This is the second part of a three-part post about the new things that I picked up through the course of 2016.

I (finally) took some big steps in CSS this year, picking up some of the things I’d been putting off for a while.


I’d heard a lot of good things about Flexbox but having to support older browsers I’d never really bothered with it. Finally, this year, with support for older IE getting dropped I decided to dive in. It’s amazing. It can handle just about anything you would need for layouts. I’m sure there are now loads of great resources for learning it but the two I used were Wes Bos’s videos and Chris Coyier’s A Complete Guide to Flexbox.


The really big one for me this year was learning Sass. I know I’ve come to this very late. I was never that keen on the idea of adding another layer of complexity for my own convenience rather than for any actual user benefit. I still don’t think it’s really needed, it’s a just a nice convenience. That said, it does make writing CSS, particularly modular CSS a lot easier. Nesting, variables and mixins make it much easier to keep things consistent and manageable. CodeSchool’s Assembling Sass course was very good.


I’ve used Bootstrap on and off for a while but only recently did a course in it. It turns out that there are loads of little utility classes built in to handle all sorts of variations of the basic components. It’s well worth learning properly rather than just diving in and grabbing bits and pieces. Like with Sass I don’t think you really need a CSS framework but it can certainly speed things along nicely once you know your way around. Our friends at CodeSchool came up trumps again, Blasting Off with Bootstrap.

(Angular) Material

I didn’t go deep into this, just had a bit of a play. Angular Material is very nice and fairly easy to use but I came unstuck as I was trying to use parts of the framework within an existing page layout. It got messy pretty quickly. I think Material is a bit “all or nothing” – you use it fully or not at all.

And now for something completely different…

Being a front-end guy I rarely (never) touch the database world. Writing a request to an API is about as close as I get but recently I’ve poked about with a couple of things.


I liked the name. I got curious. I’ve done some stuff with SQL many moons ago so I was interested to see how a database could work without it. If you’re used to JavaScript objects and JSON it’s actually really nice to use. You just push and pull objects, query by properties, that kind of thing. I didn’t go deep into it but was very impressed. It’s very much sticking with JavaScript thinking. I think it’s got a bit of a bad reputation but I’m inclined to think that was some early teething trouble and mud sticking rather than a serious issue. Glass half full. I might be wrong.


Another play thing. Airtable lets you build databases and views, query, filter, sort, run formulae, rollups, lookups, etc. It also gives you forms, galleries where you can show your data in a card format, calendars and a whole lot more. It’s free for the basics and is lovely to use mainly down to some very good UI design. It also has an API for sharing the data with applications.


More in the next part…


Beautifying Native Form Elements

The various types of form inputs can look very different in different browsers. When it comes to styling them there’s only so much we can control. Here are all the form elements (at the time of writing) in one pen. Try viewing it in different browsers to see how they appear.

See the Pen All Form Elements.

It bugs me that the width and height of these elements seem inconsistent, as do text sizes, shading, etc. It makes it hard to create attractive forms and have everything align nicely.

A Style Base (CSS Reset) for Form Elements

It’s not too difficult to try to bring some control to the styling. Textareas, inputs which accept text and buttons are basically boxes and we can style them just like div elements. Other inputs can have special features but we can still change the basics – height, width, font-family, font-size, margin, padding, color, border, border-radius.

See the Pen All Form Elements – Style Base.

This light scattering of CSS seems to bring it under control and “flexbox” is a nice way of making everything align and behave responsively.

I don’t think there’s any hope for keygen but, to be honest, I’d never even heard of it before starting this so I’m not going to lose any sleep.

Please fork either of these pens and try out your own form styling.

Ordering CSS Properties A-Z

How do you order your CSS properties? There are a few different possible ways that spring to mind:

  1. Sort all properties alphabetically, listing them A-Z
  2. Group properties by their meanings, e.g. typographical properties first, then sizing, then shadows, then animations, etc.
  3. Random – just added as they occur to the developer.

I started off with them just logged randomly. Then, as I started writing longer style rules, I tried to bring similar items together. Gradually, over a long time, I’ve realised that the point of this grouping was to make the properties easier to find quickly. These days I always list them A-Z.

Going A-Z

At first it seems a bit obsessive-compulsive to order them in this way but it does make a real difference. I think things probably changed for me when I started working with JavaScript objects and JSON and the browser dev tools naturally ordered the object properties alphabetically. I got used to them being listed this way and learnt to scan these lists in a logical way. With CSS I’m convinced that in a list of 10 or more properties that being able to scan them in order and focus on the makes a huge difference when doing it every few minutes.

CSS Property Naming

Using A-Z ordering has made me realise how much of an opportunity has been missed with the property naming. For example, ‘border-top-right-radius’ would have been so much better as ‘border-radius-top-right’ as it would keep all of the ‘border-radius’ properties together in an alphabetical list. Also, some typographical properties being prefixed with ‘font-‘ and others ‘text-‘ means that they don’t get naturally grouped and ‘color’ seems stranded out on its own. Hopefully, some future incarnation of CSS will allow some aliasing of property names.

Code Editor Property Sorting

I use different code editors for different projects but my main day-to-day one is Visual Studio. The ReSharper tool, a paid extension, offers some code clean-up options, one of which is to order all CSS properties A-Z. This enables me to go back to code I worked on pre-A-Z and quickly kick it into shape in a couple of clicks. I don’t know of any other tools that do this but I’m sure they must exist, my guess would be as extensions/plugins rather than a core feature.