There are few interfaces that are as necessarily dense and complex as a modern betting application. InPlay Match Live views, Partial Cash Out interfaces and the bet slip itself each contain a significant number of user interface components.
Historically, maintaining the many styles for our application has always been problematic. This simplicity and forgiving nature of CSS means it’s easy to write and keep on writing it – even though, months and years down the line, half the styles may no longer apply! As such, style sheet authors working on new product features could never feel entirely confident knowing what CSS was still needed, what the scope of each rule was (due to CSS’s inherent global nature) and which sections of the existing code could be entirely deprecated. We had already wrestled back control of JavaScript authoring by adopting and maintaining standards around TypeScript. Now it was the turn of CSS.
Therefore, at the beginning of 2015 we were looking to improve the manner in which we wrote and ‘architected’ CSS for mobile.bet365.com.
Tackling the issue
We had two major issues; insufficient tooling and the lack of a consistent methodology for how we actually wrote our styles.
We had a CSS authoring methodology that suited our needs. A methodology that had been prototyped for some months in a small team. However, when it came to opening the flood gates to many developers authoring in that manner, we needed some tooling to both facilitate and enforce what we wanted to achieve with this methodology.
Tools
At the time Sass was the de-facto standard for CSS pre-processors. It works as a super-set of CSS, enabling variables for oft-used colours and sizing, ‘mixins’ (think of them as equivalent to helper functions in JavaScript or macros in Excel) as well as logic such as loops. Historically, Sass had a dependency on the Ruby language, which wasn’t a language we otherwise needed. The newer libSass, a C/C++ port of the Ruby engine, removed that dependency so Sass (via libSass) seemed like the natural choice. However, we decided to buck the conventional wisdom; after all, it’s the ‘bet365 Way‘!
PostCSS
PostCSS is a tool for transforming styles with JavaScript. In early 2015, PostCSS was a relative newcomer in development circles and subsequently few people were using it in the wild. However, it piqued our interest. Where Sass was an existing and predictable ‘Turing complete’ language that had well defined limits, conventions and releases, PostCSS was something of a rebel.
However, with PostCSS we recognised we could effectively do anything we wanted. Existing plugins could provide all the parts of Sass we wanted, and crucially enable us to opt out of the parts we didn’t. We were equally free to create plugins to perform any additional task as needed. So, while Sass failed to provide the ability to glob files, it was a one-liner for PostCSS (we were in-turn consuming PostCSS via a custom Gulp build).
Here are some more highlights of adopting the PostCSS ecosystem:
Dealing with vendor prefixes
The most well-known plugin for PostCSS is Autoprefixer. This enables style authors to forget about vendor prefixes in their style sheets. A configuration defines the browser versions it’s necessary to support and relevant prefixes get added auto-magically. No more ‘-webkit-‘ prefixes in the authoring styles!
Modular CSS minifier
PostCSS also allowed us to switch to a new modular minifier. Unlike other minifiers that perform wholesale changes, this modular minifier enabled us to make nano adjustments to produce the smallest possible file size. In our last post we talked about site performance and this was just one more area we were able to make performance improvements thanks to choosing PostCSS.
W3C standards today
While adopting variables in our style sheets allowed us to rationalise our colour palettes, occasionally we wanted to perform a transform on one of those variable values. Although still draft status at the W3C, thanks to PostCSS we are able to use the CSS color() function today. The tooling transpiles a statement like ‘color: color($color-grey-54 a(.5))’ in the CSS to a simpler rgba value that can be consumed by all browsers.
CSS methodology
While there are a number of existing CSS methodologies (SMACSS, BEM, OOCSS) that had been used to varying degrees of success in bet365, none facilitated our exact needs. Instead we adopted for ‘Enduring CSS‘, an approach that was specifically designed to cater for all our edge cases.
This approach bucks conventional CSS authoring wisdom, favouring isolation over abstraction and ultimately allows more predictable and targeted style sheet authoring – plus a far simpler means of deprecating old code.
Developers are only human though, and despite documentation and training on ECSS, it wasn’t long before our new established standards were slipping. Instead of selectors like ‘.ns-Component_ChildNode’ in our codebase we were seeing ‘.NS-componentName-Child-node’ and every variation you can imagine. To the untrained eye, the placement of underscores, hyphens and appropriate casing in a CSS selector/HTML class may seem academic but it’s indicative of a lack of uniformity throughout the codebase. Something we were working hard to eradicate.
Thankfully, at this point, the decision to choose PostCSS paid us back tenfold.
Linting
Stylelint was, at that point, a purely PostCSS based ‘linter’. Linting, for the uninitiated, is a term given to a means of statically analysing code and providing instant feedback. What the means in layman’s terms is that we were able to author specific JavaScript plugins to parse the CSS in real-time and flag up any non-conformity against our standards.
So as a developer authors styles, any problems are fed back instantly in either their code editor (as an aside, one of our cone-headed developers even wrote a plugin to provide Stylelint feedback in Sublime Text), command line tool or both. Nobody needs to wait for a peer review or code QA session to find out they did something wrong – Stylelint does it for us. To exemplify, if an author uses an incorrect selector syntax, nests a selector unnecessarily or uses the wrong module name in the wrong file, they get feedback immediately.
Furthermore, as Stylelint is extensible (again via JavaScript) we can continue to hone our rule set and provide additional developer ergonomics for our style sheet authors.
Forward
While we can’t eradicate all CSS authoring issues, our tooling and methodology choices have enabled us to make significant improvements to our current and in-development code. The result is that it’s now a better time than ever to be writing CSS at bet365.com.