css file naming now in glorious batman style

The way Drupal have been handling css styles up until recently have been to say it nice "Problematic" Theres been a lot of unessasey barries for new & experienced frontend developers alike, fiddeling with the css files can even caused functionality to break.
Now in D7 theres a hidden gem in the very core that needs to some spotlight on it: the filenaming rules of drupals css files.
Hopefully this post can help module developers & Themers alike understand the beauty of the new css naming rules, and why its so importent to follow these, now and in the future. But first a run down of what the problems actually are both for the frontend & backend Developer, and why this change is extremely importent for the future of Drupal.

css in Drupal is simply wrong

Drupal core & the contrip modules have a habbit of always including at least one css file to define the styles used by the module so it can
* make fancy javascript thingies (ajax, accordians, sliders etc)
* fix the layout for the administration of the module
* fix the layout for the theme (we need more float left & right style definitions)
* add some design styles like colors, margin, padding, fonts or borders, just as good defaults for the theme
All of this so it works outta the box.

Lets not to forget a favorite re defining a couple of common classname like

foo module's foo.css

Now when drupal spits out the final page theres a good amount of css files & styles (Drupal alone comes with XXXX out of the box & then add the contrip modules css files) Chances are that the theme will probably have to overwrite, reset and at least take into consideration all these styles, that drupal is pushing out to the frontend.
This has been a HUGE irritation problem for us who define ourself as frontend developers in drupal for years, and there is actually reasons for that:

separation of logic & presentation

There isnt any file system or namescheme that can tells us if the .foomodulestuff style is essential or not to the modules functionality. This makes its actually easy to destroy modules functionality - if youre a bit to aggressive with the resets, or overwrites the wrong styles.

IE file limitations

The number of css files made IE choke because of its limitations of css files that can be added, so the styling for ie was a complete mess untill "rule35" was effected.
The new release of IE 10, the css file limitation is removed, so this isnt a problem for anyone that uses ie10 (which just leaves us with the ie7, ie8 & ie9 users)
This is offcouse not a problem when the css files are compressed in a live site, but its a "small" annoince in the development of the site (not to mention that we at the same time have to battle ie6 drunk cousin ie7)

Overload

Its really easy to get lost in the amount of styles that a drupal site is carring around, when every module has its own classes + Drupal carries its own good amount of stuff.
and lets not forget the css cascade that can end up beeing so complicated that it can be tempting just to use !importent to whatever you need.

If you think you can just drop a style.css into the theme & then expect it to look the way that its defined in style.css, then you havent worked with Drupal -or you just dont give a rats ass about pixel perfect implementations (and then you probably dont care about having 500 unused styles defined) your gonna use countless hours to reset, overwrite & beat drupal into what you might consider best practice, lets be honest drupal is not actually known for a clean mean styles & markup (much of it based on the fact that Drupal7 still supports IE6)

Take the power back

The way to get the control over Drupals styles is normally one of these 4 methodes:

Revove all $styles

Remove "print $styles;" from html.tpl (was page.tpl in d6)
This will remove every css file that drupal even dreamt about , the problem here is that we also remove the administration elements wont work, jQuery sweetnes wont work etc. To make the site work you need to find the css classes thats needed and add them ind by hand - This is generally a very bad idea & will only cause you problems down the road, new modules thats installed wont work etc. but you got complete control ;)

foad style .info css overwrites

In the themes .info file you can easy exclude a css file just by defining it in css with the same filename as the file you wanna remove.
So lets say you wanna kill off foomodules pesky foomodule.css apparently it adds pink dotted lines around you divs & makes you cry & you basically dont wanna deal with it.

** THEMENAME.info **

Now Drupal is tricked into beliving that we have a css files in foad/foomodule.css define in the theme, so it includes that file in the $css list - it dosnt exist so woho its now dead & gone :)
The reason i use the foad as a fake folder is to remember that this file myst Fuck Off And Die.

You should remember though to be carefull what you call the css files in you theme, naming accedentially a file views.css have gotten me into trouble a couple of times. (views-style.css is a much safer name)

Stylestripper module

The stylestripper module to remove all the css files you dont wanna include in a theme. The problem here is that you have to do alot of configuration each time you create a new theme
Guess that features & strongarm can probably do that + havent tried yet in D7.

Overwrite styles as needed.

Offcourse we have the simpel & classic way to clean out is to overwrite & zeroing out the styles thats defined by drupal, and you dont need. Just overwrite all style that drupal spits out, and then you done
This results here is a pretty huge css file thats only job is to zeroing out styles thats been defined & the theme dosnt need.
and you gonna have to fiddel with that file everytime theres new modules added to the site.

These 4 methodes always leaves us down to the simple question:

Why does Drupal add stuff that i dont need, or asked for - thats dumb

(insert you own profanity here)

lets compare this to a database query:

If youre a developer that dont really like to work out in the frontend, let me try to give you an example of how drupals style implementation looks & feels like:
I need the title field from footable so i could do a simple and quick "SELECT title FROM footable" as my database query. - now instead of that just to be sure that i have everything, in case i might one day need it, i better also select the date, the author, the body, its grandmother and what ever i might can find... aaah lets just grap it all
"SELECT * FROM footable"
ah now we have whats needed & offcourse whatever else that might gonna be added to the footable forever.

I can here developers all over the world screaming right now - why oooh why do you wanna select all fields in the table if you only- you are using unessasry resources & it takes longer time to get the data yadi yadi
Well this is how the style css file hell that drupal gives us today feels & its plain wrong.
Everything, including the kitchen sink and its mother are added into the css & spoonfed down the throat of the theme - the frontend development now have to paddel through the ton of styles defined from a ton modules that all are throwing in their idea of what should be in styles... argh (sorry for ranting).

Best of both worlds!

So what that we really need is something like this:

• must be ready to go outta the box.
  The reason that Modules comes with all the style defined is that it should be usuable when you install it - it dosnt make sense that the theme must write custom css everytime. Sensible defaults would be nice.
• We dont wanna have unused styles & have to work with a ton of overwrites. It makes the page load slower & makes it weight more
  It makes styling sites a pain & really dosnt make sense to have a remove when nessesary, when we really wanna have an add when nessesary aproach.
• Modules needs to be able to tell the themes what they should not mess with, so a theme dont accedentially ends up destroing functionality, by overwriting a style or a css file.

Seperation of css logic

Now in Drupal7 all this is taken into consideration, at least if you look at the system module in core (drupal/modules/system/) it is (I danced with joy when i figured this out)
So Lets look at the css files that system is packing

Look there is no system.css file!
Instead all the files have added a description to them after the module name (.base, admin, theme, maintenance, menuse etc)
That actually means that we now can make themes that dont have the problems that I described earlier.

The module is splitting up the normal modulename.css file into 3 different files:

• modulename.base.css (system.base.css)
  .base.css file is having all the essential style definitions that we needs to make sure the module is working,
• modulename.admin.css (system.admin.css)
  heres the styles that we need for the adminstration of the module & finally we have the
• modulename.theme.css (system.theme.css)
  Gives us good defaults for the module.

Holy crap B.A.T.man does this mean that if we remove all the [modulename].theme.css from my themes css files, i dont have to overwrite it & dont screw with the administration interface or the modules functionality?

-drummroll-

YES!

something like this in your template.php will do the trick

uuuh gimme gimme

Unfortunately all of Drupal core is not working this way (yet), I hope that we can get all logic in the core styles seperated asap and theres a ton contrip modules to get up to speed, with the way of the system module.

I have started the work of seperating the core css files into the B.A.T. (base, admin, theme) namescheme in the worlds best theme that "fixes evertyhing thats wrong in drupal (tm)": Mothership.

In the mothership, theres also n controller to quickly cleanout the .theme / .base files etc - very handy to remove some of all the clutter. Steal it use it & make it better please :)

If youre a module developer you should really think about splitting up you modules css into BAT css files. The fact that its the right way to do it, system module does it, you will never again have to curse a theme for accedentially removed a style that was essential to your module.
Dont forget there will not be hordes of angry frontend developers in your issuque going "wtf why are ya not following the Guidelines" ;)

I hope this post have put some light on the problems we currently have in an essential part of Drupal frontend development, theres a simple, clean & easy way to fix this problem.

So please wont you be the Module to my Theme?