General
- All front-end code should display clear separation of presentation, content, and behaviour.
- Markup should be well formed, semantically correct and generally valid.
- JavaScript should progressively enhance the experience
- Use feature detection rather than browser sniffing (Modernizr)
In short
- For all languages, indent your code with spaces. The default tab size should be set at 2.
- We prefer readability over file-size. Plenty of white-space is encouraged, along with as much commenting as needed, where appropriate. There is no need to purposefully compress files. Middleman (and Drupal) will automatically minify and gzip all static client-side files, such as CSS and JavaScript.
- Use multi-line CSS declarations. This helps with version control (single line CSS leads to merge conflicts).
- All CSS rules should have a space after the selector colon and a trailing semi-colon.
- When nesting selectors, try not to nest more than 3 levels deep. If you find yourself writing deeply nested selectors, it is usually a sign that you should rethink how you have structured your markup or class declarations.
Write Semantic HTML
One of the more important parts to remember when writing semantic and accessible code is to do your best to leverage the standard markup language. Do your best to write the cleanest code possible, and take pride in your work. Generally speaking, don’t use a meaningless element where another element might make more semantic sense, using a div where a h1 would be better fitted for example. Use semantic elements and attributes, as well as microdata and WAI-ARIA to extend the value of your code.
Mobile first
Greenwire should be built mobile first, specifiying the mobile styles as your base CSS and adding media queries to progressively enhance the experience for larger width devices and screens.
The problem with Internet Explorer version 8 and earlier not supporting media queries is solved with serving them a different stylesheet that has no media queries.
Object oriented CSS
Make sure your CSS can be reused wherever possible. Separate layout from styles. Instead of building dozens of unique components, try and spot repeated design patterns and abstract them. Build these skeletons as base 'components' and then peg classes onto these to extend their styling for more unique circumstances (modules). When applying a style to an element have a look if this style already exists. If not create a new reusable class and apply this on the specific element, and do not use a set of nested selectors.
Avoid attaching classes to elements in your stylesheet (i.e. don’t do div.header or h1.title)
With OOCSS, instead of a constantly growing stylesheet full of specificity wars, you’ll have an easy to maintain set of modules where the natural cascade plays an important role.
When making additions to an existing site, you won’t be adding new styles to the bottom of your stylesheet without regard for what came before. Instead you’ll be reusing existing styles and extending your styles based on existing rule sets.
With this type of forethought, it’s possible to create entire pages while coding very little CSS. WAI-ARIAny existing CSS modules can serve as a basis for all new pages, and any new CSS will be minimal. In some cases you might even be able to create a new fully-styled page without coding a single line of CSS.
These maintainability benefits also extend to the robustness of your stylesheets. Because the styles are modular, pages built on OOCSS will be less likely to break when a new developer starts to use the stylesheet.
Javascript
- Feature detect, don't browser detect. Modernizr is available.
- Name variables and functions logically and in camelCase. Sensible names that are long are preferred to short names that make no sense.
- Try to write functions to follow the principle that they should do one thing and do it well. If you can see that a function is becoming more complex, abstract it out into multiple functions – it will become more readable, reusable and will make more sense to someone unfamiliar to the code.
Performance
Performance is one of the most important features of Greenwire. We each new feature or code rewrite consider how it impacts the performance. Use tools like webpagetest.org, pingdom tools and Google page speed to test your changes impact on performance.
- Where possible javascript is loaded in the footer
- Minify and gzip where possible (Drupal)
- Lazy load images outside the viewport (PE)
- Compress and sprite images
- Minimize the number of requests.
- Avoid empty src or href
- Reduce the Number of DOM Elements