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.
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.
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.
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.
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.
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.