Overhauling the CSS in Drupal 8 Bartik

As the most recent Drupal 8 update suggests, work continues on the D8 betas: both on headline beta-upgrade blockers, and also on more subtle improvements that are no less important for making D8 not just a shippable product, but one we can all be proud to use in our day-to-day work.

One of those subtle parallel tracks gets its own mention this time round: cleaning up the CSS for Bartik's layout component. But this is part of an even bigger informal initiative, to overhaul and standardize Bartik's CSS in its entirety. This has been pushed forward by emma.maria, idebr, LewisNyman and others, without noticeably detracting attention from critical backend fixes required for full release. It's definitely bringing Bartik up to date with established best practices both in Drupal and in the wider world of web development.

Here are a few reasons why CSS standardization is more important than you might think:

  1. Forking core themes is how people get started. My first forays into Drupal 5 were certainly based on a fork of Garland, which helped me to understand how bits and pieces worked and fitted together. Lots of people begin that way, so by starting off with standardized code we make it more likely they'll follow those standards at least to a certain extent, and therefore be happier working with Drupal in the future.
  2. All of Drupal will be judged by potential adopters. When people evaluate Drupal, they won't just open the very best PHP files. They're going to look at how core contributors have structured CSS and Javascript too; maybe even more so, because only a minority of potential adopters will be adept at backend programming. Good CSS presents a professional face to what might be Drupal's next contributor, community member or just plain user.
  3. Standardized CSS will be easier to maintain later. Bugs can occur in CSS, just as in any other part of Drupal. While they won't usually have the same impact as e.g. cross-site scripting, they can still demand a fix in a later point release. If we've overhauled the CSS already, then fixes should be a lot easier to spot, implement and test. The flip side of not wanting to change the CSS when so many sites rely on the visuals is that we need to get our overhauling in now, not after launch.

Ultimately, what the Bartik Overhaul represents is appreciating that CSS is a language like any other (albeit with its own quirks); as sucha language, CSS deserves developer attention. With any luck the improvements that the Bartik Overhaul team are making now will still be helping developers for years after launch!

 (Full disclosure: I'm helping them out a bit too!)