Future-Proof Your Web Site Design by Planning Your CSS In Advance

Christian Watson CSS, Web Design

A web site is like a building. Over time it gets lived in. And, regardless of the initial intentions of the designer for how everything within it should be arranged, things get moved around, stuff gets added, some things get taken away, more stuff gets added, the occasional renovation takes place, and yet more stuff gets added.

Many web sites are not really designed to be ‘lived in’ — i.e. to support all these changes by different owners with various intentions. After a while they bear little resemblance to any sort of coherent design and are likely to become increasingly hard to manage.

Of course, it’s impossible to plan for all the ‘home improvements’ that will happen to a web site between major redesigns.

However, it is possible to be prepared so that the addition of something new to a page doesn’t break its design.

A good way to future-proof a web site is to create styles in advance for the most common page elements, even if they are not yet being used. This is called ‘planning ahead’ 😉 and is an activity often overlooked by web designers.

Using the ‘planning ahead’ method, if a content author wants to add something to a page — say, a definition list — you’ve already planned how it will look so that it fits within the overall page design and will coexist with the other elements that may be present.

Let’s take a look at the more common page elements a future-proofed site should plan for.

Headings

Even though you may only be using H1s and H2s, it’s worth creating styles for H1 down to H4.

I’d question whether you need to go further than that (perhaps just make H4, H5 and H6 look the same). If a content author feels the need to use heading levels all the way down to H5 or H6 the structure of their content may be in question.

You might also want to create a style for a byline or a page summary as it’s not uncommon for these to be used below the main page heading.

Lists

Lists can be quite tricky from a layout perspective, especially when you take cross-browser display issues into account.

Therefore, it’s essential to plan for different implementations of lists in advance.

Of course, you’ll create styles for the standard ordered and unordered list. But, what about nested lists? I would at least plan for the following variations:

  • Unordered list with a nested unordered list
  • Unordered list with a nested ordered list
  • Ordered list with a nested ordered list
  • Ordered list with a nested unordered list

I wouldn’t worry about more than one level of nesting. If the content requires this, from a web readability standpoint it should more than likely be rewritten.

Definition lists are a great way to display lists of resources. You’ll often have a link to a resource (such as a PDF) and a summary sentence below it. Take the time to set this style up and you’ll stop users from littering your ‘resources’ pages with <br /> tags.

Web pages often start with a list of jump links to the various sections on the page. It’s worth considering a style for this type of link list, to visually separate it from the regular content on the page.

A list of links with thumbnails plus a summary is quite a popular approach for gallery pages, so you may want to create such a style in advance.

Tables

Tables can be very time-consuming to build and style. However, with a little forethought at least the styling part can be made easier.

Be sure to plan for types of data other than numerical that tables can contain — such as text and images.

Here are the common table elements that you should consider:

  • Table headings along the top row
  • Table headings along the top row and left column
  • Table cell containing text (multiple paragraphs) / list / image
  • Caption
  • Footnotes

It’s also worth adding in advance any table-related functionality (often JavaScript-based) that you will likely be using. This can include:

  • Displaying table row backgrounds in alternating colors
  • Highlighting the row and/or column being moused over
  • Sorting a table by a column

If you’re managing a corporate web site it’s a good idea to also think about financial data such as that in an annual report might be displayed.

Images

There aren’t too many variations on how images are placed within content, so they’re pretty easy to plan for. Try incorporating options for the following:

  • Image floated to the left or right
  • Image with a caption
  • Image with a caption that contains a link
  • Image that is a link
  • Image that displays a larger version on being clicked
  • Multi-image slideshow
  • Image with a photography credit

Links

As well as the standard link states, consider whether links to external sites and to downloadable files should be treated differently (i.e. indicating the target of the link).

It may also be worth planning for how to style an A to Z index.

Forms

It’s impossible to plan for all the layout complexities that forms can require.

However, do plan for all the standard form elements — for example, that are present in a registration form — as well as how error messages will be presented.

JavaScript

I’m no JavaScript expert, but I do know that it’s often a good idea to choose a JavaScript library upfront rather than cherry pick individual scripts and hope they all work well together.

Doing this will help you to avoid functionality clashes and bloat that can come from using scripts from a variety of sources. I’ve used jQuery in the past, which is well established and has a good selection of plugins.

Pull Quotes

Pull quotes are a great way to call out important information or lines from quotations. I’d highly recommend creating styles for these common pull quote variants:

  • Floated to the left and right
  • Within a paragraph and at the start of a paragraph
  • Without a citation
  • With a citation

Other Things to Consider

If you’re not already using Flash, plan for how you will embed it into your site. Also, consider creating styles for displaying sidebar content such as boxes of related links or featured resources.

Don’t forget to create a print style sheet and maybe even a mobile style sheet (and remember to keep them updated).

How Does Everything Fit Together?

Lastly, it’s important to test the interaction of different combinations of page elements.

It’s simple enough to separate headings and paragraphs appropriately. But what about a heading followed by a table? Or, a heading preceded by a list? Or an H2 followed by an H3?

The same is true for other page elements — for example, lists followed by tables.

It’s worth taking the time to try out these different page layouts (including the more unlikely ones) to make sure that your spacing is set up correctly.

It’s much easier to do this in advance than to incrementally tweak your CSS as content gets moved around and added.

19 thoughts to “Future-Proof Your Web Site Design by Planning Your CSS In Advance”

  1. I’m about to redesign a website at work and am going to try the “planning ahead” approach. It makes so much sense I’m just mad I didn’t think of it during the last redesign.
    Thanks.

  2. The other thing to consider is how the end user will apply these styles. If they’re handling mark-up themselves, then you’ll need to supply a style guide, and if they’re using a CMS, then you need to find ways of letting the user attach your styles to elements (which may not always be straightforward, e.g. sometimes you can style list items, but not the list container itself).

  3. That’s a very nice and comprehensive list. On most of our projects we run into these elements, and try to plan ahead.
    We also have elements like horizontal lists, and (don’t laugh – cross-browser-css-support for some css-ideas is really bad) styles for layout-less tables for arranging complex layout.
    For forms you may want to consider fieldsets, regular inputs, none-styled-inputs (for file-upload, checkboxes and radiobuttons), selects and buttons. Oh, and labels.
    And our very first approach to css is always “* {margin:0;padding:0;}”

  4. Great rundown! I have never thought of nested lists, to be honest. So I learned something new today, thank you.
    It’s especially necessary to think of these things with CMS powered websites where you might not know the content beforehand. You never know what your user manages to do 😉

  6. Calm down Joe W. While it is recommended not to use tables there are cases when it is not only proper but recommended. Such as when displaying tabular data.

  8. *John* — absolutely you will need a style guide. No point in doing all this future-proofing if no one knows about it. Good point.
    *Frank* — agreed. I thought it might be overkill to list out all the various form elements. Which is why I recommended that you set up styles for the most common form elements, which tend to show up in a registration form.
    *Joe* — that is the scariest comment I’ve had in a while! Remember: tables for layout = bad; tables for data = good.

  9. Great article on a subject it seems like no one discusses too much. Dan Cederholm has an excellent book, “Bulletproof Web Design” that focuses more on developing flexible structures and containers that can accomodate change.
    The downside to all of this is adding a great deal of time to a development cycle. It might be helpful to scope the general content variation possibilities and then plan from there.

  10. *Elbert* — I have Dan’s book and it is a good one. Very readable too.
    I’m not so sure about how much time this level of preparation adds. The content variations I’ve outlined are pretty common, so more often than not (especially on large sites) there will be a need for them at some point.
    I’d say it was more efficient to do the planning upfront rather than to do the work in a more ad hoc manner.

  11. A great article…now a days designers focusing on tableless designs while conversions, the reason is only to get the site should go high on search engines more than competitors.

  12. Very well written article, thanks for that. I agree with most of it, although sometimes I just do not have the time to add style to elements that may never be used, not to mention that (as said above), sometimes applying styles to certain elements within certain containers on top of integration with a ‘dumbed-down’ CMS can make for a daunting task.

  14. Regarding tables: Well, our teams tries to limit the use of tables to tabular data. At Berliner Akzente we tried real hard – but due to missing support from IE6 / IE7 for some of our CSS-stunts, we had to revert to tables for layout. 🙁
    Well, but we finally managed to get the HP of Berlin.de to work without any tables. And it’s valid, too. 🙂
    In real-live conditions it is a financial matter if you want to use tables or not. Development time for table-less designs rendering properly in _all_ browsers is much, much higher. It pains me deeply – but that’s live.
    Sometimes I am just happy to reduce the amount of tables – compare the real world Netzeitung against this restructured version of Netzeitung 🙂

  16. I’m thinking of redesigning some of my existing websites to include the tips provided here. I’m sure it will help a lot especially towards create tables.

  17. Great article – for our redesign, we’re looking to limit the use of tables to data that requires it (eg. financial information) and using CSS for everything else. The hard part is the browser compatability!

Comments are closed.