News

5 CSS3 killer tips and tricks

Are you ready to take your CSS to the next level? Read on to find out how to make the most of the king of styling

afterglow

Screen shot 2014-12-10 at 14.49.49

CENTRE YOURSELF

Web technology has never quite cracked the centring problem. You should just be able to say ‘centre this’ but it never quite seems to work like that in practice. Vertical centring is especially tricky.

If you’re not using abolute positioning – which can create overlapping text – you can use a CSS3 transform to centre content vertically. You still need a container div to provide an absolute reference, but you can use the transform to automatically adjust the vertical positioning to allow for the element height, like this:

001  div.container {
002  height: however many em you want;
003  position: relative }
004  div.container p {
005  margin: 0;            //Kills lingering offsets
006  position: absolute;
007  top: 50%;        //(Nearly) centre the element vertically
008  transform: translate(0, -50%); }    //Nudge it up by half its height
009

The big win here is animation. You can change the transform value dynamically to bounce the content inside the container, and still make sure it ends up floating in the middle. To centre vertically and horizontally, add/change the following:

001  left: 50%;
002  margin-right: -50%;
003  transform: translate(-50%, -50%);

MASTERING CSS SPECIFICITY

A feature that can drive designers insane is called specificity. Have you ever defined attributes then wondered why they have no effect? CSS has a strict priority model, and you need to know how it works or you may find that your statements won’t work like you want them to.

The outline rules are simple: inline CSS statements defined with <style> tags override id attributes, which override class attributes, which then override element/type attributes. Browser defaults lurk in the background confusing things further, which is why you should always use a normaliser or CSS reset script to set them up. If you redefine an attribute with the same specificity, only the last definition matters. Otherwise the higher specificity wins. If you add the !important tag to anything it overrides everything else. But it’s a bad idea to use this to fix problems without trying to fix existing priorities first. In fact you probably shouldn’t use it at all.

Specificity is actually defined by a numerical value. Styles are assigned 1000, ids get 100, classes get 10, and elements get 1. Multiple definitions add to the count, so for example div p {} has a specifity of 2, from two elements. You might think that piling on the attributes would lead to weird overrides, but CSS is smart enough not to allow this. A class attribute always overrides elements, and so on, for the others.

Specificity also explains why you should always include <!doctype HTML>. If you don’t, specificity can work in quirks mode and inheritance will do unexpected things you don’t want. As a guide, put generic declarations first for the most important elements, then get more and more specific with classes and ids. If you start specific and work outwards you’ll soon get confused and it will end up wasting time.

BECOME A KEYFRAME GENIUS

How much keyframe code do you need? Probably not as much as you think. According to the CSS animations spec, if you don’t include explicit from/0% and to/100% keyframe steps, the browser adds default values for them. So instead of

001 @keyframes do_the_thing {
002 from { transform: none; }
003 50% { transform: scale (2); }
004 to {transform: none; }
005 }

you can just put:

001 @keyframes do_the_thing {
002 50% { transform: scale (2); }
003 }

The from/to are added implicitly, and your CSS suddenly looks simpler. If the animation block includes an infinite tag, alternate is also implied, and the animation repeats and reverses automatically.
This trick works well with colour and transparency. You don’t necessarily want to recreate the famously hated <blink> tag, but you can still use one-line repeats to add more subtle colour/transparency/size pulsing. These can then draw more attention to important elements.

HSL NOT RGB

Most designers use the age-old RGB Hex tag system to specify colours. At first sight it looks like it makes sense. Specify red, green and blue separately, include opacity if you need it, and then you will have a simple colour specification system.
Which is fine until you try working with a colour wheel, and you need to specify complementary or contrasting hues with similar saturations. Then you will have to find an RGB to HSLa calculator (http://css-tricks.com/examples/HSLaExplorer) and have to do a lot of conversions. Only you don’t, because CSS3 supports HSLa colour specs, just like like this:

001 background-color: hsla(120, 50%, 50%, 1);

This works well in a preprocessor because you can define a base hue with a variable on one line and rotate an entire palette around it by specifying fixed offsets.

SIMPLIFY YOUR FONT STYLINGS

When you use @font-face, you may load different weights and styles of the same font, but tag them with font-weight:normal and font-style:normal such as:

001 @font-face {
002 font-family: ‘Italic name goes here’;,
003     src: url(‘URL-of-italic-font’)     format:(‘Usually truetype’);
004     font-weight:normal;
005     font-style:normal;
006     }

It’s pointless typing and more efficient to collect all the related fonts into a single family when you load them, but use ‘font-weight: bold’ for bold and ‘font-style: italic’ for italic. Then apply them to single lines of CSS:

001 body {font-family: "Name goes here"; }
002 elements_that_should_be_bold: { font-    weight: bold; }
003 elements_that_should_be_italic: {     font-style: italic; }
004     elements_that_should_be_both: {     font-style: italic; font-weight:bold }
005     }

This could cause problems in older browsers, but in 2014 it’s less of an issue than it used to be.

×