jacine

Let's Do Something About Drupal's Theme System

Tue, 20 Mar 2012 20:16:16 -0400

It’s a mess. Yeah, I said it. It’s time to admit there is a problem and get serious about fixing it. In this post, I’m going to explain what I think the problems are, and how I’d like to see them fixed.

During the last year, I’ve spent a lot of time working on the HTML5 Initiative. There has been an incredible amount of work done, by a truly awesome, and growing team. We’ve gotten a whole lot done so far. The HTML5 Shiv has been added to core, the major templates are all done, and work on Form API elements is moving along. We’re also doing CSS re-factors, at minimum separating administrative styles from the rest.

Still, I’ve found myself very unhappy with the theme layer. I see a lot of work going into WSCCI and now the Layout Initiative that is really exciting. What I don’t see is if and how that will actually affect the theme system we work with today. This has been really discouraging for me, mostly because I’d like to see a lot more than just markup changes.

I’ve also become skeptical as to whether or not improvements for PHP developers automatically translate into front end improvements. I feel that we got burned with the implementation of Render API. I don’t think this was intentional or anything, just sort of the way things are. I believe the problems that it attempts to solve are hard and the way it goes about it is good, but it was implemented so inconsistently that it ended up making things harder. Many are unwilling to even give it a chance. Without consistent patterns to rely on, many of us are lost. Had the entirety of Drupal’s code base been converted to use the Render API, maybe it would have been different.

We are Doing it Wrong

When I complain about the theme system, I’m often surprised by some of the reactions I get. Many developers know there is a problem, but some seem completely unaware of the problems we face, and the things (which they would consider hacks) we have to do to get the job done. So, in no particular order here is what I think is wrong:

Too Many Templates and Theme Functions

Creating a new template was the answer for everything in both Drupal 6 and 7. It has been done carelessly, over and over again, and encouraged as The Drupal Way. As a result, we have hundreds of them. This is just plain ridiculous, considering there are only 109 HTML tags, most of them are used in groups and many of them are text-level elements that wouldn’t exist in Drupal’s theme system. We’d never have theme functions or templates for , , , , , , etc. At least I hope not.

Lack of Consistency

There is hardly any consistency in what we’re doing inside templates and theme functions. Templates are a mess of arrays, strings, render arrays, and random theme settings variables. Look no further than page.tpl.php, which is the first impression newbies get with Drupal. In order to change a given variable in page.tpl.php, you need to first track down how it was generated and then figure out the appropriate function that will allow you to change it, which could be one of SO MANY different things:

THEME_preprocess_page()
THEME_process_page() if that doesn’t work or you’re looking for something that happens late.
Theme settings tweaks in the .info file, and the UI, along with one of the above.
THEME_menu_local_tasks_alter() if you want to modify contents of tabs or action links.
THEME_menu_local_tasks() if you want to modify the markup of the tabs.
THEME_menu_local_task() if you want to modify the markup for the list item and links for the tabs.
THEME_menu_local_action() if you want to modify the markup for the list items and links for the action links. Oh, and don’t forget to wrap that one in a <ul> because just printing the rendering the variable alone leaves you with list items but without a <ul>.
THEME_links(), THEME_links__main_menu() or THEME_links__secondary_menu() to change the markup for the navigation links.
THEME_page_alter() if you need to hide or relocate regions or get at anything inside them.

This is insane. And we wonder why people have a hard time learning Drupal. And for the record, the Theme Developer module will not help all of this, nor is it the answer, and neither is documentation.

Data Structure

Data structure is a nightmare, and clearly an afterthought. The variables in templates are complicated, unreliable, and chronically inconsistent and it all starts with the data structure. Unless you are a PHP Ninja and can deal with pre-render functions, good luck trying to change a table into a list or vice versa.

Drupal may be notorious for its large, complex arrays, but IMO they are not the problem, nor is the existence of data structure. I believe the fact that data structure is whipped up on a case by case basis and pushed straight to templates in many cases is the root cause for the mess of a theme system that we have.

Imagine how much easier Drupal would be to learn if the data structure was completely consistent? Imagine if you could just guess based on experience where the value you are looking for is? Imagine if you could transform the format provided for the output from plain text to a definition list by setting one property before rendering? Imagine if contrib developers didn’t have to write theme functions for everything?

Too Many Levels of Processing

We’ve got preprocess, process, pre-render and and there can be endless implementations of these. There are no hard and fast rules for when to use one over the other. Sometimes you learn the hard way that you need to use process instead of preprocess because some module decided to add a variable in the process phase, and nothing you are doing to override that variable has worked in preprocess.

Other times you’ll get burned by pre render functions. For example, a while back I was struggling trying to prevent the filter help text from printing on a comment form. Attempting to hide it in a preprocess, process function or a form alter implementation simply did not work because there is a pre-render and process function manipulating it. The only place it would work was in the template itself. Ultimately I had to implement hook_theme() to use a template for the form solely to accomplish a simple hide(), because the template was the only place it would actually work. It took me hours to figure this out because the data I had access to in the theme layer was what it looked like before before the pre-render function changed it. That’s way too much troubleshooting and steps to accomplish something that small. This sort of thing is just maddening.

Additionally, there is no shared processing phase across theme hooks. The default preprocess variables ONLY apply to template file implementations, and cannot be used for theme functions. This means if you need any of the default variables, such as attributes or anything else created here, you must recreate it in your own theme function implementation.

Doesn’t seem worth it at the end of the day to me.

Your Output is NOT Special

Sorry, but it’s just not. We need to stop treating output as a product of the immediate need of whatever module or API is generating it. The content should drive the output, not the system or API behind it. I’m not saying that we should remove identifiers from output, i.e. a class that labels a container a node or a block. What I’m saying is…

Instead of creating new theme hooks for everything under the sun, we should have a common library of components and formats to pull from and utilize.
Every container, for example, should be handled the same exact way, whether it’s for a region, node, form element, or whatever.
We should stop abusing theme settings to manage content and leave that up to things like blocks, so that content can actually be managed by Drupal. It is a CMS after all.

We don’t have this today. What we do have is often abused and or not flexible enough, so modules create one-off implementations because it’s easier for them to get the job done. This ends up hurting everyone. It’s more code, more complexity, and the attempts to improve things little by little without any planning are making it worse.

What I Want to See

I’ve been thinking about this for a long, long time, and I’ve started to try and get a handle on what we could possibly do numerous times in the past, starting as far back as two years ago. Ultimately, I’d always be asked “How can we fix it” and always just gave up because the changes that would be required are just massive, and I don’t know if I have the technical aptitude to pull it off. Recently I realized that it’s never going to happen unless I’m able to communicate what I’d like to see somehow, so six weeks ago, I bit the bullet and started gathering my thoughts. I came up with the following.

Note: It’s still very rough, and not completely thought out. It also doesn’t aim to solve all of these problems, but I think it’s an improvement. Also, I am a theme developer, not a module developer, so please don’t destroy me if you see something you don’t think will work. All of this is up on GitHub and you are welcome to tweak it, log potential problems and send pull requests. Ok? Great.

Provide Two Structural Templates

Container: The main purpose of a container is simply to wrap Items (see below). They can be used for anything from regions to nodes to form elements. They usually contain a heading, whether visible or not, and can print ALL children (items) in the base template for that container (sort of like the way you can print and entire view inside views-view.tpl.php).
Items: Items are structured content, which are eventually styled via formats (see below) and or components. They do not print ANY wrapper markup by default, and can optionally be wrapped with containers.

Both of these templates contain the same variables, and the same data structure for as much as humanly possible. They also include $append and $prepend variables that allow content to be injected at the beginning and the end of templates. These are special variables to deal with things like Contextual Links and Shortcut links, which also contain structured content and should not be abused like #prefix and #suffix are today.

Use Formats and Components to Generate Output

Formats: Formats consist of HTML markup as defined by the spec. Some examples of formats include, unordered or ordered lists, definition lists, tables, etc. Formats need to be extremely flexible. They are variants of the default item implementation, and the key to making them awesome is providing the same data structure across different formats so that they can easily be swapped to use one or another without having to manipulate data.
Components: Components are usually a combination of containers and formats that make up custom UI elements. Examples of components include Tabs, Vertical Tabs, Form Widgets (like password confirm and machine name), Carousels, Accordions, etc. Components usually have recommended use cases for application. Their implementation can vary from CSS and JavaScript standpoint, but their markup is pretty standard.

Some of the Potential Benefits

If we are able to pull this off the way I’m envisioning, we can drastically reduce the number of templates. We can continue to give the theme developer control over the markup without so many assumptions and a sane, reliable data structure and workflow, which IMO will make Drupal a lot easier to learn and a lot less frustrating to use. It should also allow us to use other theme engines, instead of being locked into PHP Template.

So, check it out. It’s not, by any means complete, but there are some examples that should give you a decent idea of what it would look like:

http://jacine.github.com/drupal

Then, join the relevant conversations on Drupal.org:

If you’re at Drupalcon, come to the Re-thinking the Render/Theme Layers core conversation.
[meta] Theme/render system problems
Reduce the number of theme functions/templates

Drupal 8 HTML5 + Front end Update Slides

Sun, 11 Dec 2011 17:17:00 -0500

Here are the slides for the presentation I gave yesterday at Drupalcamp NYC 10.

Download the PDF.

adactio: 8 Month Old Deaf Baby’s Reaction To Cochlear Implant...

Fri, 09 Dec 2011 14:16:07 -0500

adactio:

8 Month Old Deaf Baby’s Reaction To Cochlear Implant Being Activated (by Pasanonic)

Strawberry Vomo = Yummy

Tue, 06 Dec 2011 21:59:17 -0500

Allow me to share the best cocktail I’ve ever had with you… :)

Strawberry Vomo

Ingredients

1 shot - Absolut Vanilla vodka
1 shot - sour mix
~2 - muddled strawberries
~3 - fresh mint leaves
Sprite

Instructions

Combine all the ingredients above, except for the Sprite into an 8 oz. glass. Fill the glass entirely with ice, and then fill the rest with Sprite. Mix it all up (in a Martini shaker if you have one) and enjoy.

Source: I learned of this drink at “B Bar” in The Borgata Hotel and Casino a few weeks ago.

Creating Patches for Drupal Projects

Wed, 03 Aug 2011 02:28:00 -0400

This guide will show you what patches are and how to work with them in the context of the Drupal project (though it will likely be useful for any project). When you’re finished reading, you’ll be able to create, apply and revert patches like a pro. Here’s what we’ll cover:

The Anatomy of a Patch
Check out a project from the Git Repository
How to Create a Patch
How to Apply a Patch
How to Revert a Patch

The Anatomy of a Patch

A patch is a document that shows the differences between 2 versions of one or more files. We use them for Drupal development along with version control (Git) to communicate changes in a way that is very easy to understand, share and review. This is an example of a dead simple patch that changes a single line of code. If it looks a little complicated, not to worry. We’ll break it down bit by bit.

diff --git a/modules/taxonomy/taxonomy-term.tpl.php b/modules/taxonomy/taxonomy-term.tpl.php
index b515a9b..872d4cb 100644
--- a/modules/taxonomy/taxonomy-term.tpl.php
+++ b/modules/taxonomy/taxonomy-term.tpl.php
@@ -37,7 +37,7 @@
* @see template_process()
*/
?>
-<div id="taxonomy-term-<?php print $term->tid; ?>" class="<?php print $classes; ?> clearfix">
+<div id="taxonomy-term-<?php print $term->tid; ?>" class="<?php print $classes; ?>">
<?php if (!$page): ?>
<h2><a href="<?php print $term_url; ?>"><?php print $term_name; ?></a></h2>

The Header

The header is automatically generated. It provides information about which files are affected and what command was used to generate it (in this case the git diff). The last two lines show the files being compared with a --- (original) and +++ (new) prefix.

diff --git a/modules/taxonomy/taxonomy-term.tpl.php b/modules/taxonomy/taxonomy-term.tpl.php
index b515a9b..872d4cb 100644
--- a/modules/taxonomy/taxonomy-term.tpl.php
+++ b/modules/taxonomy/taxonomy-term.tpl.php

Hunks of Changes

The first line of each hunk range represents the starting line number and the number of lines in the hunk. As above, the - and + prefixes refer to the original and the new version of the file(s). Below this, each change is represented with the original version of it, followed by the new version of it. The original version is prefixed with minus sign. It represents code being removed in the patch. The plus sign represents the new version of code being added.

@@ -37,7 +37,7 @@
* @see template_process()
*/
?>
-<div id="taxonomy-term-<?php print $term->tid; ?>" class="<?php print $classes; ?> clearfix">
+<div id="taxonomy-term-<?php print $term->tid; ?>" class="<?php print $classes; ?>">
<?php if (!$page): ?>
<h2><a href="<?php print $term_url; ?>"><?php print $term_name; ?></a></h2>

Checking out a project from Drupal’s Git Repository with Tower

Before you can get started creating patches for Drupal projects, you’ll need to ensure you’ve got Git installed and that you’ve setup a local repository for the Drupal project you want to patch. You can test whether you’ve got Git installed by opening up terminal, typing “git” and hitting enter. If you get a bunch of help text, then you’re good. If you get a message saying the command isn’t found, then you’ll need to install Git.

-bash: git: command not found

If you are comfortable using the command line, this page will show you now to install Git. Afterwards, or if you’ve already got Git installed you can skip to creating a patch instructions. If you need a little guidance with a GUI, read on.

Set up a local repository with a GUI (Tower in this case)

Personally, I use and like Tower, so I’ll show you how to set up a repository using it. There are lots of Git GUI’s available and the process of setting up a new repository is pretty similar across them, so you’ll probably be able to follow along. Refer to the handbook for a growing list of Git GUI apps that are available.

Begin by click “Clone Remote Repository” from the dashboard.
Grab the repository URL from from the Version control tab (available from every project page) as use it as the “Remote URL.” In this case we are setting up the current development version of Drupal core. Name the repository whatever you want and browse to a location where you want to place the files. Then click “OK.”
After clicking “OK” the clone process will begin. It usually takes a minute or two depending on your connection speed. When it’s complete a new repository will appear on your dashboard. When you click into it you’ll see that repository is already on the proper branch (8.x) and there are no local changes pending. That’s it.

How to Create a Patch

The first thing we need is an issue to patch. Last month, mortendk noticed that an unwanted .clearfix class had somehow made it into the taxnomy-term.tpl.php template. Eventually, a new bug report against core was born. Morten didn’t know how to create a patch, but he tells us what should be done in the first comment. Unfortunately, if there is no actual patch, it will never reach “Reviewed and Tested by the Community” status and will not get fixed so that is just not enough. We need an actual patch. We know what the fix is here. We simply need to remove the “clearfix” class. So how do we do that?

Make sure the code is up to date

Since we’ve already setup the repository, the first thing we need to do is make sure our codebase is completely up to date. There should be no other changes pending in the local repository. If you are using Tower or another GUI, you’ll need to make sure any pending changes are reverted before continuing.

We can update the code in the Terminal with the following 2 commands:
```
git reset --hard
git pull origin 8.x
```
In our GUI, we can click the “Pull” icon (in Tower it’s the second icon from the top left) to accomplish the same.
Make Your Changes and Save Them

Since we’re working with version control, we can freely make changes and then save those changes right in place. They can always be easily reverted, and since none of us actually have commit access to Drupal core (or most contributed projects), we cannot actually do any harm. That being the case, I’m going to go straight to the affected file: modules/taxonomy/taxonomy-term.tpl.php. I’ve deleted the “clearfix” class and saved the file. Now when I look in Tower, it appears as “modified” and it’s got what looks like a patch underneath it.
Create the Patch

We are now ready to create our patch. Sorry folks, but we’re definitely going to have to use the command line for this one. Don’t worry — It’s 2 painless commands. I promise. First, we navigate to the root of the project and then we run the git diff command to generate the patch.
```
cd ~/Dropbox/Sites/drupal-8
git diff > patch-name.patch
```
It gets more complicated when patches require adding, renaming and(or) removing files. In order to get these changes into a patch, Git needs to know about them. You cannot just git add or “stage” in Tower and then run the patch command. This will not work. Instead, you should stage the files like you normally would for a commit. After doing this, you can generate the patch using the —staged option when generating the patch. For more information, see git diff documentation.
```
git diff --staged > patch-name.patch
```
This short video shows this process in action.
Upload the patch to Drupal.org

You’re done! Your new patch is sitting in the root of the project directory. Now it’s time to upload it. It’s always best to explain what the patch does in the comment to help reviewers. This one is really simple and so is the comment. The patch is automatically tested by the testbot to ensure that it doesn’t cause any unwanted test failures elsewhere. Generally markup and CSS patches don’t have an affect on unit tests, so most of the time these will pass. The green background indicates that this one has passed the tests. Yay!

If you read on in the issue, you’ll see that it is reviewed by and marked “reviewed and tested by the community” or what we like to call RTBC. This gets the attention of core committers. Just a few comments and weeks later, Dries committed the fix to both Drupal 7 and Drupal 8. SUCCESS! Now that wasn’t so hard was it? This is how it happens, folks.

How to Apply a Patch

The first step, as always is making sure your codebase is up to date. Once your codebase is clean and ready to go, you are ready to apply a patch. I’ll use the same issue as an example.

The first thing we need to do is save the patch to our project root. One fancy trick to speed this process up is to use wget. This command doesn’t come with OS X by default, so if you want it you’ll need to install it. Of course this is not required. “Save as” works just as well, but if you do have it this is the simple command you’d run from the project root to download the patch:
```
wget http://drupal.org/files/issues/taxonomy-clearfix-1198088-01.patch
```
Next we apply the patch using a simple command, again, from the root of the project:
```
git apply -v taxonomy-clearfix-1198088-01.patch
```
Hint: You can start typing the first few letters of your patch name and use tab completion.

The -v flag stands for “verbose.” When using this, the command will provide feedback in Terminal showing how the patch has applied.

Once the patch has been applied you can begin testing it and making modifications to the code, if needed. You may easily create an updated version of the patch by repeating steps 3-4 in the How to create a patch section.

How to Revert a Patch

There are a few different ways to revert patches:

Revert changes for a specific file using a -R (revert) option:
```
git apply -R taxonomy-clearfix-1198088-01.patch
```
Revert a specific file using git checkout, or you can select the file and click the “revert” icon in your GUI.
```
git checkout modules/taxonomy/taxonomy-term.tpl.php
```
Reset the entire working tree with a hard reset:
```
git reset --hard
```

Learn more

Here are some quick shortcuts to the documentation pages that detail everything you ever wanted to know about patches and more.

HTML5 Initiative Video Presentation and Slides for Drupal Design Camp Berlin

Tue, 28 Jun 2011 13:40:00 -0400

If you’re interested in the Drupal 8 HTML5 Initiative, check out this short video presentation and slides I put together for Drupal Design Camp Berlin. It provides an overview of the initiative, the roadmap, and provides details explaining how to get involved.

View on Vimeo.com.

View on Slideshare

HTML5 Drupal 8 Initiative

Wed, 18 May 2011 16:39:00 -0400

Back in March, at Drupalcon Chicago, Dries announced that moving to HTML5 would be one of five major initiatives for Drupal 8. I was honored when he asked me to lead the initiative.

These are exciting times for web development and for the Drupal community. Over the past couple of years, we’ve seen HTML5 usage grow and CSS3 hit the mainstream. There has also been a real shift in design thinking. Gone are the days when you could design a website that would only be viewed on a desktop computer. At the same time, many of us are still stuck supporting older browsers. This presents both a challenge for Drupal, and a great opportunity. Between the Design for Drupal 8, Web Services and the HTML5 initiative, Drupal 8 is well positioned to make the improvements to Drupal core’s markup and CSS that many of us (myself included) have been waiting for, for a very long time.

Initiative Goals

The main goals of this initiative will be to implement HTML5 in Drupal core in a way that will:

Have the most benefit for end users.
Enable contributed modules and themes to evolve using HTML5.
Allow theme developers to control where to use the new semantic elements, and opt out entirely if they so choose.

We want to ensure we’re spending our time implementing features that will directly benefit Drupal’s user base the most. As part of this initiative we‘ll focus mostly on:

Adding support for the new form elements to Drupal’s Form API.
Adding new semantic elements in core templates in an appropriate way.
Adding ARIA roles to markup to improve accessibility.
Simplifying style and script elements.
Ensuring input filters and functions accept HTML5 elements.

The process of switching to HTML5 will also allow us take a good hard look at our templates. While updating the markup, we’ll also have the opportunity to re-factor Drupal’s CSS, and get rid of all the old and crufty bits once and for all.

HTML5 introduces a number of new APIs including audio, video, drag and drop, offline web applications, storage, geolocation and more. These APIs will not be the main focus of this initiative at this time, but proposals to implement them in core will be considered on a case by case basis.

Next Steps

In the coming months, we’ll examine the work that has been done in contrib and discuss what’s best for Drupal core. We’ll be working in the core issue queue on issues tagged HTML5 and general discussion will continue in the HTML5 group. We’ll schedule regular meetings to discuss priorities, progress and issues. More details will be posted shortly on the core initiative homepage, which once created will be referenced here.

Getting Involved

I’d like to take this opportunity to encourage anyone that’s passionate about HTML5 and wants to get into core development to join this effort. The stronger our team, the more we’ll be able to accomplish and anyone is welcome to get involved. You don’t have to code patches. Feedback, reviewing patches, writing documentation and contributing your awesome project management skills, for example, are just as valuable as code and will go a long way in helping make this initiative a success. Don’t let a perceived lack of knowledge or phobia of the core issue queues hold you back. ;)

The best way to get started is to read up on HTML5, and begin to participate by commenting on core HTML5 issues where you can. If you’re not familiar with HTML5, here are some great free resources to get you started:

I’d like to thank everyone who encouraged me to accept this challenge, and those who’ve committed to being part of the team so far (more on this will follow soon). I hope to talk to more of you in the coming weeks about logistics and I’m looking forward to working with you all to make this initiative a success. Finally, I’d like to thank my employer, Gravitek Labs, for their continued support and for giving me the time I need to work on Drupal core.

How we've started to clean up CSS in Drupal's System module

Fri, 10 Sep 2010 18:25:40 -0400

A couple of weeks ago, I wrote a post about Drupal’s CSS and how we can begin to clean it up. Since then a couple of us have resumed work on a patch to make some progress with the first part:

Do a round of cleanup in system.css, and ensure code is in the appropriate CSS file.

We are certainly limited to cleanup at this stage, given that Drupal 7 is so close to a beta release, so we’re just moving styles around as opposed to rewriting any code. Still, we’ve gotten really far.

Last weekend, while working on the latest patch, I decided to create a document summarizing the process of splitting of the base styles from the design styles with screenshots and code to help those reviewing the patch. The idea is that themers can easily remove system.theme.css, which makes a lot of assumptions about design, without breaking critical functionality.

This may not end up being the final version of the patch, but that’s beside the point. Hopefully this will help some module developers out there begin to think about separating their CSS.

Check out the PDF (pretty pictures and code).

If you can, please help review the patch.

Stylesheets can't remove CSS files via theme.info anymore in Drupal 7

Thu, 02 Sep 2010 22:23:00 -0400

UPDATE: The original issue has been fixed. However, there is still a bug that allows these stylesheets to come back when content is rendered via AJAX.: http://drupal.org/node/967166

This video demonstrates the Drupal 7 issue outlined here: http://drupal.org/node/901062. Please comment in the issue if you want to see this fixed. Posting here wont help.

Dreditor TextMate Style for Drupal.org

Sun, 29 Aug 2010 14:00:00 -0400

For those of you who don’t know, Dreditor is a kick-ass Greasemonkey script that Daniel Kudwien wrote to help make the process of reviewing patches more efficient.

It begins by adding a “review” link right next to the link for the patch file that looks like this:

When you click it, Dreditor opens the patch in an overlay that allows you to browse the affected files. It also allows you to select any line(s) you want to comment on and provides a textarea for you to enter them. You can do this for as many lines as you want. When you’re done, it allows you to paste fully formatted comments right in the comment textarea of the issue. It’s incredibly helpful and one of those “must have” tools for anyone reviewing patches for Drupal.

However, I’m used to viewing patches in TextMate, which is very different looking from the default style Dreditor provides. I find TextMate’s style a lot easier to read, so I created a Userstyle for it last year. Since then, there have been changes to the markup and new features added, and this weekend I finally got around to updating my Userstyle. I also gave the sidebar a redesign and did some other tweaks. If you use TextMate, you might want to check it out.

Here’s what it looks like:

Jeremy Keith on styling id attributes in stylesheets at Drupalcon Copenhagen

Sun, 29 Aug 2010 13:19:00 -0400

At Drupalcon Copenhagen last week, Jeremy Keith did a fantastic keynote on HTML5. After the keynote was finished, he answered some questions. Someone asked if the id attribute behaves the same in HTML5, to which he answered yes, and then offered the following, excellent advice:

Think about why your using id though. I’ve stopped using id in my stylesheets. I generally never style things using id, sticking to class names all the way, because whenever you say id equals you know whatever, header, footer, you’re saying this is only gonna come once in this document. I guarantee it. It will never come twice.

That’s a pretty big commitment. Are you really sure? Are you sure that six months from now, a year from now there might not be another one of those elements on the same page. Play it safe, use a class.

The only time I use an id attribute on an element is when I want that element to be addressable, which is the reason id’s exist, so that you have that fragment identifier in the url which is hash and then the id. That’s when I use id.

I pretty much never use it for styling now anyway, and I would recommend you look at sticking to classes, understanding specificity, understanding the flow, and using classes well, rather than using id.

When theming Drupal sites, targeting id’s in stylesheets is a very easy trap to fall into. I’m guilty of doing this myself at times, but he’s absolutely right. Don’t fall for it! Working with classes is much more flexible and generally easier to code.

Oh, and if you haven’t watched the keynote, I highly recommend you watch it now. It was top notch.

If you’re feeling inspired after that, and want to help with Drupal’s HTML5 efforts, join the HTML5 Drupal Group and get involved with HTML5 Base (theme) and HTML5 Tools (module).

The Future of CSS in Drupal

Thu, 19 Aug 2010 16:35:00 -0400

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.

Mistakes

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.

Lessons Learned

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:

Maintaining modularity
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.
JavaScript relies on CSS in most implementations
When removing all CSS from core, you must also remove the JavaScript functionality as the two are closely tied to each other. Things like the overlay, toolbar, contextual links, collapsible fieldsets, vertical tabs, and tabledrag, etc. simply will not work. Try it yourself if you don’t believe me.
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.

The Mission:

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:

Filename	Purpose
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

If module developers follow this as a guideline, in Drupal 7, we can do a swift hook_css_alter() in template.php, and wipe out all the design related assumptions we don’t want. Poof, gone! The best part is that JavaScript functionality and basic structure would not be lost.

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.

I’m not exaggerating when I say it’s rewarding. It’s not always easy, but I could practically promise you that you would not regret it. Just look at what Jen Simmons has been up to lately.

Hi!

Fri, 30 Jul 2010 00:38:27 -0400

I moved my site over to Tumblr! I rarely find the time to post anything, and well it’s just easier to maintain this way. Maybe next time I get a chance to spend an hour or two on this site, I’ll spend that time actually writing for it instead of updating it.