When asked for yet another new website, my mate Matthieu Larcher and I it was time to implement such an organization that we wouldn’t have to deal with development recurrent problems anymore.
Reading this article you will understand our motivations and our approach. You will also know what these problems are and what solutions we implemented. Spoiler alert: in the end, we formalized our architecture and invented a methodology we called DoCSSa.
Context
In the beginning, there was a paradoxical situation: the front-end, in spite of being close to the users, has been devalued by decision-makers for a long time. The back-end was then privileged for being more mature and responsible for very sensitive topics (i.e. authentication, data scalability, business logic, etc.).
Certainly due to the new place websites took in marketing strategies, along with better front-end languages capabilities, the requirement level was revised upwards. Now, decision-makers are paying attention to the front-end, investing time, money, research, benchmarks and study the profitability in terms of performance and cost.
Encouraged by this new deal, front-end developers are using their talent. Conferences and blogs are becoming references. Contributions on open-source projects, research, creation of new tools and languages… Front-end technology is growing.
The basis of the problem
Matthieu and I have around ten years of experience, in both front-end and back-end. The two of us are as strongly attached to methods and best practices as we are to delivering functional code itself. In that context, designing a new methodology came naturally.
CSS conflicts are a big problem. By CSS conflicts, I am referring to various forms of code misuses, which have for consequences CSS rules resetting, or CSS rules applying into places they shouldn’t. More specifically, it concerns the distribution of CSS classes in HTML elements and CSS selectors specificity.
We do not want CSS conflicts. In other words, we do not want CSS regressions while developing.
Kindergarden sandbox
Before describing our approach, I’d like us to take a look back and see what has been done so far, and why CSS conflicts still exist.
One of the first method was to write all CSS code in one file. Developers were asked to code with discipline and common sense when ordering and combining different pieces of code. In the best cases, conventions were established within teams. However, we noticed that over time, inevitably, developers ended up writing their code in the bottom of the file, hardly caring what had already been written above. It’s hard to blame the developer, as it is difficult to navigate and avoid conflicts when all team members are working on the same file, sometimes even on the same area. This is what I call the “large file kindergarden sandbox”.
Sandcastles
To avoid this mess of CSS lines, the solution naturally adopted was grouping. The idea is good in itself. Developers began to cleverly segment their code and dispatch it in separate files. The layout of a particular section of the site would be a file, an element that was repeated at different locations another file. But, another problem appeared…
Each CSS file require an HTTP request, and each request was (and still is) adding to the website loading time.
Also, this solution only works when strictly followed by all members of your team. Otherwise, it is even more difficult to pay attention to what has already been written, as everything is split up into different files.
Use the Force
Here is the situation: websites have become major players when it comes to marketing. They became richer and more complex. They follow you everywhere on your phone, your tablet, your watches… However we have seen above that behind the scene, the technical skills may not be ready for the fight.
This imbalance between responsibility and development maturity is highly problematic. Hopefully, the CSS preprocessor arrival (in 2006) has allowed us to consider an optimistic way out.
A preprocessor is a language which, once compiled, is translated into another language. In our case, we will generate the CSS writing in a more sophisticated language.
The most significant CSS preprocessor language advantages over conventional CSS are:
- variables,
- functions,
- loops,
- file imports.
Even better. The code compilation allows us to transform a whole set of files into a single CSS file. This means having a single HTTP request, which means better performance.
For more details I invite you to visit the two major CSS preprocessors websites: LESS et SASS
Inspiration
Taking a step back from the code, some developers have thought brilliant methodologies, each corresponding to a specific problem. I will not go into the details of each, but I invite you to visit their websites. BEM, OOCSS, DRY and SMACSS are sources of inspiration for us, and it is taking advantage of their best ideas that we built DoCSSa.
Show houses
Meanwhile, two former developers from Twitter proposed in 2011 their open-source project: Bootstrap.
Their goal is to provide to developers the most common page elements, delivered ready to use, requiring zero line of CSS. Bootstrap delivers a turnkey solution for your everyday HTML widget.
Bootstrap has created what so many others had tried in vain: a significant milestone in the web design evolution. However, it doesn’t solve all our CSS conflict problems, it bypasses them. Indeed, with Bootstrap, everything is fine as long as you stick to the generic defaults provided. But what happens when you want to innovate or customize? I will just say t hat it’s not going so well.
I invite you to read this article for a detailed Bootstrap review.
Megalopolis
We are now in 2014, and architecture proposals keep on popping up online. We note that the purpose and motivations are often very close to ours.
Here is what Matthieu Larcher and I set for objectives when creating DoCSSa:
- prevent CSS conflicts,
- allow for factored code without duplication,
- dissociate appearance from content,
- allow other developers to join us and be productive right away,
- establish several themes and switch easily between them,
- provide a clear idea of where we should write each bit of CSS code,
- deal with CSS3 prefixes and feature detection,
- handle responsive design integration,
- create re-usable components.
It’s with those goals that we extracted the best from our inspiring methodologies, added our own knowledge and experience, and created DoCSSa.
If you are interested in our solution, I invite you to visit our website docssa.info.
To look up the technical aspects of DoCSSa, comment, or contribute, I invite you to visit our Github repository.
Please let us know what you think!
