OnVista CSS

This article has been published in English to reach a greater audience. It covers a topic that every web developer should be concerned about. So I chose English to target everyone in the business. Let me know what you think about it in the comments below the article.

Inspired by the latest articles about CSS architecture (from Mark Dotto, Ian Feather and Chris Coyer)
I decided to come up with my own one.
I think a lot more developers should do that, to learn from each other.

OnVista is a website which targets the German speaking user who is interested into financials.
We’re currently one of the most visited german financial websites.
Right now we are facing the fact, we serve some pages in a new layout
and some (well most of them) still in the old layout and old backend architechture.
Don’t ask for the reason. This is quite challenging for optimising the CSS architecture.
So here’s what we do now to cope with the given situation.

Quick facts
– We use SASS as our preprocessor
– We have about 60 partials which are compiled to (currently) four CSS files in
production (weighing about 290kb, 58kb gzipped)
– We compile them into two main files for our focused new layout because of the 4096 selector thing in IE<10 - The other two are used for elements used in both worlds (prefixed with "global_") - we used to write styles very specifically, mainly on tag base (not the best idea, because we nowadays need to reset a lot of styles) - we're trying to get the switch from tag based to a kind of BEM, OOCSS approach. That said we aim for classes over tags - pixels are the unit of choice Preprocessor
We are relying on SASS.
It gives you anything you need right now and it’s doing its job server-side.
Nesting can help a lot, when it comes to style a certain box.
But we try to keep the nesting level to a minimum. Never more than 3 levels is a rule of thumb.
Gradients, animations, cropping text via ellipsis and things like that are mixins we can use
everywhere needed.

We learned from mistakes we made in the past.
As mentioned before we were starting to lean to a more BEM, OOCSS approach.
It is absolutely nessesary to get away from selectors like .foo .bar .baz ~ .item-one > span:first-child
That means we’re trying to rely on base classes used with modifiers (if needed) to create a standard button with the class „button“.
Modifiers would determine the color or the size. Just by applying the classes „button-primary“ and „button-small“.
Despite being a german speaking company we started to use english class names.
Variables are heavily used for colors, margins, font-sizes etc.

Yes, we’re using a CSSlint Jenkins step.
But it is very basic and just checks if the css is valid and if the count of selectors isn’t larger than 4096.
There is room for improvement here.
Think of how often are font-sizes set or floats or widths, etc.

Actually we’re using two fonts.
The first one is our corporate identity font, the second one is a customized icomoon font.
They are implemented in a _webfont.scss which is imported by the main css file.

Most of the icons are SVGs in a special folder.
A grunt task (written by the gorgeous filamentgroup) packs them together and even delivers a png fallback.

Remember the time you handcrafted sprites in photoshop?
Get over it. Most of it could be achieved automatically.
grunt-spritesmith can help. Just place your single files in a folder and let grunt do the work.
Run grunt-imgcompress to gain smaller file sizes.

Also a grunt task we set up the other day.
Styles are annotated as a comment and grunt-stylguide generates a browsable living styleguide.
So every single backend/frontend developer or designer is able to look up which element can be used in
On the other hand it can ring a bell if you’re duplicating things (i.e. 50 shades of gray).

Are we done yet?
Hell no. There is a lot to do.
Linting must be improved to raise the quality of the css (i.e. number of importants, nesting level, etc.).
Spites must be improved to reduce the manual positioning of items.

2 Kommentare