Tags: 24ways



Friday, January 5th, 2018

Improving the Accessibility of 24 ways | CSS-Tricks

Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.

Monday, January 1st, 2018

All That Glisters ◆ 24 ways

I thought this post from Drew was a great way to wrap up another excellent crop from 24 Ways.

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them.

Chris likes it too.

Thursday, December 14th, 2017

Why Design Systems Fail ◆ 24 ways

Great advice from Una on getting buy-in and ensuring the long-term success of a design system.

Friday, December 1st, 2017

Cascading Web Design with Feature Queries ◆ 24 ways

24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using @supports:

Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.

Wednesday, June 7th, 2017

A day without Javascript

Charlie conducts an experiment by living without JavaScript for a day.

So how was it? Well, with just a few minutes of sans-javascript life under my belt, my first impression was “Holy shit, things are fast without javascript”. There’s no ads. There’s no video loading at random times. There’s no sudden interrupts by “DO YOU WANT TO FUCKING SUBSCRIBE?” modals.

As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!

This has made me appreciate the number of large sites that make the effort to build robust sites that work for everybody. But even on those sites that are progressively enhanced, it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.

Monday, December 19th, 2016

Front-End Developers Are Information Architects Too ◆ 24 ways

Some great thoughts here from Francis on how crafting solid HTML is information architecture.

Friday, December 9th, 2016

Get the Balance Right: Responsive Display Text ◆ 24 ways

Some really great CSS tips from Rich on sizing display text for multiple viewports.

Thursday, December 8th, 2016

What the Heck Is Inclusive Design? ◆ 24 ways

I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.

He also includes some tips which read like design principles to me:

  • Involve code early
  • Respect conventions
  • Don’t be exact
  • Enforce simplicity

Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.

Sunday, December 4th, 2016

Fractal ways

24 Ways is back! That’s how we web nerds know that the Christmas season is here. It kicked off this year with a most excellent bit of hardware hacking from Seb: Internet of Stranger Things.

The site is looking lovely as always. There’s also a component library to to accompany it: Bits, the front-end component library for 24 ways. Nice work, courtesy of Paul. (I particularly like the comment component example).

The component library is built with Fractal, the magnificent tool that Mark has open-sourced. We’ve been using at Clearleft for a while now, but we haven’t had a chance to make any of the component libraries public so it’s really great to be able to point to the 24 Ways example. The code is all on Github too.

There’s a really good buzz around Fractal right now. Lots of people in the design systems Slack channel are talking about it. There’s also a dedicated Fractal Slack channel for people getting into the nitty-gritty of using the tool.

If you’re currently wrestling with the challenges of putting a front-end component library together, be sure to give Fractal a whirl.

Thursday, December 10th, 2015

Putting My Patterns through Their Paces ◆ 24 ways

Ethan demonstrates progressive enhancement at the pattern level using flexbox.

I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.


Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Tuesday, December 9th, 2014

Responsive Enhancement

This article first appeared in 24 Ways, the online advent calendar for geeks.

24 Ways has been going strong for ten years. That’s an aeon in internet timescales. Just think of all the changes we’ve seen in that time: the rise of Ajax, the explosion of mobile devices, the unrecognisably-changed landscape of front-end tooling.

Tools and technologies come and go, but one thing has remained constant for me over the past decade: progressive enhancement.

Progressive enhancement isn’t a technology. It’s more like a way of thinking. Instead of thinking about the specifics of how a finished website might look, progressive enhancement encourages you to think about the fundamental meaning of what the website is providing. So instead of thinking of a website in terms of its ideal state in a modern browser on a nice widescreen device, progressive enhancement allows you to think about the core functionality in a more abstract way.

Once you’ve figured out what the core functionality is—adding an item to a shopping cart, or posting a message, or sharing a photo—then you can enable that functionality in the simplest possible way. That usually means starting with good old-fashioned HTML. Links and forms are often all you need. Then, once you’ve got the core functionality working in a basic way, you can start to enhance to make a progressively better experience for more modern browsers.

The advantage of working this way isn’t just that your site will work in older browsers (albeit in a rudimentary way). It also ensures that if anything goes wrong in a modern browser, that it won’t be catastrophic.

There’s a common misconception that progressive enhancement means that you’ll spend your time dealing with older browsers, but in fact the opposite is true. Putting the basic functionality into place doesn’t take very long at all. And once you’ve done that, you’re free to spend all your time experimenting with the latest and greatest browser technologies, secure in the knowledge that even if they aren’t universally supported yet, that’s okay: you’ve already got your fallback in place.

The key to thinking about web development this way is realising that there isn’t one final interface—there could be many, slightly different interfaces depending on the properties and capabilities of any particular user agent at any particular moment. And that’s okay. Websites do not need to look the same in every browser.

Once you truly accept that, it’s an immensely liberating idea. Instead of spending your time trying to make websites look the same in wildly varying browsers, you can spend your time making sure that the core functionality of what you’re building works everywhere, while providing the best possible experience for more capable browsers.

Allow me to demonstrate with a simple example: navigation.

Step One: Core Functionality

Let’s say we’ve got a straightforward website about the twelve days of Christmas, with a page for each day. The core functionality is pretty clear:

  1. To read about any particular day, and
  2. To browse from day to day.

The first use-case is easily satisfied by marking up the text with headings, paragraphs, and all the usual structural HTML elements. The second use-case is satisfied by providing a list of good ol’ hyperlinks.

Now where’s the best place to position this navigation list? Personally, I’m a big fan of the jump-to-footer pattern. This puts the content first and the navigation second. At the top of the page there’s a link with an href attribute pointing to the fragment identifier for the navigation.

  <main role="main" id="top">
    <a href="#menu" class="control">Menu</a>
  <nav role="navigation" id="menu">
    <a href="#top" class="control">Dismiss</a>

See the footer-anchor pattern in action.

Because it’s nothing more than a hyperlink, this works in just about every browser since the dawn of the web. Following hyperlinks is what web browsers were made to do (hence the name).

Step Two: Layout as an Enhancement

The footer-anchor pattern a particularly neat solution on small-screen devices, like mobile phones. Once more screen real-estate is available, I can use the magic of CSS to reposition the navigation above the content. I could use position: absolute, flexbox, or in this case, display: table.

@media all and (min-width: 35em) {
  .control {
    display: none;
  body {
    display: table;
  [role="navigation"] {
    display: table-caption;
    columns: 6 15em;

See the wide-screen styles in action

Step Three: Enhance!

Right. At this point I’m providing core functionality to everyone, and I’ve got nice responsive styles for wider screens. I could stop here, but the real advantage of progressive enhancement is that I don’t have to. From here on, I can go crazy adding all sorts of fancy enhancements for modern browsers, without having to worry about providing a fallback for older browsers—the fallback is already in place.

What I’d really like is to provide a swish off-canvas pattern for small-screen devices. Here’s my plan:

  1. Position the navigation under the main content.
  2. Listen out for the .control links being activated and intercept that action.
  3. When those links are activated, toggle a class of .active on the body.
  4. If the .active class exists, slide the content out to reveal the navigation.

Here’s the CSS for positioning the content and navigation:

@media all and (max-width: 35em) {
  [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .active [role="main"] {
    transform: translateX(-75%);

In my JavaScript, I’m going to listen out for any clicks on the .control links and toggle the .active class on the body accordingly:

(function (win, doc) {
  'use strict';
  var linkclass = 'control',
    activeclass = 'active',
    toggleClassName = function (element, toggleClass) {
      var reg = new RegExp('(\s|^)' + toggleClass + '(\s|$)');
      if (!element.className.match(reg)) {
        element.className += ' ' + toggleClass;
      } else {
        element.className = element.className.replace(reg, '');
    navListener = function (ev) {
      ev = ev || win.event;
      var target = ev.target || ev.srcElement;
      if (target.className.indexOf(linkclass) !== -1) {
        toggleClassName(doc.body, activeclass);
  doc.addEventListener('click', navListener, false);
}(this, this.document));

I’m all set, right? Not so fast!

Cutting the Mustard

I’ve made the assumption that addEventListener will be available in my JavaScript. That isn’t a safe assumption. That’s because JavaScript—unlike HTML or CSS—isn’t fault-tolerant. If you use an HTML element or attribute that a browser doesn’t understand, or you use a CSS selector, property or value that a browser doesn’t understand, it’s no big deal. The browser will just ignore what it doesn’t understand: it won’t throw an error, and it won’t stop parsing the file.

JavaScript is different. If you make an error in your JavaScript, or use a JavaScript method or property that a browser doesn’t recognise, that browser will throw an error, and it will stop parsing the file. That’s why it’s important to test for features before using them in JavaScript. That’s also why it isn’t safe to rely on JavaScript for core functionality.

In my case, I need to test for the existence of addEventListener:

(function (win, doc) {
  if (!win.addEventListener) {
}(this, this.document));

The good folk over at the BBC call this kind of feature-test cutting the mustard. If a browser passes the test, it cuts the mustard, and so it gets the enhancements. If a browser doesn’t cut the mustard, it doesn’t get the enhancements. And that’s fine because, remember, websites don’t need to look the same in every browser.

I want to make sure that my off-canvas styles are only going to apply to mustard-cutting browsers. I’m going to use JavaScript add a class of .cutsthemustard to the document:

(function (win, doc) {
  if (!win.addEventListener) {
  var enhanceclass = 'cutsthemustard';
  doc.documentElement.className += ' ' + enhanceclass;
}(this, this.document));

Now I can use the existence of that class name to adjust my CSS:

@media all and (max-width: 35em) {
  .cutsthemustard [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  .cutsthemustard [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .cutsthemustard .active [role="main"] {
    transform: translateX(-75%);

See the enhanced mustard-cutting off-canvas navigation. Remember, this only applies to small screen screens so you might have to squish your browser window.

Enhance All The Things!

This was a relatively simple example, but it illustrates the thinking behind progressive enhancement: once you’re providing the core functionality to everyone, you’re free to go crazy with all the latest enhancements for modern browsers.

Progressive enhancement doesn’t mean you have to provide all the same functionality to everyone—quite the opposite. That’s why it’s so key to figure out early on what the core functionality is, and make sure that it can be provided with the most basic technology. But from that point on, you’re free to add many more features that aren’t mission-critical. You should be rewarding more capable browsers by giving them more of those features, such as animation in CSS, geolocation in JavaScript, and new input types in HTML.

Like I said, progressive enhancement isn’t a technology. It’s a way of thinking. Once you start thinking this way, you’ll be prepared for whatever the next ten years throws at us.

Responsive Enhancement ◆ 24 ways

My contribution to this year’s edition of the web’s best advent calendar.

Monday, December 8th, 2014

Websites of Christmas Past, Present and Future ◆ 24 ways

A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.

Friday, December 2nd, 2011

Clean conditional loading

It’s December. That means it’s time for the geek advent calendars to get revved up again:

For every day until Christmas Eve, you can find a tasty geek treat on each of those sites.

Today’s offering on 24 Ways is a little something I wrote called Conditional Loading for Responsive Designs. It expands on the technique I’m using on Huffduffer to conditionally load inessential content into a sidebar with Ajax where the layout is wide enough to accommodate it:

if (document.documentElement.clientWidth > 640) {
// Use Ajax to retrieve content here.

In that example, the Ajax only kicks in if the viewport is wider than 640 pixels. Assuming I’ve got a media query that also kicks in at 640 pixels, everything is hunky-dory.

But …it doesn’t feel very to have that 640 pixel number repeated in two places: once in the CSS and again in the JavaScript. It feels particularly icky if I’m using ems for my media query breakpoints (as I often do) while using pixels in JavaScript.

At my recent responsive enhancement workshop in Düsseldorf, Andreas Nebiker pointed out an elegant solution: instead of testing the width of the viewport in JavaScript, why not check for a style change that would have been executed within a media query instead?

So, say for example I’ve got some CSS like this:

@media all and (min-width: 640px) {
    [role="complementary"] {
        width: 30%;
        float: right;

Then in my JavaScript I could test to see if that element has the wide-screen layout or not:

var sidebar = document.querySelector('[role="complementary"]'),
floating = window.getComputedStyle(sidebar,null).getPropertyValue('float');
if (floating == 'right') {
// Use Ajax to retrieve content here.

Or something like that. The breakpoint is only ever specified once so I ever change it from 640 pixels to something else (like 40 ems) then I only have to make that change in one place. Feel free to grab the example and play around with it.

By the way, you’ll notice that in the original 24 Ways article and also in this updated example, I’m only testing the layout on page load, not on page resize. It would be fairly easy to add in an onResize test as well, but I’m increasingly coming to the conclusion that—apart from the legitimate case of orientation change on tablets—the only people resizing their browser windows after the page loads are web designers testing responsive designs. Still, it would be nice to get some more data to test that hypothesis.

Conditional Loading for Responsive Designs

This article first appeared in 24 Ways, the online advent calendar for geeks.

On the eighteenth day of last year’s 24 ways, Paul Hammond wrote a great article called Speed Up Your Site with Delayed Content. He outlined a technique for loading some content — like profile avatars — after the initial page load. This gives you a nice performance boost.

There’s another situation where this kind of delayed loading could be really handy: mobile-first responsive design.

Responsive design combines three techniques:

  • a fluid grid
  • flexible images
  • media queries

At first, responsive design was applied to existing desktop-centric websites to allow the layout to adapt to smaller screen sizes. But more recently it has been combined with another innovative approach called mobile first.

Rather then starting with the big, bloated desktop site and then scaling down for smaller devices, it makes more sense to start with the constraints of the small screen and then scale up for larger viewports. Using this approach, your layout grid, your large images and your media queries are applied on top of the pre-existing small-screen design. It’s taking progressive enhancement to the next level.

One of the great advantages of the mobile-first approach is that it forces you to really focus on the core content of your page. It might be more accurate to think of this as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essential.

But what happens when you apply your media queries for larger viewports and you do have sidebars and multiple columns? Well, you can load in that nice-to-have content using the same kind of Ajax functionality that Paul described in his article last year. The difference is that you first run a quick test to see if the viewport is wide enough to accommodate the subsidiary content. This is conditional delayed loading.

Consider this situation: I’ve published an article about cats and I’d like to include relevant cat-related news items in the sidebar …but only if there’s enough room on the screen for a sidebar.

I’m going to use Google’s News API to return the search results. This is the ideal time to use delayed loading: I don’t want a third-party service slowing down the rendering of my page so I’m going to fire off the request after my document has loaded.

Here’s an example of the kind of Ajax function that I would write:

var searchNews = function(searchterm) {
    var elem = document.createElement('script');
    elem.src = 'http://ajax.googleapis.com/ajax/services/search/news?v=1.0&q='+searchterm+'&callback=displayNews';

I’ve provided a callback function called displayNews that takes the JSON result of that Ajax request and adds it an element on the page with the ID newsresults:

var displayNews = function(news) {
    var html = '',
    items = news.responseData.results,
    total = items.length;
    if (total>0) {
        for (var i=0; i<total; i++) {
            var item = items[i];
            html+= '<article>';
            html+= '<a href="'+item.unescapedUrl+'">';
            html+= '<h3>'+item.titleNoFormatting+'</h3>';
            html+= '</a>';
            html+= '<p>';
            html+= item.content;
            html+= '</p>';
            html+= '</article>';
        document.getElementById('newsresults').innerHTML = html;

Now, I can call that function at the bottom of my document:


If I only want to run that search when there’s room for a sidebar, I can wrap it in an if statement:

if (document.documentElement.clientWidth > 640) {

If the browser is wider than 640 pixels, that will fire off a search for news stories about cats and put the results into the newsresults element in my markup:

<div id="newsresults">
<!-- search results go here -->

This works pretty well but I’m making an assumption that people with small-screen devices wouldn’t be interested in seeing that nice-to-have content. You know what they say about assumptions: they make an ass out of you and umptions. I should really try to give everyone at least the option to get to that extra content:

<div id="newsresults">
<a href="http://www.google.com/search?q=cats&tbm=nws">Search Google News</a>

See the result

Visitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.

I’ve been concentrating on HTML and JavaScript, but this technique has consequences for content strategy and information architecture. Instead of thinking about possible page content in a binary way as either ‘on the page’ or ‘not on the page’, conditional loading introduces a third ‘it’s complicated’ option.

This was just a simple example but I hope it illustrates that conditional loading could become an important part of the content-first responsive design approach.

Update: I’ve published some further thoughts on clean conditional loading

Wednesday, December 1st, 2010

The 24 Ways Annual 2010 | Five Simple Steps

All of this year's 24Ways articles are available as an £8 book with all the proceeds going to UNICEF.

Thursday, December 31st, 2009

The future of the tradition

Drew and Brian did a superb job with this year’s 24 Ways, the advent calendar for geeks. There were some recurring themes: HTML5 from Yaili, Bruce and myself; CSS3 from Drew, Natalie and Rachel; and workflow from Andy and Meagan.

The matter of personal projects was also surprisingly prevalent. Elliot wrote A Pet Project is For Life, Not Just for Christmas and Jina specifically mentioned Huffduffer in her piece, Make Out Like a Bandit. December was the month for praising personal projects: that’s exactly what I was talking about at Refresh Belfast at the start of the month.

If you don’t have a personal project on the go, I highly recommend it. It’s a great way of learning new skills and experimenting with new technology. It’s also a good safety valve that can keep you sane when work is getting you down.

Working on Huffduffer is a lot of fun and I plan to keep iterating on the site whenever I can. But the project that I’ve really invested my soul into is The Session. Over the past decade, the site has built up a large international community with a comprehensive store of tunes and sessions.

Running any community site requires a lot of time and I haven’t always been as hands-on as I could have been with The Session. As a result, the discourse can occasionally spiral downwards into nastiness, prompting me to ask myself, Why do I bother? But then when someone contributes something wonderful to the site, I’m reminded of why I started it in the first place.

My dedication to the site was crystallised recently by a sad event. A long-time contributor to the site passed away. Looking back over the generosity of his contributions made me realise that The Session isn’t a personal project at all: it’s a community project, and I have a duty to enable the people in the community to connect. I also have a duty to maintain the URLs created by the community (are you listening, Yahoo?).

I feel like I’ve been neglecting the site. I could be doing so much more with the collective data, especially around location. The underlying code definitely needs refactoring, and the visual design could certainly do with a refresh (although I think it’s held up pretty well for such a long-running site).

I’m not going to make a new year’s resolution—that would just give me another deadline to stress out about—but I’m making a personal commitment to do whatever I can for The Session in 2010.

Wednesday, December 10th, 2008

24 ways: A Christmas hCard From Me To You

A great 24 Ways article by Elliot on creating and styling hCards.

Monday, December 8th, 2008

Feedback loopy

24 Ways is back again this year. Today’s article is a little something I penned called The IE6 Equation. Share and enjoy!

The design of 24 Ways has been refreshed for this festive season and it has prompted quite a varied reaction. That’s always a good sign. You might love it or you might hate it but you’re probably not ambivalent about it. Veerle has written more on this subject, provocatively asking Do you innovate or opt for the safe route in web design?

The implementation prompted as much feedback as the design itself. Clearly, 24 Ways is a site with an immovable deadline. It’s an advent calendar so it must go live on December 1st. This year, that meant that some cross-browser issues weren’t sorted out on the first day. A few days after the site launched, everything was hunky-dory but in the interim, there was a clamour of epic fail! from indignant visitors to the site. I’m finding that Andy’s thoughts on this term of derision has become the canonical document to point people to for a healthy dose of perspective.

Merlin Mann’s observation, delivered in fewer than 140 characters, deserves to be framed and mounted next to every input device:

Some days, the web feels like 5 people trying to make something; 5k people turning it into a list; and 500MM people saying, “FAIL.”

If you’ve ever created anything on the web—a story, a picture, a video or an application—then you’ll be familiar with the range of responses that will result. I don’t just mean the laughably mindless babblings of the Diggtards and Reddidiots; I’m referring to that peculiar effect that sitting behind a monitor has on otherwise level-headed well-adjusted people. In the same way that some people undergo a Jekyll and Hyde transformation behind the wheel of a car, computer keyboards have a tendency to bring out the fuckwad in many of us—I include myself amongst that group.

The upshot of this effect is that criticism tends to be harsher online than if it were delivered in real life, which might just be due to the lack of . Should you find yourself on the receiving end of some criticism, having built a labour of love, I’ve put together a hierarchy of verb tenses by which you can weigh the feedback you’re receiving:

  1. Past. Advice from someone who has also built something is valuable. Their opinion is informed by experimental data.
  2. Present. If someone else is also building something, it’s worth paying attention to what they have to say.
  3. Conditional. This is the bottom of the pile. If someone describes what they “would” have done or what you “should” have done, it isn’t worth wasting your retinas on the photons of that feedback.

Although this hierarchy of verb tenses was prompted by web-native creations, it probably works equally well for film-making, plumbing, literature, dentistry, music, or just about any endeavour of the human spirit.