Over the years, the process of theming Drupal sites has improved drastically. However, one issue that remains a constant pain point in the community is dealing with core and module CSS. I think we all agree that it’s broken, but there are two completely opposite views on how to go about fixing this problem. There are those that want to get rid of it altogether, and those that want to fix it at the source. What’s important is that we have a chance to fix things. We just need to get involved and share our ideas.
I’m firmly in the “fix it” camp, and I’m going to take this opportunity to explain why, and also share what I think can be done about the situation. If you don’t care, or already know my story, feel free to skip to the fix it part.
The Evolution of This Drupal Themer
When I first started theming Drupal sites about 4 years ago it was hard. Template files were few and far between, preprocess functions didn’t exist, and figuring out how to override views felt like trying to study rocket science. I would google for days at a time, praying for some decent information to help me accomplish the task at hand. This was always a crap shoot, because back then documentation was scarce and when you did find documentation it was either very developer-centric or complete and utter crap. I was fairly new to PHP, so at times it was frustrating to say the least, but I knew Drupal was going places and I was determined to learn. I spent time lurking in IRC, read blog posts from Drupal developers, and usually after some trial and error, I was able to figure out how to get most of what I needed done.
When I started working for Gravitek back in 2007, things changed for the better. I’m lucky enough to work with talented developers, that were happy to help explain things, and never made me feel stupid. They encouraged me. They also told me when I was “doing it wrong.” At times, I found this annoying. Seriously, what difference did it make what editor I used? And why on earth did I need to use the command line to do my job? But hey, they were able to do some amazing things with Drupal with ease, things that I still consider amazing to this day, so I listened. I’m glad I did because it made me a better coder.
Since I was mostly able to bend Drupal to my will, of course the natural thing to do was to rip things apart and fix it. It was like a reflex. The code was bad and I could do much better, right? I started by rewriting markup to a really minimalist state. This naturally led to the removal of many core stylesheets because, of course, I didn’t need them anymore. My markup was clean and, at the time, I was satisfied.
Throughout the development process, the usual things would occur. New functionality was added, which often meant new modules, blocks, views, fields, etc. A lot of the time, the modules would add CSS that was based on some pre-existing CSS, code that I had removed. I spent a lot of time removing and re-writing that CSS to fit my use case. I never once posted a patch to try and fix things for everyone. I didn’t even know what a patch was.
Damage Control and Denial
Before I knew it, template.php was a mile long, with many theme function overrides and crazy logic. I had stripped things down to a minimum, not taking into account that every implementation just wasn’t going to be that simple, and I constantly had to rethink my logic to regain the granularity I had initially.
It was clearly inefficient, and had negative implications for myself and client. My code served one highly customized purpose at a time. I was reacting to every change that came up and upgrades at the module and core level were pure hell. This meant that I ended up doing tons of damage control, which I didn’t enjoy. I enjoyed bringing mockups to life and making clients happy. I quickly realized I was “doing it wrong” and knew there had to be a better way.
For the most part, I’ve managed to overcome and these challenges. Realizing that Drupal is not WordPress, that things aren’t always going to be simple, and learning to embrace that was a big part of it. Most importantly, I’ve learned that working with the system is better than working against it.
These days I start with markup that I think provides a good structure and
will work for the majority of content on the site. Usually, this means a
couple of extra
<div> tags and my block.tpl.php and
panels-pane.tpl.php files end up very similar, or identical in structure. In
general, I try not to pay attention to what Drupal object is containing the
content and instead concentrate on the content itself.
I try to avoid creating template file overrides, unless I have good reason. I aim to keep as much logic as possible in preprocess functions, and just print variables in template files. I also keep a close eye on my preprocess functions, and when it can be done better in a module, I try to do it. A good rule of thumb to help determine this, is that when something ends up being too much of a challenge to accomplish in the theme layer, it probably belongs in a module. Lullabot’s Drupal Module Development Workshop helped me feel more comfortable easing into this. I don’t always succeed, but I try, and I always learn something. I am not afraid of PHP, and I don’t think front-end developers should be. PHP is your friend.
I don’t mess with menu theming anymore. It is an epic waste of time. I just use the Menu block module, which is third in line to CCK and Views on the list of modules I cannot live without. BTW, Panels is next in line. I’ve heard some high profile Drupal developers claim that Panels is for people who don’t know how theme. I think that is absurd. It’s like saying the CSS frameworks are for people who don’t know how to code layouts.
While I’m on the subject of layouts, lately I’ve been using the
960 Grid System. I prefer to start theming with a
very simple base that consists of the
ns() function from the
NineSixty theme and
preprocess functions that combine class and id attributes into one variable
for template files, as Canvas does in the
Studio theme. I also tend to
recycle code on a much smaller basis, which is where
Skinr comes in handy.
I try not to sweat the small stuff. For example, I believe that the default markup Views provides is good, especially with the help of Semantic Views. I know many disagree with this, but I have yet to see a better version proposed. Sure there are ways it can be improved, but overall, I think it’s a non-issue and frankly I am baffled by the backlash it receives by this community. I mean seriously, what other module gives you that many options to change things, and literally guides you through the process (if you are willing to look, before lashing out)?
This has all been working well for me. However, there is one area that literally needs the help of an army to overcome. That area is CSS.
CSS in Drupal is Broken
Some of the problems and challenges we face:
- Lots of CSS is located in the wrong file. system.css is literally a garbage pail that exists for when developers don’t know where to put something. Work was done by mverbaar and I to improve this for Drupal 7, but it was quickly (unintentionally) messed up again.
- Other CSS has no business being there. Completely unnecessary margins, padding, font-family, color and other similar declarations are scattered all over the place.
- In Drupal 7, there’s a great deal of code in modules that is designed for the Seven theme. This is wrong and it makes me crazy.
- There’s lots of outdated code, that was never commented, which ultimately needs review and removal.
- Some of the markup is so horrendous, it causes equally horrendous CSS.
- Drupal 7 introduces quite a few brand spanking new modules, that didn’t get refined in contrib and contain some of the most specific selectors I have ever seen.
- Outside of core, we need to educate module developers to provide what we expect, and give them an easy means of implementation.
Why Getting Rid of it All is Wrong
I understand that many want to see raw HTML, and don’t want to deal with any existing CSS. Believe me, I get it. I also think it is a natural reaction, but having already tried this myself this is why I feel it’s wrong:
Much of Drupal’s strength can be attributed to its modularity. The current state of CSS files in Drupal is modular (even though that needs improvement), but the CSS styles themselves are not. This is where it breaks down, and needs to be fixed – not tossed.
Duplication needs to be avoided
There are things you will want to keep. I’ll be damned if I am going to re-write things like the CSS for the Toolbar, Overlay and Contextual Links in any theme, whether it’s a base theme or not. This is not sustainable, modular or effective. It only creates the opportunity for duplicate code all over the place, which translates to additional maintenance and ultimately damage control.
UX and accessibility compliance efforts must continue to be supported
There is a lot of effort going into achieving these goals, and CSS is often a big part of it. We can’t just give up and ignore those efforts.
Having a solid base (code, not a base theme) would benefit us all
If we all have a good base to start with, I honestly believe that we would be bothered by core CSS much less, and hopefully someday, not at all. Instead of repeatedly battling bad CSS, we can move and focus on bigger, better things, like contributing kick-ass themes and code snippets to help others get started.
Changing Strategy: A Proposal
The issues we face are not small, by any means, but I think we can do it, and I think we should start working on it now. Here’s how we can start:
Reevaluate Existing CSS
- Do a round of cleanup in system.css, and ensure code is in the appropriate CSS file.
- Remove code, and possibly entire files, that clearly do not belong, e.g. border, color, font-family, margins, paddings, etc.
- Keep CSS that provides helpful visual cues, and accessibility compliance, such as system messages, progress bars, etc.
- Completely separate admin styles into separate files, i.e. use block.admin.css instead of block.css, when the purpose of the file is purely administrative.
Get Serious About Goals and Organization
A few of us have been discussing ways to overhaul the way we do things in Drupal 8. There hasn’t been that much discussion yet, because unfortunately the idea came up too late in the Drupal 7 development cycle, but the ideas are really good, and IMO open up a world of possibilities. The best part is that we can start implementing them now.
- Make the separation of structural/behavioral styles from design related styles standard practice.
- Give modules the ability to include a generic design implementation with their module, as well as the ability to target specific themes.
Here’s what it might look like, using the vertical tabs module as an example:
|vertical-tabs.css||Holds structural and behavior related styling. CSS should be coded against the Stark theme. The absolute bare minimum CSS required for the module to function should go here. If there is no CSS required, this file should be omitted.|
|vertical-tabs.theme.css||Generic design-related styles that could be used with Stark and other themes would go in this file. It’s where all design assumptions like backgrounds, borders, colors, fonts, margins, padding, etc, would go.|
|vertical-tabs.bartik.css||Design-related styles specific to the Bartik theme.|
What This Could Mean for Themes
It also means that we can try give voodoo magical powers to drupal_get_css() in Drupal 8, to autoload the ones we need/want. When creating a custom theme you automatically wouldn’t get any of the CSS meant for other themes, and there could be a simply theme setting to wipe out all the generic .theme.css implementations as well.
If you have an opinion on this, want to see more about how it would actually work, or think you can help, please chime in.
Hey, Front-end Developers: ♥ Drupal needs you. ♥
As far as I can tell, quality CSS has never been much of a priority in terms of code or strategy in Drupal core. This is not surprising to me, even though the standards for everything else are so high, because there is a serious lack of designers and front-end developers participating in core development. The situation is slowly improving, largely because of long-time efforts by awesome, enthusiastic members of the Design for Drupal community. However, it’s still a big problem. We have attracted more front-end types to Drupal, but we need more, and we need them involved in core development, where they are sorely needed.
Contributing to Core
Earlier this year, I was asked to volunteer to be a markup co-maintainer for Drupal 7. I was hesitant to take this role on for a few of reasons, but mostly because I worried that I would not be able to convince front-end developers to help, since many are either intimidated by the issue queue in general, or think the situation is totally beyond repair.
Although I was hesitant, I really wanted to start fixing things. I had already gotten quite a few patches in, which was a lot easier than I thought it would be and it felt great. With a little encouragement from Dries and webchick, along with some guidance and tough love from Sun, I was sold. It hasn’t been easy to find the time, and there is so much to do, but it is extremely rewarding, and I am completely confident that if we all come together we can fix these problems.
An Opportunity to do Really Rewarding Work
I really hope all of you rock star Drupal front-end developers reading this will take the leap into the issue queue and help us solve some of these issues. I know you guys are all out there lurking. You don’t have to work on this specific issue, there’s plenty of geeky work to go around.