In an attempt to follow the ‘mobile first’ ethos, reducing the amount of loaded assets on smaller devices is high on the priority list.

Using media queries we can effectively control the loading of things like background images, but what about the CSS itself? After all, it seems wasteful to load CSS specifically for desktops when viewing a site on a mobile device.

A common misconception of media queries is that a device only downloads the CSS of a matched query (when using the query in the media attribute of a link element).

This is not the case.

All CSS files are downloaded regardless, though the CSS is not applied until you match the requirements of said query.

I feel like I’m being slightly cheated. In an ideal world I’d like the CSS to only be downloaded when they are needed, based upon matching the requirement of the media query. So how can I watch my http requests and keep my slimming mobile figure?

JavaScript to the rescue, or JavaScript polyfill time.

We could easily use a bit of JavaScript to achieve this, the fine fellows over at the BBC use the following on their blog:

<script type="text/javascript">/*<![CDATA[*/
 (function(){
  var importStatement = "";
  switch (true){
   case ($dc.screenWidth > 639):
    importStatement = '@import url("http://some.tablet.css") screen and (min-width: 640px);' + importStatement;
   default:
   importStatement = '@import url("http://some.compact.css") screen and (max-width: 639px);' + importStatement;
   break;
 }
 document.write('<style type="text/css">'+importStatement+'</style>');
 })();
/*]]>*/</script>

If you are willing to travel the JavaScript route then something like this works fine. However, when you add a content management system on top of this it gets more complicated.

Dealing with Drupal

Our previous example was very basic, aren’t all examples?! When we consider taking this approach in Drupal we come across a few hurdles.

Drupal’s CSS optimisation aggregates and compress theme, core and contrib CSS together into a greatly reduced number of files. This is great, not least because there seems to be a huge amount of core and contrib CSS in Drupal.

But as soon as we do this we loose the ability to control our CSS for different devices with a little more finesse.

A module in the making?

Ideally there would be a module which would do the following:

• Show a list of all CSS which is put out by the system, theme, core and contrib, preferably with a description as to its purpose.

Do you know where/what all of the CSS Drupal spits out is? Probably not. I’ve never sat down and gone through all of these files and figured out exactly what they do, and indeed if I really want them. On more than one occasion I’ve found myself writing CSS to override stuff from them. This shouldn’t be the case.

• Allow selection/deselection of said CSS, removing what you don’t want.

An ability I’ve always longed for, yet it’s never been that important to warrant the time to actually figure out how to do properly (it’s generally been quicker to just override it in the theme). But, this is the ultimate, complete control on what styles are used.

Traditionally you’d simply override an unwanted style sheet in the theme info file by using an empty declaration with the same name. In some themes, most notably Omega, this feature is now offered as a theme setting. It allows you to switch off core and theme CSS.

• Specify groups which are separately optimised.

Having Drupal optimise our CSS is a good thing, but as stated, it kind of walks all over our plans to deliver style sheets as needed rather than the whole lot together. Having the ability to set specific groups would be great. I could then lump all core/contrib stuff together and then have the needed separate—compressed—files for my ultimate goal!

I hereby name this module CSS Admin.

Pragmatically thinking

We’ve specified a useful CSS administration module there, and so in a modular mind set the features left to finish our solution should probably be rolled into another module which is just dependant on CSS Admin.

We need the ability to:

• Write some JavaScript into the head of the document that tests the screen width (or other variables) and then loads an appropriate CSS file.

Perhaps we could call this CSS Admin – Media Query Loader.

That’s it. Simple!

Glory awaits

Perhaps deferring the loading of CSS files is getting too picky, but I’d don’t think so. Granted, I’m probably missing a few angles of reasoning from this, but I think the core message is sound—we should be doing everything to honour the mobile first ethos by asking these kinds of questions and seeking out their solutions.

I’ve no doubt creating those modules is possible, I’ve worked with some excellent Drupal developers and I’m sure there are plenty more out there. With any luck we might get to look at this during this project and I’ll be able to follow up with a solution post, but for now I’ll make do with seeding the thought amongst you all.

Knowing my luck, in true Drupal fashion, a module already exists for that! I hope it does, but I’ve yet to come across it.