CSS Guidelines

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

CSS Style Development / Design Guidelines[edit]

The use of raw HTML should be sufficient to create any element on the Interactive Investor website, as the CSS style sheet controls all spacing, layout and style information, without the need for inline CSS.

This purely helps to facilite the requirement to manage several 'skins' on a range of sites powered by universal components, and the ability to modify and evolve the style sheets as necessary.

Current Issue

Due to legacy code on the site, there is a marked difference between design and development pages. Different parts of the site are written in different languages, and use different templates. Although the goal is to bring all these elements closer together, currently any changes to the existing style sheet can have adverse affects to different parts of the site, and as such require varying degrees of testing.


Wireframes and designs should be implemented with the minimal effort, controlled via a global style sheet that has been agreed by both design and development, and the aforementioned style sheet should be easily updatable by in terms of rolling out look and feel tweaks across the existing site(s) as necessary. Design needs to be aware of all technical limitations before embarking on a new project, and in the same vein development need to keep design aware of such findings.

Key points

  • Always use semantic HTML
  • HTML design should always validate as per W3C standards, to ensure ease of production
  • Only use DIVs for layout – tables should only be used for tabular data
  • Use correct Table HTML structure (caption, thead, tbody, tfoot)
  • No inline CSS – although can occasionally be used to achieve a particular effect inside a reusable component, i.e. always float right or fixed width, rather than creating a new style for each component – but should be limited to only one or two attributes
  • As the requirement appears for CSS styles to evolve, these should be tackled on a style by style basis as an individual project, and tested across the site in development before live implementation
  • Design suggests a monthly or two monthly review of the style sheet between design and development that will produce some actions to tidy things up or fix existing bugs with styles – perhaps this could be solved with a monthly email from design with the ‘top bugs’?
  • Some degree of accessibility has already been achieved within the HTML – what’s the next rung?

New style / element rules

  • New colors / updates to colors should be kept to same contrast levels inside the existing palette to minimize color shift issues in other areas of the site
  • List elements should never use list-style-image, but instead background-image with padding for greater degree of control and cross browser/platform compatibility
  • Elements should always space themselves via margin-bottom for consistent display
  • Buttons should always stay the width of the button text
  • Site typography needs to follow a predefined format – design suggests type rules of margin: 5px 0; on P elements, and margin: 10px 0; on H class elements
  • Links need to be obvious on the site, either through the use of underline, border-bottom or a unique color