Close
Type at least 1 character to search
Back to top

Questioning standard CSS

CSS has transformed the way in which we code websites. In the ‘olden days’, we would have to repeatedly assign the same presentational attributes directly in the HTML, which meant that pages were typically long and cumbersome to maintain. The introduction of Cascading Style Sheets (CSS) eliminated the need for this tedious repetition, avoided extra markup and meant that webmasters could apply rules consistently to a whole site or even a whole group of sites easily and elegantly. Separating content from presentation seemed like a great idea, and with new evolutions of CSS, it is something that most web designers hold very dear.

So what’s wrong with standard CSS?

If websites remained simple, small and static, there would be no real problem at all. But of course they don’t, and the ever-increasing complexity of today’s websites means that CSS can prove to be a time-consuming, convoluted and fiddly business. The more changes that are required to a site, the more classes and rules are added and the more complex and lengthy our style sheets become. Webmasters resort to adding extra rules because they are afraid that changing the existing rules will affect other parts of the site and they don’t want to break anything. Some of the downsides of reliance on standard CSS include:

  • Bloat – style sheets can be incredibly long and difficult to manage
  • Obsolescence – style sheets can easily become full of redundant classes that are no longer required
  • Inflexibility – it can be difficult to make changes to individual components, since styles can be too far-reaching
  • Inconsistent browser support – CSS works differently on different browsers and some CSS features are not supported at all

What’s the alternative?

CSS rules should affect only the elements that pertain to them, and nothing else. Yet this is rarely the case. So the goal should be to write CSS that only affects certain elements, isolating components, limiting the scope of the cascade and grouping components according to the types of effects they have on the whole site. Using OOCSS or SASS might be a step in the right direction.

Object-oriented design (OOCSS)

The two main principles of OOCSS are the separation of structure and skin and the separation of container and content. Main benefits include:

  • Fast websites (fewer styles in the CSS lead to smaller file sizes and faster downloading). Markup will, however, be more cluttered
  • Data has to reside somewhere. But in many cases, the loss in markup performance will be surpassed by the gain in style sheet performance
  • Easy-to-maintain modules. Rather than adding new styles into the style sheet, you will reuse and extend existing styles

{module_contentholder,name=”Blog ad”}

SASS

The SASS (Systematically Awesome Style Sheets) language should win awards simply for its name, but does it help improve CSS? Open-source and coded in Ruby, SASS is an extension of CSS3, using variables, nesting, mixins and selector inheritance to provide a more succinct and user-friendly way of writing CSS. The especially deep grouping of selectors, however, can make SASS difficult for beginners or less experienced designers to learn.

Going further?

Using child and class selectors, abstracting features into class-based modules and so on can help ensure that rules only pertain to those elements the class is applied to, but should we be going further than this?

‘Atomic Design’

‘Atomic design’, a system created by Brad Frost, is based on the principle that the smaller the unit, the more reusable and flexible it is. Often spoken of as being like Lego bricks, the system advocates breaking styles down into small units, resulting in a palette of rules from which to choose. Rather than using contextual or descendant selectors and overwriting styles, atomic design serves a RTL style sheet and styles via direct HTML markup. The advantages of this are that there is no style sheet redundancy or dead weight.

The basic principle is that all web design can be broken down into:

  • Atoms
    Basic building blocks that can’t be broken down any further without losing meaning. Examples include HTML tags (e.g. a form label, an input or a button), colour palettes, fonts, animations
  • Molecules
    Groups of ‘atoms’ bonded together, e.g. a form
  • Organisms
    Groups of ‘molecules’, such as a combination of logo, navigation menu, search form and social media buttons, or a group consisting of product image, title and price tag)
  • Templates
    Concrete structures that consist of grouped ‘organisms’ in a given layout, and that look ‘real’ to clients
  • Pages
    Where placeholder content is replaced with real content and can be used to test template variations

Whilst proponents of the system state that it can help speed up workflow and write more efficient code, critics say that it is no better than old-fashioned inline styling. So far, the verdict is out, but with more people starting to question the necessity of separating structure, presentation and behaviour in web design, it’s likely that we’ll see further approaches to the problems of standard CSS.