Blog

Remember the invention of the font element? Yeah, me neither. But what a day that must have been! Suddenly we could break out of the sad world of Times New Roman and start using those other three fonts and an array of magical "web safe" colours.

Things have certainly come a long way since then. Many new advancements have come along to help us create beautiful websites. Most notable is the humble Cascading Style Sheet. I think we all take this for granted. Just think: we used to have to do image rollovers with JavaScript, magic and curse words!

But as websites and pages have become more complex, CSS quickly buckles under the weight. It's still a thousand times better than tables for layout but it really hasn't changed all that much… selectors, properties and values.

This is where CSS preprocessors come in. They add a new layer of awesome on top of a syntax we already know and love. There are many CSS preprocessors out there, but I'm going to focus on th

As a front-end developer of course I'd heard about accessibility. I'd always followed best practices when creating web content that shouldn't have any problems being read by a screenreader. Like so many other developers in my position though I'd never actually tried a screenreader myself. It always seemed like a difficult thing to do, and I'd heard it was expensive. A few months ago I spent a week pretending to be blind for a week, using a screenreader to navigate websites, attempting to understand how a blind user will hear a site. I learned quite a few things that I didn't expect that have changed the way I write HTML. There's lots of rumours and misinformation about accessibility best practices. Here are some myths that are definitely not true:

There are several tactics for deciding where to put breakpoints in a responsive design. There is the rusty idea that they should be based on common screen sizes, but this doesn't scale well. There are no "common" screen sizes. Another popular tactic is to create a breakpoint wherever the layout breaks.