A scalable and modular approach to writing CSS

Scalable and Modular Architecture for CSS

Something that I’ve been keen to introduce to the web team for quite a while is a coding standard: a style guide, a consistent way for the whole team to write and format their code (whether HTML, CSS, JavaScript or PHP) and name their assets (documents, images, videos, etc.) so we spend less time trying to figure out what the last person did and more time being productive.

I actually started work on one after a meeting we had with a few developers and project managers back in October 2010 but I kept getting interrupted. I kept getting taken off ‘just writing documentation’ and put on other projects because they were seen as more important.

The importance of code conventions

Interestingly the last JavaScript Jabber podcast (#075) features a long conversation with Nicholas Zakas, author of Maintainable JavaScript, who talks about the importance of writing code that others can immediately understand and work with without needing to reformat or rewrite it.

The idea behind maintainable JavaScript. Or really maintainable anything is that somebody other than you has a fighting chance at maintaining it later on. […]

There are a few things that go along with that: […] When you look at the code it’s laid out nicely; you’re playing by the rules that have been set down at your company or on your team.

One of the biggest things that annoyed me in my career is that you go some place and you’d have five people on the team and they are all writing code slightly different. How many times have you ever opened up a file and before you did anything you’ve reset all of the formatting?

The discussion then moves on to the importance of code formatting issues. One of the co-hosts confesses that he has often become more incensed by co-workers using inconsistent formatting than by anything else because it adds needless extra mental effort.

Zakas agrees and refers to the work of Daniel Kahneman’s book Thinking, Fast and Slow explaining that our brains get used to particular patterns, and when you detect an anomaly in that patterns that you’re used to you switch into a different mode in your brain and that upsets you.

Zakas explains that when he worked as a consultant he used to go into companies to help them sort out their coding conventions:

I’m a very big believer in the broken windows theory where you need to do the small things right if you have any chance to get the big things right.

Jonathan Snook: SMACSS

One approach to organising CSS code that I’ve been investigating and trying out is SMACSS (scalable and modular architecture for CSS) which has been developed by Canadian developer Jonathan Snook.

In his book he talks about structuring your CSS not only in terms of how to organise the code but also the naming convention that he uses for classes and IDs.

What I’ve found immediately helpful, however, is the way that he categorises CSS rules into five groups:

  1. Base
    These are the defaults, usually single element selectors such as a, input or li.
  2. Layout
    These rules divide the page into sections.
  3. Modules
    These rules introduce reusable blocks, such as sidebar sections, product lists, carousels, tabs.
  4. State
    This was a new way of thinking for me, which I find particularly useful: how do things look in a particular state, e.g. when something is hidden or expanded, active or inactive. I especially like his class naming conventions for state which makes them readable, for example: .is-pressed, .is-disabled.
  5. Themes
    Themes are something that we use already on the University website: we often have a common core of page styles and elements but which are themed or skinned differently, for example compare Current Staff with Current Students.

I’ve used this approach in a few stylesheets now and the clarity it brings to organising my code has been very welcome. I’ve found myself asking “what is this to do with?” This is layout so the code needs to go in this section, that is a module so it needs to go into this other section. It has allowed me to offer a generic theme within the module itself, and over-rule it with a particular theme, if required. Very useful.

My next task is to explore Snook’s naming rules (he uses prefixes such as l- for layouts, is- for states) and compare it against the BEM (block-element-modifier) approach advocated by Yandex.

No doubt I will report back.

Advertisements

Making the Student Handbook mobile-friendly

Yesterday I wrote a post about our first steps into the mobile web. Today I will look at what I had to do to make it happen.

Learning about the principles

The first step was to think about the principles behind mobile web design. I am well versed in the principles behind desktop web design, but mobile is a different ball game. The focus is even more strongly centred on a streamlined approach — less is more.

The only other thing I really knew is that there are no easy answers. I had to do my research.

The first question to ask myself was, is a three year old book about mobile web design still relevant? Gareth let me borrow this book, and while parts of it feel out of date, there is still plenty of insight to chew over. It is particularly useful when thinking about older or non-‘smart’ mobile devices. There is a tendency nowadays for articles about mobile to be heavily focussed on iPhone and Android. While this book does feature the iPhone, it is much more about the wider principles of mobile web design.

I also found it useful to take a look at Patrick Lauke’s slides about the mobile web, which he delivered at IWMW. These are more up-to-date, and it was useful to refresh my memory about what I had learnt.

There are three major approaches to tackling mobile:

  1. Do nothing and hope for the best.
  2. Create a separate mobile site.
  3. Adapt what already exists.

Option 3 was the only one really open to us. This option requires compromises to be made. It probably also leads to the largest file sizes. But it is easier, and if you use web standards and code your website well, it should work well enough on a mobile device.

The stylesheet

The first step was to create a stylesheet optimised for mobile devices. A decision was taken early on to focus on the current generation of browsers, as mSaint is designed primarily for smartphones. Mobile Safari, Android and Opera Mini and Mobile all ignore stylesheets with the attribute media="handheld". Modern mobile browsers like to think of themselves as a cut above that sort of thing. They try to render a webpage more or less as you would expect it to on a desktop.

(Handheld stylesheets have always been shakily supported anyway. I have created one nonetheless as a fallback for any mobile browsers that prefer to deliver a webpage in this way.)

But accepting that modern mobile browsers will render the desktop version was not an option in this case. The technique around this is to use CSS3 media queries, which allow us to dictate which stylesheet is used based on the width of the device or browser window. Perfect for adapting content for mobile!

There is a good tutorial on how to use media queries. Guess which browser doesn’t quite like it? Internet Explorer’s issues were the source of some of the biggest puzzles I faced. But since I figured out how to make IE play nicely, it has worked well.

Design

So that it integrates well with mSaint, we have removed a lot of the devices that you find on a standard University webpage. The header, main navigation, left hand navigation and footer have all gone. Basically, everything except the content has gone. Thank goodness for display: none;!

Much of the rest of the stylesheet has been lifted straight from the existing stylesheets. So it should look and feel pretty familiar to regular users of the University website. The other major change I made was to lay out all of the content so that it sits in one mobile-sized column. So any items that appear in the right hand sidebar on the desktop version of the Student Handbook will appear beneath the main content on the mobile version.

When deciding on the ideal width of the column, I settled on a maximum width of 480px. This is the width of an iPhone in landscape mode. But I did not just make this decision with iPhone goggles on. Looking at standard screen resolutions for mobile devices (QVGA, HVGA, VGA and WVGA), 480px is the dimension that comes up the most.

Viewport

The main thing that I have learnt that I was not aware of before is to do with the viewport. The iPhone automatically displays every webpage as though it were 980px wide, and this becomes the scrollable area of the webpage. But if you have optimised the content specifically for mobile display, this is no good. The text is zoomed out and unreadable. The user must manually zoom in, even though there is absolutely nothing on the rest of the page.

The answer is to use the viewport meta tag:

<meta name="viewport" content="width=device-width" />

This tells your mobile browser to automatically zoom in as though the web page were as wide as the mobile device. You can also set a specific width, as well as setting an initial scale and control how far the user can zoom in and out. Originally introduced by Apple for Safari, it seems as though most modern mobile browsers recognise and support this — though this hasn’t been without its problems.

I have been a bit iffy about including the viewport meta tag on these standard web pages. From what I gather, its presence is supposed to indicate that the webpage has been optimised for mobile, which ours hasn’t. It also appears to alter the behaviour of Opera Mobile (by disabling the mobile view option). However, it appears to have no effect on the way desktop browsers display the page, while making it look much better on mobile devices. So we are sticking with it for the time being.

But just when I had got my head around how to control the viewport, imagine my shock when I discovered that a pixel is not a pixel. That is to say, the number of pixels on your device is not the same as the number of pixels that appear to be displayed. Accommodating different screen sizes and resolutions seem complicated at first, and unfortunately it only becomes more complicated as you learn more!

Apple have a very useful guide for developers called Safari Reference Library. It was hugely useful in helping me understand about the viewport and a lot of the other quirks of Safari for iOS, such as automatic text resizing. I think Safari tries to be too clever for its own good sometimes. This makes it a brilliant mobile browser overall, but it is quite frustrating as a developer to try and work out precisely what it is doing.

Incidentally, Opera also have a good mobile web optimisation guide.

Testing

Testing for mobile is notoriously difficult. There are hundreds of different devices, operating systems and browsers out there, with radically differing capabilities. Testing every possible combination is even more impossible for mobile. It makes designing for desktops look like a piece of cake.

The book Mobile Web Design by Cameron Moll contains a highly interesting section about Yahoo!’s procedure for testing their 2006 FIFA World Cup mobile site. By selecting a range of 5-10 devices from top- to bottom-end to test on, they felt that they had covered a wide enough range for the website to work on most mobile browsers. The technique paid off for them as it was a hugely successful website, attracting a peak of 290 million page views in one day. And that was four years ago. Incredible!

We are not aiming for that sort of audience, so our testing has been an even more modest affair. I used my own iPhone to test it in Safari and Opera Mini. But this has been quite frustrating as it is very difficult to get a signal in my office. Upstairs, my colleague has also been testing on an Android emulator.

The Opera Mobile emulator has also been hugely useful, particularly for comparing different screen sizes. How important Opera Mobile actually is, I am not sure. At the end of last semester, around 1% of visits to the University website were on a mobile device. Among those users, Opera does not appear to figure as highly as I had expected.

There is more information about mobile emulators here. These are highly useful tools for finding out how a mobile browser will render a page. But unfortunately they tell us little about how it genuinely feels to use a website on a particular type of device.