So Many Modules – So Much Theming?
One thing you can’t argue with when it comes to Drupal is that there sure are a lot of modules. In fact, a quick total up of Drupal modules for version 5 comes in at over twelve hundred (1200). And even if you knock off two hundred or so for instances where a module is listed in more than one category, that’s still around a thousand different modules that people might be using on their Drupal site. The point being, that each module will produce a different output which requires theming.
Now this isn’t a problem if you’re designing a theme for a specific client, because obviously that client will only want a finite amount of functionality, and will thus only be using a set number of modules – all of which they’ll tell you about (hopefully ;) ).
But what if you want to release a theme on drupal.org? How many modules should you provide theming for? And, for that matter, what’s the best way to go about creating themes which cover as wide a number of modules as possible?
The answer to the first question is ‘that depends’. A good rule of thumb is to say that you should, as a minimum requirement, be looking to create a theme which covers all of the core modules, both required and optional (a list of which can be found in the modules section of your site’s admin). But what about all the other modules?
Well, unfortunately, unless you have a lot of free time you’re not going to be able to test your theme against all of them. And even if you could somehow manage this, new modules, and updates to existing modules, are being released all the time. All of which means new output, and new things for you to theme.
So, a good idea when designing Drupal themes is to start big. Start by creating code which is as wide reaching as possible. This is because the more general the code is the less it will matter which modules are used, as the code should cover the output from all of them. For instance, the first rule on all of my stylesheets is
* {
margin: 0;
padding: 0;
}which, because it uses the universal selector ‘*’, will effect everything.
The next rule is generally something like
body {
font: 1em Verdana, Arial, Helvetica, sans-serif;
}Again, this is a general rule which makes all fonts have a size of 1em (an explanation of which can be found in this post). So, no matter which module is now used, the font size will always be 1em.
This approach is also beneficial because it should help you to create stylesheets which are as clean and efficient as possible, and make it easy to apply any future modifications. The reason being, that the less specific rules you apply, the less rules you will have and the easier it will be to make a complete change to something.
Bookmark/Search this post with:
Hi, I'm Laurence and this is my Drupal blog.
Don't Make Me Think!
Pro Drupal Development
PHP Cookbook
Will You Please Be Quiet, Please?
Up until yesterday I wouldn't have given much thought to your choice to zero out the padding and margins--but then I read a couple of posts on Eric Meyer's blog about why this is a bad thing to do. The short version is that using the universal selector as you have suggested does indeed reset the padding and margins for *everything*--including form elements. Meyer explains here (http://meyerweb.com/eric/thoughts/2007/05/15/) why that's a bad idea. In a related post, he also explains--and documents--those elements he does reset: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/. It's worth reading through the post and comments to see how he handles it as well as his rationale.
Hi Dan, thanks for the links.
I would definitely agree with you that Eric Meyer's views on the whole resetting CSS issue are something that people should take the time to read through and understand, and I would also agree that the universal selector option is not perfect (although to be fair I never said it was ;). However, I think it's important to say that Eric Meyer's reset solution isn't perfect either.
If anyone wants to get into this subject I would suggest they start with Eric's post on Meyerweb entitled Reset Reasoning, where he first explains why he feels the need to implement a specific set of reset rules.
Laurence--glad you included the link to the initial post by Meyer--should have done that myself.
The big idea that I take away from Meyer's discussion of the reset rules is that beyond creating a baseline for all browsers, resetting the rules forces him to think about every element of the page and why he is styling it as he does. To put it another way, the reset encourages intentional design choices, and I think that's a good thing.
You noted in your post on stripping down the page template file to its skeleton (I think that's the one) that it's good to understand how the various elements work together up front and to solve design problems up front, rather than implementing code and then hoping you can figure out where the kinks and quirks are coming from. Another benefit of some sort of reset rules is that it helps with the problem solving.
Finally, Meyer himself notes that his rules are his--how he would create a baseline for his designs, and he encourages his readers to create their own--and to know why they are making the choices they make.
Post new comment