Category: Reference

Responsive tables using CSS

As the world of web design has embraced CSS (and, indeed, become more aware of Accessibility) designers have become, in many ways, rather scornful about the humble HTML table—especially as responsive tables are so tricky.

As with every HTML element, there are good, semantic reasons to use tables in certain circumstances. Or, rather, in one circumstance—when you are displaying tabular data.

So far, so good.

The non-responsive solution

However, in our multi-device world, tables do provide some challenges—particularly on small screens. The simplest way to address the issue is, as Twitter Bootstrap does, simply to surround the table with a div that has overflow-x:auto; applied on small screens.

This has always struck me as being rather inelegant: it is a hack, a work-around to enable people to see tables as they would be displayed on the desktop, rather than a truly responsive solution.

So, I thought that I’d share two different solutions that I have used (and continue to use) for responsive tables. I don’t claim to have invented either of them—I have seen similar solutions elsewhere—but I thought that my particular twists might help others.

Hiding columns with the Checkbox Hack

In my day job, we often have to generate pages that display quite large tables—such as a tenant’s rent statement. These will have, say, seven or eight columns, e.g. date of payment, several individual charges, the total charge, and the remaining balance.

The first thing that I did was to talk to the customer, and get them to survey their tenants to find out which were the most important pieces of data. Armed with this information, I used @media queries to hide all but the most important columns on small screens. Thus, when accessing their account through a mobile, the tenant was presented with the date of payment, the total payment, and the remaining balance—the three of which fitted easily without horizontal scrolling.

Crucially, however, if they wished to see other columns, then they could switch columns on and off as desired. And all of this was achieved using only the CSS Checkbox Hack, as demonstrated in the Pen below (this example is not responsive, but you can use the label buttons to switch columns on and off).

See the Pen Table sizing and checkbox toggling by Chris Mounsey (@devilskitchen) on CodePen.

This is a nicer solution than the scrolling div, since it does allow the user to focus on the important information—and, in this type of case, it may even be the best solution.

What do you do when you cannot separate the columns of primary importance? And how do you craft a truly responsive table?

Pivoting the table using data-attributes

The neatest solution that I have adopted is one in which we use data-attributes to replicate our headings, and then simply pivot the table.

In order to achieve this sort of responsive table, we first add the column title to the relevant cells (this does imply a slightly larger HTML foot-print, but you are GZipping your website, right?). So:

Now, we use @media queries to apply the following CSS for small screens (obviously, I use LESS, but I’m showing the CSS for those of you who aren’t familiar with pre-processors).

After that, all you need to do is to use standard CSS to make things look prettier. The Pen below shows one of my more recent efforts: resize the window to see the responsive table pivot (there is a desktop, a tablet and a mobile state).

See the Pen Responsive Table by Chris Mounsey (@devilskitchen) on CodePen.

Conclusion

I think that both of the responsive table examples above work better any others that I have so far used. As outlined, which one of these I use in production rather depends on the purpose of the table.

However, I hope that this quick post gives you some ideas about designing truly responsive tables.

Flexbox

Two years ago, I tried to implement our web software interface using flexbox. Unfortunately, I was a little too eager in this endeavour, and had to hastily reinforce my fallbacks as the specification changed.

The Flexible Box Layout Model—commonly known as flexbox—has the potential to solve a number of perennial problems that front-end devs have been banging their heads against ever since CSS was invented in 1996, including equal height columns, true proportional width flexibility, and DOM ordering over-rides (very useful for Accessibility).

A number of these practical problems—and how flexbox solves them—are illustrated on Philip Walton’s Solved by Flexbox GitHub page.

However, as I discovered back in 2011, flexbox has had rather a chequered history—passing through three distinct specifications. Detailed support is outlined at caniuse.com, but, roughly, browser support is:

  • flexbox-legacy: supported by Safari 5–6 and Chrome 4–20;
  • flexbox-intermediate: Internet Explorer 10;
  • flexbox: Chrome 21+, Safari 6.1+ (allegedly), Firefox 21+ (sort of: there’s no support for flex-wrap and flex-flow).

To make things more complicated, Modernizr only has feature-detection for the oldest and newest syntax, which are output as flexbox-legacy and flexbox respectively.

And finally, once you delve into all of the possible variables, the syntax is not at all simple.

Luckily for us, a number of very smart people have been keeping up to date with all of the progress and built some useful web tools to generate code for us.

  • Flexyboxes provides a neat WYSIWYG interface for building flexible layouts, and it will generate code for all three syntaxes if you need to. Do be careful, however, as the older versions are not as capable as the up-to-date flexbox.
  • You can only use Flexplorer if your browser supports the latest syntax (which Safari 6.0.2 does not!), but it does also give a useful rundown of browser support for vendor prefix requirements.

With everything settling down—and a UI refresh of our software on the cards—I have been considering writing a set of LESS mixins for deploying flexbox in the wild. Inevitably, of course, putting “flexbox less mixins” swiftly shows that yet more smart people have got there first.

With so many to choose from, David de Coninck’s version jumped out at me most immediately—his use of guard expressions is really elegant.


See the Pen Flexbox 2013 LESS mixins by David De Coninck (@davidgenetic) on CodePen

Do you have a favourite LESS mixin that supports all of the syntaxes out of the box? Let me know in the comments…

 

Applications that I use

Having mentioned Sketch in my previous post, I thought that I would expand on the applications that I use in my workflows. And to start with, I need to expand on what those workflows actually are.

Which is tricky—because I do quite a number of varied jobs.

First, I do a considerable amount of management, both in my team and in the wider business. This is why my job title is the, slightly unwieldy, Creative and User Experience Manager (usually shortened to CrUX Manager).

Essentially, I lead the team that designs and builds our customers’ websites and intranets on our company’s content management platform (CMS). However, I also design the user interface (UI) and user experience (UX) for the CMS—plus I also design a lot of the new functionality too.

Occasionally, I give talks at events—both internal and external—about the web, CSS, Accessibility, and other related issues.

Because I know a lot about the web, our product and our customers, I have also spent a lot of time in customer pitches, Information Architecture (IA) workshops, and in discovery meetings for new software. In other words, I am heavily involved in a customer’s entire journeys with our company—and, in many cases, for determining the steps along that journey.

And, since I run the CrUX team, I am also responsible for recruitment to that team and, with the operations team, for managing resources on a day-to-day basis. And, of course, when we have a new starter, I am responsible for sorting out software and hardware—which means that I know how much we invest in our applications!

Which brings us back to where we began—the applications that I use to achieve all of this.

Graphic Design

For the moment, I find myself continually coming back to Photoshop—like a dog to its sick. I don’t really like Photoshop for design (and I loathe Illustrator) but it is familiar and thus relatively easy to dip into.

However, I am gradually weaning myself off Adobe’s products in favour of smaller, cheaper applications that are, in many ways, better for the job than Adobe’s bloated behemoth’s.

I have been playing about with Sketch (about £30) a lot, and I think it’s a wonderful application. It is very capable and, with every update (usually monthly), it becomes more capable and more stable. I am aiming to make it my primary design tool.

For non-vector based work, I have been getting into using Pixelmator (about £20) which is also an excellent (and cheap) photo-editing and design application.

Browsers

My browser of preference is Safari. Its Web Inspector tools are almost as capable as Chrome’s, and I find the browser faster and more reliable than Google’s offering.

However, I do test in all major browsers—including Internet Explorer 7, 8, 9 and 10. To achieve this on my Mac, I use VirtualBox (free) and the wonderful IEVMS script to automate the conversion of Microsoft’s supplied disk images to a format that VirtualBox can read.

Coding

A few years ago, I found myself, with a colleague, in a café with free Wi-Fi; up until that point, I had used Dreamweaver to code my work. However, my laptop was not equipped with my meatier applications and so—needing to do some coding and having read a good review of it—I downloaded Panic’s Coda.

And I have never seriously used another coding environment since (although I have also dabbled with MacRabbit’s Espresso—before they merged it with CSS Edit). I certainly never launched Dreamweaver ever again.

Coda was, essentially, my first foray into the sunlit uplands of indie Mac Developers. Up until that time, I had basically used Adobe applications and little else; for someone with this experience, the speed with which Coda launched and operated, as well as its feeling of lightness, were a revelation.

That independent developers are challenging Adobe in its core areas of photo-editing and vector design (this latter being an area that Adobe basically stole when it killed my beloved Freehand) is one of the very best things about the Mac platform right now.

I write in LESS and use the excellent CodeKit to process it, as well as for compressing images, and other useful things. Be sure to read CodeKit’s amusing release notes, by the way…

Finally, I started using CodePen a lot for experiments, reduced test cases, reference files, etc. I particularly like the fact that it compiles LESS on the fly. I haven’t had much time to continue playing with it recently, but that should change in the next few days.

Software Design

My role in this area is, essentially, to gather customer needs, to productise them, and write requirements specifications.

For this I use Apple’s Pages (£14) for the text and, for the workflows, Celestial Teapot’s very nice little diagramming application called, simply, Shapes (roughly £3!).

This latter app is—like most Mac indie apps—under active development and Celestial Teapot seem very good at taking feedback and incorporating it into releases.

Administration

For most other administrative tasks, I use Pages, Numbers and—for presentations and speaking engagements—Keynote.

When presenting, I use Apple’s Keynote Remote—running on my iPhone—to control the slides and display presenter notes (where necessary). In the absence of Wi-Fi (a rare thing these days) I carry a standard, hardware Apple Remote.

Miscellaneous

I do dabble with a few other apps, and I like to try out new applications quite often.

Wireframes

Where necessary, I use MockingBird for building up wireframes; it is simple, elegant and easy-to-use. The lack of development on it over the last couple of years has been disappointing, but it is still an excellent online application.

Animation

One app which has a great deal of potential is Tumult’s Hype. Using this application, you can build up complex animations using a timeline model, and Hype will then generate a file containing CSS3 animations (including complex matrices): even better, it will also generate the Javascript required to cater for older browsers.

Combine this with Modernizr and the built-in YepNopeJS, and you have a modern, compliant solution for creating complex animations.

Project Planning

Since I have taken over my current job role I don’t use OmniPlan as much, but I still find it useful for internal scheduling: it’s a fully-fledged project management application, with proper concepts of utilisation and efficiency.

Font Management

For font management, I still use the free version of Linotype FontExplorer X (which, whilst difficult to find now, has lasted me for years and years!), but I am starting to switch over to Bohemian Coding’s Font Case.

For web fonts, I use TypeKit (although, since Adobe has taken over, I am finding some issues with reliability. What a surprise) and, occasionally, Google Web Fonts.

And that’s about it. There are one or two applications that I play with, but the major ones are those listed above.

Do you have any favourite applications? Feel free to leave your preferences in the comments…

A new CSS property — position:sticky;

My blog colleague, Mike, wrote about implementing “sticky” menus in Javascript; however, it seems that this effect can be achieved in WebKit browsers through a new CSS property—position:sticky;.

By simply adding position: sticky (vendor prefixed), we can tell an element to be position: relative until the user scrolls the item (or its parent) to be 15px from the top:

At top: 15px, the element becomes fixed.

HTML5 Rocks has put together a demo although, of course, it will not work in anything other the latest version of Chrome or the WebKit Nightlies.

However, I can think of a couple of places where I should incorporate position:sticky; into our company’s CMS and shall do so, against the day when the property is widespread.

As a point of interest, this tends to be my general strategy for new CSS properties: I implement them into our systems so that, in the future, people get a nice surprise!

UPDATE 18/05/2014: position:sticky; seems to have appeared and disappeared more often than a flexbox spec. However, Can I Use reports that position:sticky; is supported on  Safari 6.1+ (on desktop and iOS) with the -webkit- prefix, and that support is coming to Firefox and Chrome in the near future.

Web Fonts

Adobe have just recently announced the release of Adobe Edge Web Fonts, a large library of web fonts. Whilst Adobe has teamed up with Google in order to offer many of these typefaces, they are served through TypeKit—which was bought by Adobe some months ago—and are free to use (for now, at least).

I am a great fan of using web fonts—anything has to be better than constant doses of Arial. There are certain pitfalls and caveats that web designers do need to bear in mind, but I shall cover those in a later post.

Right now, I would like to make an observation—simply because it amuses me…

Ten years ago, companies were getting frustrated that they couldn’t use their super print-specified corporate fonts on their websites (at least not without using some horrible substitution system like Flash or Cufon).

So, in the last few years, we have seen more and more companies changing their corporate image—and all of their print and branding material—to one of the 30-odd typefaces available to “normal” web browsers (such as Trebuchet or Lucida).

Now, the web font revolution has hugely expanded the number of typefaces available on the web—rendering all of the rebrands utterly unnecessary!

I am most amused…

Writing sustainable CSS using SOLID principles

We all know what it’s like: you start off with the best of intentions—to write neat, sustainable CSS using all of the very latest fashions (DRY, OOCSS, etc.)—but then the clock is ticking and you find yourself rushing the project and producing a stylesheet that, whilst not totally awful, still resembles spaghetti.

This is a problem that only becomes compounded when you are writing Less: here the problem becomes one of lazy nesting and, next thing you know, not only do you have selectors that are 80,000 characters long but you have also “cemented” certain elements—you know that if the customer moves that slideshow from that position on that page, then the whole thing is going to fall apart.

Leaving aside the special considerations that you need to bear in mind when implementing designs onto a large CMS (which I intend to address in another post), writing sustainable CSS is absolutely essential to a web designer. The simple fact is that sites with well-written CSS will load faster, be easier to maintain (essential if your customers are regarded as partners), be more flexible (from a CMS point of view) and be generally more elegant.

Introducing SOLID Principles to sustainable CSS

There are, of course, many opinions as to what makes sustainable CSS: however, one of the best articles that I have read on the subject is this post on SOLID principles by Miller Medeiros.

SOLID is an acronym for five basic principles of object-oriented programming and design that when applied together can make systems easier to maintain and to extend over time. The term was coined by Uncle Bob and I’m pretty sure he didn’t had CSS in mind(although I didn’t asked him).

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Now, this all sounds a bit too techie for me, but Miller goes on to explain the principles in  rather more detail.

Single Responsibility Principle

This principle states that an object should have only a single responsibility, and that responsibility should be entirely encapsulated by the object. When applied to CSS this means that we should separate structure from presentation, instead of creating a single class and/or element that does both, we should decouple them so you can change the skinning of the components without affecting the structure.

CSS rules should have a high cohesion, you shouldn’t normally see too many different kinds of rules grouped together. You shouldn’t have text styles + borders + colors grouped with dimensions + positioning and floats.

By doing so we can reuse the same modules inside a different container and increase the chance of reuse. It will also make maintenance easier since you can change the skinning without affecting the structure and can toggle the visual easily based on the context (eg. element with same structure but different colors).

This principle sounds sensible enough—and its particularly easy to address when using CSS pre-processors—but, in fact, it is usually the very first method to go out of the window when you are under pressure to deliver.

Open/Closed Principle

“software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”

That means that you should make it easy to overwrite/extend the base rules and should avoid editing the base classes.

You should only edit a base class if you are fixing an error, never add new behavior, otherwise you might introduce conflicts. That means that you should not change yourreset.css file or edit rules that affects multiple elements after the project is stable. Create a new class that augments it instead of editing it.

This is an easy principle to stick to, since it can save a lot of time: with the capabilities of Less, I quite often find myself writing things like this:

In Sass, you can use the @extend  class to do this even more sustainably. If you aren’t already doing this, then I heartily recommend that you adopt this methodology.

Liskov Substitution Principle

“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”

Classes that @extend others shouldn’t have a different behavior than the base class. You should be able to toggle between them without affecting the correctness of the app.

The idea behind this principle is that if you can swap Parent classes with their Children, without causing any undesired side effects, you will have a system that is more flexible and easier to understand. It will increase code reuse on cases that you couldn’t predict when the project started.

That means, modifiers should ideally affect only things that wouldn’t break the layout. If the base class doesn’t have a fixed height the child class shouldn’t have as well, the display and position also shouldn’t be changed.

Once again, this is a sensible principle that, again, often falls by the wayside.

Interface Segregation Principle

“many client specific interfaces are better than one general purpose interface.”

That means, it’s better to have multiple specific base modules than to have a single generic one. It will increase the cohesion of your modules and make code easier to refactor/change/maintain (since it reduces tight coupling).

Now, it has to be said that Miller does not seem to be entirely on board with this principle, or what it implies.

Sometimes it can be really tempting to create a base module that fits multiple scenarios trying to increase code reuse as much as possible. To be honest, lately I’ve been thinking that not all code reuse is a good thing. If you are doing it just for the sake of reusing(specially CSS) you might be increasing the coupling between modules without a need, that will make further changes harder to implement since it will cause a ripple effect to undesired modules (eg. changing the margin around an article in the homepage would also affect the margin around a blog post on the inner pages).

Which is fair enough.

Dependency Inversion Principle

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

I like to think this rule on the CSS domain means that the container shouldn’t care about the existence and the visual style of its children as long as it behaves how it expects it to behave. For an .article component it shouldn’t matter how the .title is styled, as long as the title doesn’t break the layout. We should delegate the styling of child components to their own modules and do it in a way that the child elements can be swapped without affecting the parent element. This is the core idea behind OOCSS.

Nested selectors are a sign that you might be breaking this rule. Instead of making nested selectors like #sidebar .group > h3 you should create a new class .group-title. That way it can be an <h3>, <div> or any other element you need. It will be easier to create new modules with slightly different styling/behavior by simply swapping the dependencies (child elements). This also favors composition over inheritance.

It also couples with an absolute principle that I advocate: that you should avoid targeting the mark-up element whenever possible—especially in these days of shifting HTML5 specifications!

Conclusions

I have been adhering to most of the SOLID principles for many years without really knowing about it, but this article is extremely good at articulating why I have been coding in the way that I have.

Over the years, I have had to dive into far too many website implementations and then recoiled when I have seen the state of the CSS (let’s leave aside the HTML for the moment).

These experiences have convinced me that one of the most important issues facing our company—if not the web as a whole—is the production of sustainable CSS.

Emulating a multi-line ellipsis in CSS

There are various methods for clamping the number of characters, words or lines that can be fitted into a particular space on a website. However, most of them involve limiting the characters either through Javascript or server-side language (and most involve unpleasant Regex expressions).

And while there are a few options for text-overflow , there is currently no elegant cross-browser solution for clamping the number of lines then ending with an ellipsis in CSS.

My personal favourite—because it focuses on the number of lines (which is more important for pernickety designs) rather than words or characters and ends the text excerpt with said ellipsis—is WebKit’s line-clamp property.

Which renders as:

On Webkit browsers, this should be limited to two lines and end in an ellipsis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam non auctor nunc. Aenean porttitor eros quis tellus dapibus vel scelerisque quam laoreet. Fusce vel nulla vitae erat adipiscing feugiat. Nam vitae mauris orci, et congue dolor. Aenean et leo eu dui ullamcorper pretium id at mauris. Donec dolor mauris, dignissim dapibus commodo eget, pretium id lorem. Nullam pharetra mollis imperdiet.

However, this method far from ideal for generating a multi-line ellipsis: it requires all of the attributes above, and is Webkit only—and, even then, it’s a non-standard property. (My theory is that it was created to clamp the information on TV show episodes in the iTunes Store.)

So, Mobify has created an excellent simulation of the line-clamp which will work in most browsers—yes, even in IE (with some tweaking). So, now you can deploy a multi-line ellipsis in CSS…