You are hereBlogs / moshe weitzman's blog / Highlights from Design 4 Drupal

Highlights from Design 4 Drupal

By moshe weitzman - Posted on 15 June 2009

I am so happy that I attended much of Design 4 Drupal this past weekend. I think it was a watershed event for Drupal’s design and themer communities.

Markup freaks

There were quite a lot of people who expressed frustration with Drupal’s markup. I got an earful from #danigrrl before I even picked up my badge. She said

My site has a testimonial section. To do that, I create a View called testimonial and configure it to show as a block. I want that block to have an HTML id of #testimonial. I don't want #block-views-testimonial. And I definately don't want a truckload of classes added everywhere.

I decided to take a look. Here markup from a Views block that Organic Groups module offers. The block is a list containing two usernames.

<div class="first block left-region views-block odd clear-block" id="block-views-og_members_block-block_1">
          <h2>Recent members</h2>
          <div class="block-content">
            <div class="view view-og-members-block view-id-og_members_block view-display-id-block_1 view-dom-id-1">
              <div class="view-content">
                <div class="item-list">
                    <li class="views-row-1 views-row-odd views-row-first">
                      <div class="views-field-picture">
                        <div class="picture"></div>
                      <span class="views-field-name">
                        <span class="field-content"><a href="/pr6og/user/1">weitzman</a></span>
                    <li class="views-row-2 views-row-even views-row-last">
                      <div class="views-field-picture">
                        <div class="picture"></div>
                      <span class="views-field-name">
                        <span class="field-content"><a href="/pr6og/user/3">amy</a></span>

The traditional answer to this complaint of “classitis” can be summed up as - “tough shit”. That ‘views’ prefix that appears everywhere is a namespacing issue which has solid justification. But I’m slowly, possibly changing my mind on this. The markup freaks greatly value economy in their HTML and CSS. They can’t stand any non-essential bits. Drupal developers are like this too. Code patches get rejected because of extra whitespace for goodness sake. Einstein might have been talking about markup freaks when he said Everything should be made as simple as possible, but no simpler.

Granted, id=block-views-testimonial is only a tiny bit uglier than id=testimonial. But that ugliness gets propogated all over the theme. Your css now references #block-views-testimonial. Multiply that for many blocks and several elements within those blocks and pretty soon you are swimming in block-views prefixes. Furthermore, javascript needs to target these elements so your code becomes less readable too.

Studio theme

Studio is truly innovative base theme. I love how it fully embraces the preprocess layer and base theme inheritance that we added in Drupal6. Studio ships with the usual template files like block, node, page, etc. But the hard coded HTML attributes in the files have been stripped. Compare these two node.tpl.php files.:


<div<?php print $attributes; ?>>

  <?php print $picture ?>

  <?php if (!$page): ?>
<h2 id="_title"><a href="<?php print $node_url ?>" title="<?php print $title ?>"><?php print $title ?></a></h2>
  <?php endif; ?>

  <?php print $submitted ?>

  <?php print $terms ?>

  <?php print $content ?>

  <?php print $links; ?>



<div id="node-<?php print $node->nid; ?>" class="node<?php if ($sticky) { print ' sticky'; } ?><?php if (!$status) { print ' node-unpublished'; } ?> clear-block">

<?php print $picture ?>

<?php if (!$page): ?>
<h2 id="_title"><a href="<?php print $node_url ?>" title="<?php print $title ?>"><?php print $title ?></a></h2>
<?php endif; ?>

  <div class="meta">
  <?php if ($submitted): ?>
    <span class="submitted"><?php print $submitted ?></span>
  <?php endif; ?>

  <?php if ($terms): ?>
    <div class="terms terms-inline"><?php print $terms ?></div>
  <?php endif;?>

  <div class="content">
    <?php print $content ?>

  <?php print $links; ?>

Instead studio_preprocess() sets them into an $attributes array such as:

// $Id:,v 1.3 2009/04/20 17:15:17 zarabadoo Exp $

* Implementation of theme_preprocess_HOOK().
* Passes varables to the node templates.
* @return $vars
// Prepare the arrays to handle the classes and ids for the node container.
if(!isset($vars['node']->attributes)) {
$vars['node_attributes'] = array();
else {
$vars['node_attributes'] = $vars['node']->attributes;

// Add an id to allow the styling of a specific node.
$vars['node_attributes']['id'] = 'node-' . $vars['type'] . '-' . $vars['nid'];

// Add a class to allow styling of nodes of a specific type.
$vars['node_attributes']['class'][] = $vars['type'] . '-ntype';

// Add a class to allow styling based on publish status.
if ($vars['status'] > 0) {
$vars['node_attributes']['class'][] = 'published';
else {
$vars['node_attributes']['class'][] = 'not-published';

// Add a class to allow styling based on promotion.
if ($vars['promote'] > 0) {
$vars['node_attributes']['class'][] = 'promoted';
else {
$vars['node_attributes']['class'][] = 'not-promoted';

// Add a class to allow styling based on sticky status.
if ($vars['sticky']) {
$vars['node_attributes']['class'][] = 'sticky';
else {
$vars['node_attributes']['class'][] = 'not-sticky';

// Add a class to allow styling based on if a node is showing a teaser or the
// whole thing.
if ($vars['teaser']) {
$vars['node_attributes']['class'][] = 'teaser-view';
else {
$vars['node_attributes']['class'][] = 'full-view';

// Add a class to allow styling of nodes being viewed by the author of the
// node in question.
if ($vars['uid'] == $vars['user']->uid) {
$vars['node_attributes']['class'][] = 'self-posted';

// Add a class to allow styling based on the node author.
$vars['node_attributes']['class'][] = 'author-' . strtolower(preg_replace('/[^a-zA-Z0-9-]+/', '-', $vars['node']->name));

// Add a class to allow styling for zebra striping.
$vars['node_attributes']['class'][] = $vars['zebra'];

// Add a class to make the node container self clearing.
$vars['node_attributes']['class'][] = 'clear-block';

// Crunch all the attributes together into a single string to be applied to
// the node container.
$vars['attributes'] = theme('render_attributes', $vars['node_attributes']);

So, if you want a custom id or class, you just set them up in preprocess. The big benefit now is that your hardly ever need to override template files like block.tpl.php. They just emit the attributes which you carefully setup in preprocess. So, we’ve traded proliferation of template files for proliferation of preprocess. I think thats a win, since you likely already deal with preprocess proliferation.

Further, Studio has a great convention for managing preprocess functions. It offers a subdirectory called preprocess where you put small include files. A preprocess function for the theme(‘node’) would is called and it just contains what you would have put in THEMENAME_preprocess_node(). This isolation into small include files helps keeps your template.php nice and small.

Studio can also greatly improve the id and classitis problems I mentioned above. You can simply unset any classes or other HTML attributes in your preprocess function. And its approach to templates is completely compatible with the traditional template files. You can still use the template files from your favorite modules without any changes if you desire. Personally, I’d like to see Studio’s templating philosophy become standard in D7. That might be controversial, so we’ll see if it gets in.

Studio’s authors, Al Steffen and Matt Tucker, have done a terrific job here. For more detail, read their blog post. Thanks for Pingvision for sponsoring this work.

Skinr module

Jacine of Gravitek introduced Skinr module to the world and generated quite some buzz. I missed this session, but have since played with the module on my test site. Skinr’s project description is quite good:

Skinr's main purpose is to allow the theme to define a set of reusable and modular CSS styles, and to make those styles available in Drupal's UI. Skinr was developed for themers to allow them to tap into the power of Drupal's modularity and apply those same principals to theme development. It does not provide any styles of it's own. These styles are defined in the .info file of the theme (or subtheme), by the themer and end up in various places in Drupal's UI, such as:

* Block Configuration
* Node Type (and Comment) Configuration
* Panel Panes
* Views Displays

It also provides a CSS class field, where you can manually add custom classes.

So, all you have to do is add some items to your theme’s .info file and those items appear on the block config form and similar places. Now site admins can choose how to style individual blocks. As their needs vary, the blocks can grow or shrink or change color and so on.

The piece I’m not yet clear on has to do with these modular CSS styles. Perhaps someone could give me some example of css that you might want to make available to block admins. I haven’t done enough style work to instantly see this. Skinr also lets module developers supply these modular CSS styles which sounds quite promising.

Skinr really mixes up the salad bowl. Style selection on the block form really bends my brain. Nice work, Jacine and moonray.

960 theme

960 theme is a Drupal adaptation of, a very strong open source project thats getting quick adoption in Drupal circles. It reminds me of the early days of Jquery, where we adopted the upstart library instead of the established players (Prototype, Mootools). That worked out very well, and I have high hopes for 960 and Drupal.

960 helps you lay out your pages. You slice up your page into a grid and 960 does all the math for you. Column based layouts used to be very tricky but I think 960 has finally licked this one. We also heard some about competing grid systems from Blueprint and YUI. Use those if you like them!


  • The theme community really stepped up this weekend and shared like the open source rock stars that they are.
  • Core developers should be very proud of the enhancements we put into Drupal6. In particular, preprocess, base themes, and rich .info files are in heavy, happy use.
  • A thousand thanks to Susan MacPhee and everyone who organized this great event. Hurrah for the sponsors too.

Update (June 16)

Earl clarifies that the reply to the markup freaks when discussing Views is DON'T USE GENERIC BUILDERS. Hmmm. Is that the final word? Can we add code and documentation that eases the processes of molding generic, verbose markup into terse, personalized output? Lets all think and blog on this topic. Also, it may be news to many that Earl Miles, the author of Views, is also the creator of the preprocess layer and most of the enhancements to themeing in Drupal 6. In other words, he created many of the innovations that we are enjoying.


Currently my main frustration with Drupal is the amount of redundant code it outputs. Drupal core is actually OK, especially because core output functions are so easy to override, but mainly it's Views that outputs terrible code, as you made clear in your example.
I'm not sure if it still holds true but when I tried panels once I immediately wrote that module off, as the combination of views and panels created code that makes nested table layouts from the nineties look pretty :)

I mean, views is an awesome module and I respect the authors very much, but they are probably not frontend developers. I would love to help out with cleaning it up if someone could guide me through the backend process. Same goes for panels.

Also, mad props for studio themes, it has taken code cleanliness in Drupal theming to a next level and I'm using some of the new stuff in my own basetheme.

I call bullshit.

It's not respect when you call my work crap in public.

Please go look up what respect actually means.

Sorry I did not mean to disrespect you or your modules, in fact I love views and have been using it abundantly on my sites since version 4.7-1.0. Sometimes it takes some loudness and boldness to catalyze a discussion, so if I come off as blunt and bold it's not me tryng to start a fight, it's me trying to start a discussion.

I also understand that in views there is good reason for the code not being very brief, I've also worked with nested views, node views inside nodes etc and you do need extra selectors to get to specific elements.

However, I think an example of "too much html" is this list view from my latest site:

<div class="content">
<div class=
"view view-BestOfADTDrupalBlog view-id-BestOfADTDrupalBlog view-display-id-block_1 view-dom-id-1">
<div class="view-content">
<div class="item-list">
<li class="views-row views-row-1 views-row-odd views-row-first">
<div class="views-field-title"><span class="field-content"><a href=
"/drupal-blog/theming-cck-node" title="Theming a CCK Node" alt=
"Theming a CCK Node">Theming a CCK Node</a></span></div>
<li class="views-row views-row-2 views-row-even">
<div class="views-field-title"><span class="field-content"><a href=
"/drupal-blog/omg-were-live" title="OMG WE&amp;amp;#039;RE LIVE!!"
alt="OMG WE&amp;amp;#039;RE LIVE!!" class="active">OMG WE'RE

The point where I think code becomes reduntant (other word than unnecessary) is where multiple HTML elements wrap around a single text string (except for the anchor element which has a specific function).
In this piece of code it's that each node title is not only wrapped by a

  • tag, but also by and tags.
    Because there is only a node title inside each list tag, all the semantics can be embedded in it's class and id properties, there's no need to add div and span tags to add more meaning to the same text string. You can just add more classes to the list tag to get the same level of inheritable CSS styles and targetting.
    Of course I understand that these extra tags are there because there are also cases where there is more then a node title inside a list tag, and different elements need to be differentiated and grouped. It would though, be cool if views could learn to automatically minimize the amount of tags per item based on how many different elements per list item need to be differentiated.
  • What does "too much HTML" even mean? If there are no styles associated with a div, what's the harm in having too much code there? Does it perform poorly (no)? Does it make it harder to theme (no)?

    So, what's the big deal?

    I'm thinking that the HTML purists should join with the PHP/coder purists and build your own CMS (though, the two groups would probably not work too well together).

    Really, I read your comments as "I don't know how to theme, so let me find someone to blame!"

    Wow, that seems like an odd comment from someone who works for a company that gives training in drupal theming. You are in a minority group if you're a web developer who doesn't care about web standards and clean code.
    The "I don't know how to theme, so let me find someone to blame!" comment is just childish.

    I just read and I have to say I agree with Merlin: before making bold statements and using harsh language, you better just ask how you can help in a polite matter. I guess you don't clearly see the bigger picture of the views module, it isn't solely build to directly output html.

    If you want to 'improve' the output have a look at the theming info link on the views edit page, it allows you to override almost all html output (as easy as core). Or if you want to really (as in 100%) control the output make a custom module that runs the view and process all the results row by row. (You can export a view to code from the same edit page)

    PS: I'm a frontend / backend developer but it shouldn't make a difference.

    The more automated output is, the uglier it is, period. This is true with code generators, markup generators, sql generators, document generators, anything that generates output on behalf of another entity that doesn't have the time and/or the knowledge to generate the output manually.

    I think anyone who works with stuff like CSS and HTML all day, may eventually assume that everything else up and down the stack is as easy to do correctly as closing your tags and not using tables for layout.

    It just isn't so. I don't understand why designer types are so quick to criticize things they do not fully understand. The complexity of something like views is mind boggling to the average joe. To have a GUI for something as complex as generating endless possible queries against unknown sources of data is just plain remarkable. I'm in awe of that. It is amazing and makes many amazing things possible.

    The fact that the result of such a system is too many tags with "ugly" names is a result of many different components working together without knowing what the other components are doing. It is most definitely not the result of sloppy development practices as your comment implies.

    Designers, think twice before criticizing the folks that make it possible for you to create powerful, dynamic websites for your clients without even employing a developer.

    And peach, from the sound of it, you weren't even around in the 90s. The ugliest markup produced by Drupal today can't even come close to the hideous, bloated, unreadable markup produced by pre-CSS HTML during the 90s.

    I love the views module with just a bit more effort and planning ( tpl files, preprocess functions ) you can pretty much produce you desired output.

    There aren't "authors" of views. There is one author, merlinofchaos. You say you respect him, but you clearly don't know who he is and then go on to diss his work.

    Panels & Views are designed to be very flexible and automate a lot of drudge work. You aren't going to get the same markup from that as you will from hand written HTML. It's just not going to happen.

    I think he does an amazing job of making his modules themeable. If you want clean markup with them, have at the template files. Bend them to your will. But don't go slamming him for writing something that people who aren't themers can use.

    I think you owe him an apology for this comment.


    I totally disagree with the OPINION that Views outputs overly heavy or "terrible" CSS markup. I find the mark-up very helpful when trying to theme discreet little bits without changing other Views bits. That flexibility is much more important than lean code. If you want leaner code, write a custom module for your specific use case that outputs only the CSS that you will need, but don't suggest that we remove theming flexibility from Views.

    Difficulty theming the various bits is a MUCH bigger barrier to adoption than heavy markup.

    I love clean light semantic markup as much as you but your comments have not only been hurtful (see Merlin's post"views-panels-economy-of-front-end-code-and-classes-and-namespace") but seem to stem from lack of experience and ignorance.

    peach: "because core output functions are so easy to override, but mainly it's Views that outputs terrible code"
    Views is just as themable and easy to override as core, if not more so.

    peach "I would love to help out with cleaning it up if someone could guide me through the backend process. Same goes for panels."
    Look, I've overridden views many a time only to find that I end up adding back so many wrappers and classes I might as well have not bothered in the first place. All those divs and classes are there for a reason. To assume that you can easily 'clean up' the markup used on tens of thousands of sites whilst simultaneously admitting that you have no idea of the backend process is either extremely naive or massively arrogant – quite possibly both!
    It's easy to take one site and craft light semantic markup, doing the same for ten thousand sites at the same time all with different content...? Try to keep everyone happy and you'll end up with a generic kitchen sink approach, there's no other way.

    You don't even need to know the backend. Create a view, copy the markup and then show us how you'd improve it. Put your markup where that bitchy mouth is :)

    For me this is part of a larger debate, read Dave Shea's essay
    Redundancy vs. Dependency. Views markup is basically very redundant (and that's a good thing for views) whereas you're looking for highly dependent markup (which may well be a good thing for a specific site or theme) there is always a tension between the two.

    In short - please cut out the bitchy ill-informed comments, please don't assume that what's right for you is right for everybody else and please do contribute code and constructive suggestions.

    I'm really glad you got to come out and spend some time at the sessions this weekend! This whole thing definitely has to be a combined dev and designer effort. To be honest, I never really got the developers' confusion or reluctance about economy of code for front end, because having gone to college in a computer science department in the day before laptops were being shipped with 4-8 /giga/bytes of ram, tight code and memory management was something that was stressed a great deal. It makes sense that that mindset would carry over to elegantly simple front end code, but I think that over a decade of pretty powerful home computers has made us all kind of lazy in that respect, perhaps. I'm glad to hear that it's not ignored in the patch submission department/approval of!

    One thing that really got me stoked about the Design for Drupal initiative this weekend in Boston was that whether you are a developer or a designer... we all seemed to be organically speaking the same language. Ultimately, this is going to be huge for Drupal and add years to its longevity, which is something we will all benefit from, having personally vested interests in seeing Drupal be as great and as long-lived as it can be.

    -=- christopher

    Moshe, these were the things that I also gravitated to at D4D Boston. Very exciting stuff! I would add your presentation on some of the cool things coming in D7 (hook_page_alter and many others!) to that list too.

    One of the things we did on day 2 was discuss as a large group with Jay Batson of Acquia ideas for improving Drupal for Themers and Designers. Modules like Mothership, and the frustration of themers like #danigrrl show that poor or overdone markup coming out of modules is a major issue with at least some themers. And even for themers who take the sustainable theming approach of working with what markup is provided - surely themers would like to be able to help mold the markup coming from the modules that they have to beautify.

    With that in mind, and after bouncing the idea off of johnvsc, I posted an issue currently sitting in the webmaster queue to add "Markup" as a standard component in the issue queue for modules. This would provide an obvious way for themers, who may not be comfortable with the idea of offering code patches to "theme_" functions, with a way to offer feature requests for improved markup to module maintainers. It's a small thing, but possibly useful. Comments welcome.

    Hey Moshe!

    I'm really glad you came to the D4D event. I was great to meet you and I'm sorry we didn't get a chance to really chat.

    As far as the modular CSS goes, Nicole Sullivan, who calls it Object Oriented CSS, explains it better than I ever could: It's semi-long (about 45 mins), but I highly recommend it. Without Skinr, achieving code like this with Drupal would be nearly impossible without loads of unnecessary template files and/or logic in the theme, which kind of defeats the purpose.

    The Skinr API is cool because modules like Quicktabs, who want to provide styles with their modules, can use Skinr as a bridge between the module and the theme. With Quicktabs for example, only modules can hook in and tell Quicktabs to scan their directory for tab styles. The end result of a tab style, loads a CSS file and applies a class. If a themer wants to provide custom styles, they would have to write a module specifically to hook into it, but that's not so fun. I see Skinr as a great option here, especially since the module depends highly on its own markup to function, and can't really provide template files. If Quicktabs were to support Skinr, themers could pass styles in the through the .info file without the need for any module.

    Jacine ;)

    Interesting that you should say "So, we’ve traded proliferation of template files for proliferation of preprocess. I think thats a win, since you likely already deal with preprocess proliferation."
    There was a big push to move away from theme functions and use more .tpl.php files in D6, to *help* designers... (although .tpl.php files everywhere are starting to drive me nuts, now). By generating the classes, IDs, etc, in preprocess functions (yay! I personally prefer that) would we not be making things harder and less transparent for the new-to-PHP designer?

    Because by intelligent use of preprocess in a well designed _base_ theme, your tpl.php pages can theoretically be much cleaner and easier to deal with. I thought the Studio presentation showed that quite nicely.

    Also, through improved organization of pre-process you also at least somewhat reduce the learning curve imo.

    I also thought (having attended the Studio and Skinr presentations) that what you saw was the start of possibly putting a UI on top of some of those powerful low level functions. The way Studio manipulates attributes, in theory, allows for better programmatic control (a UI specifically) to be built on top. My, albeit less experienced, observation was that the Studio guys were very excited about Skinr for exactly that reason.

    Anyway, I felt like I was present for the start of something very cool - and by cool I mean powerful, flexible, beautiful ... and maybe even easy too ;)

    I too would love cleaner code, but classes like views-row-1 views-row-odd views-row-first or views-row-2 views-row-even views-row-last are essential for theming, until all browsers can interpret structural pseudo-classes.

    If someone didn't require these utilitarian classes, or wanted them in a shortened form, surely they could theme the view & include/remove whatever html they desired?

    Perhaps the views UI could give more control over the IDs and Classes it inserts, or perhaps more 'frontend developers' could learn how to theme views, but merely 'cleaning up' (i.e. removing) this stuff would just limit ordinary Drupal users' theming abilities - and who would it help? The view-source gestapo?

    Great wrapup on the D4D event!! I tried to write something up, but it was late Sunday after that long weekend, and it was more of an "I'm too tired to talk about it, but I had lots of fun!".

    My weekend highlight was the 960 presentation, and getting to speak with @nathansmith after it was over regarding the great work that he put into the original 960gs. Now if only I could beat every designer with a stick and force them to just use that photoshop overlay as a guide when putting together their wireframes & comps.

    "...That ‘views’ prefix that appears everywhere is a namespacing issue which has solid justification. But I’m slowly, possibly changing my mind on this."

    Moshe, I think this post is great because its stirring up a lot of feelings across the board in the Drupal community. But, what I want to push back on is...isn't it more than just a "namespacing issue"? Isn't it "built in logic" to help us understand what this content actually is, and not something we should just pass off as annoying?

    When I first started Drupal theming, I stripped EVERYTHING, and I mean EVERYTHING out of the page.tpl.php and built up my own markup. I thought it was easier for me to add in my own constraints, name things the way I liked them named, and see how little markup I could get away with - the same way I built sites in Dreamweaver (before I came to CMS land). Now mind you, I was new to Drupal, and there were no preprocess functions yet. This worked for about 2 weeks until I needed to add another view to the site, and then a menu, then I needed to add 2 views to the page, etc. I felt like I was chasing my tail over and over and over again trying to add new CSS rules and markup for every bit of content added to the site. It wasn't for another year before I realized that the CSS classes/IDs that are provide by modules like Views and the Menu system are giving me hints. They're telling me - hey, you can theme every menu in the site if you want,...with just this CSS. It also helped me really understand CSS on a whole new level. It was a monumental shift for me to realize that I'm working with a system that has redundancy, for a reason. Its a system, a tool kit, a website that is NOT static. A website that needs to be able to grow on its own, without the intervening hand of a developer, themer, or designer.

    What I'm encouraged about with your post is that you're saying that you're "...possibly changing my mind on this.". What I think we all to often do is get set in our ways, and I hear you saying...I want to hear about what we can do to make things better, for everyone. That excites me.

    There are 2 camps in the Drupal frontend community right now. The purists and what I like to call myself: the "getting your hands dirty" frontend people. There needs to be a place for both camps, but I don't think the answer is to necessarily bash modules like Views and Panels. The answer is to educate and provide more tools to the purists who want full control of the markup.

    I personally love the over abundant markup in Drupal, b/c I can do anything with it. I'd much rather spend my day writing CSS over HTML. #block-view-testimonial says to've got this view block of testimonials that could show ups in a bunch of places, and hey you might also have a page version of that view could theme them the same or differently. That very logic is what makes Drupal so powerful, and usable by all different types of people. I'd hate to see that go away.

    There are 2 camps in the Drupal frontend community right now.
    I would say that those 2 camps both only have a handful of people, the majority is somewhere in between. Some things are easier in code, other's are just easier in html. And I think that the majority is rather pleased right now, as you can choose exactly which output is generated where.

    I'm personally not a fan of too many tpl.php files cluttering everything, which is why I was never a big fan of contemplate (sry jjeff, mad <3!), whereas for views you can easily drill down and override a tpl.php in a way that it's still generic for (almost) all your views.

    And with all the wrappers and classes, there's usually not even any need to override any tpl.php's, I think that's what makes both CCK and views so popular: it's easy, it's amazingly lean, and you don't have to know a letter of PHP to make it look pretty much however you want.

    The only reason I've tinkered with views preprocessors and tpl.php's is because panels wasn't up for the job at the time, and I looked at the panels code... I wasn't going to be any help there... :(

    Then again, I've only discovered Drupal like a year ago, so what do I know

    From my point of view (someone who needs to build sites quickly and uses Views to get the sites up and running and with savvy clients, explains to them how to use Views to maintain their own sites without needing to know HTML, let alone SQL), I agree with Merlin's righteous rant.

    I've got a site and here's a snippet of code generated by Views:

    <div class="view-content">
      <div class="views-row-1 views-row-odd views-row-first">
        <div class="views-field-field-image-fid">
          <span class="field-content"><a href="" class="imagecache imagecache-thumbnail imagecache-imagelink imagecache-thumbnail_imagelink"><img src="" alt="" title=""  width="110" height="43" /></a></span>
        <div class="views-field-field-artist-nid">
          <span class="field-content">Pablo Picasso</span>
          <span class="views-field-title">
            <span class="field-content">My Awesome New Painting</span>
          <span class="views-field-field-year-value">
            <span class="field-content">
              <span class="date-display-single">(2009)</span>
        <div class="views-field-body">
          <div class="field-content">
            <p>I'm a paragraph, I have things to say, blah blah.</p>

    Lots of markup, sure. Should I want to throw out everything I don't need? I'm not zebra striping this, so I should chuck views-row-odd and views-row-even? But then there will be people asking "what php snippet do I need to paste where so I can have striped rows?" and complaining that it isn't easy to theme things unless you're a php developer. I'm not styling the first and last differently, so should I get rid of views-row-first and views-row-last? Then people will ask "what php snippet do I need to paste where so my view adds the right classes to the first and last result so I can theme it?" and complaining that it isn't easy to theme things unless you're a php developer. To me, it looks like having the classes and ignoring them is better than not having a class and wondering what php you need to add to the view to give you the result that you want.

    Regarding all those divs and spans, you can make the same argument. Remove all of them and people will say "I've got a bunch of views that list all list 10 nodes and that's great, but I want to make the title of the first node in every list 20% larger, please let me know what php I need." With the current Views classes, it is as simple as:

    .views-row-first .views-field-title {
      font-size: 120%;

    Now, I could be misunderstanding this all, but I thought the idea was to get rid of the middlemen. Instead of people who want websites needing to know SQL and PHP and hiring a developer or trying to moonlight as one themselves, Suzy Surfer can pick up some CSS, watch a 3 minute tutorial on Firebug and be well on her way.

    Could there be some improvements made? Sure. Personally, I'd just abbreviate and use classes like vr-first and vf-title, but then at first glance, people will wonder what all these "v" classes are. Alternatively, submit a patch to Views that asks for each field in a view, each grouping grouping of fields and each view itself if it should include certain default classes, custom classes, both or neither. Or require the Views tpl.php files be used to add divs, spans and classes (though there are so many possible combinations and those names get rather lengthy, plus it would become a nightmare to maintain and your average site would have two dozen views tpl.php files).

    Or someone could write a module that goes through the theme's CSS and any class that isn't referenced is removed from the final HTML.

    If I had to pick, I'd prefer verbose HTML that let me just jump in and start styling as opposed to having to jump into php and mess with that. But that's just my opinion. I could be misunderstanding this entire issue.

    Peaches, if you're expecting just the classes that you need and nothing less, you're right, Views, isn't for you. Spend the time (read: your clients' money) writing your queries by hand and adding just the right number of divs, spans and classes, then get around to styling it and explain to them that it costs more because the code doesn't have any unused CSS classes. (I'm all for preaching accessability and other technical merits, but this one would probably prove to be a hard sell.)

    Brian, thanks for the detailed analysis. That's exactly what I'm thinking, as well. The long class names drive me crazy but when I want to figure something out after I come back to it after a month or two, I'm glad they're there.

    I came to Drupal in 4.6 - long before Views and CCK and it was virtually impossible to build a proper site without writing some SQL and PHP. Personally, I can't see a thing to change about the Views mark-up. Moshe's suggestion is intriguing but I'm still not all that clear that the case for it has been made. If it can be shown that the current mark-up produced by modules like CCK, Views, Panels and OG significantly interferes with

    • functionality
    • compatibility
    • speed of processing
    • accessibility
    • ease of development

    then perhaps we should look at this more closely. So far, all the arguments put forward are about code elegance. Sure, the programming community sets great stock by elegance so it's not possible to reject it outright but it should serve a purpose. For instance, the elegance of core PHP code and strict adherence to coding conventions may seem excessive but this is to serve a huge collaborative effort where hundreds of people contribute code that needs to be portable across many developer's IDEs and instantly recognisable for what it is. The same might appear to be the case with theming but it is only to a certain level. Themes are generally developed by much smaller communities than most modules and tools like Firebug make it relatively easy to make sense even of the most convoluted mark up. Sure, it would be faster and easier to theme Views output where only the stuff that needed nested divs had them but the effort and compromises made along the way make that an unpalatable proposition. I often wish more modules paid such meticulous attention to the needs of potential themers. I'll take the few (dozen) extra classes I don't need to define over those that aren't there for somebody else who might need them because the next time around, it could be me.

    I tried to comment on peach and christophers comments but it seems to have got lost, so I blogged instead:
    Drupal markup: redundancy vs dependency. It was getting a little long for a comment anyway :)

    Hi Moshe,

    Thanks for this very good summary of the Studio, Skinr, and 960 theming presentations at D4D this weekend. These clearly are major new projects in the Drupal Design world, and in Drupal in general.

    Have you seen Merlin's response to the D4D discussions?

    It seems that some of the themers loud cries for cleaner HTML - in particular from Views and Panels output - has offended Merlin (Earl Myles), who has put so much of his own time and effort into Views and Panels. He has given a pointed response to a number of the comments presented in discussions at the D4D Camp this last weekend.

    I think that such schisms between the Drupal design and developer communities will occasionally occur, especially as design continues to assume its rightful place of to equal importance to development in the Drupal ecosystem. I enjoyed the D4D camp very much, which was directly setup to address the need for more emphasis on design in Drupal.

    However, I hope that developers like Merlin are not seriously put off by strident demands for cleaner HTML, and "pixel perfect" theming in Drupal.

    Have a look at Merlin's post. I plan to write to Merlin in response to his comments, and let him know how much he still is appreciated by the Drupal community.

    Best regards,

    Michael Caudy

    I also enjoyed having a chance to talk with you at some length about my own major area of Drupal interest: as a CMS for genomics research. Mike

    Thanks for the post.
    However, IMO the markup that you highlighted is a non-issue. Just like you said, it is for namespace sake, a very solid reason. It provides flexibility to control the CSS/theme freely. Let's say Views output less markup, sooner or later there will be complaints that it is not easily themable due to lack of differentiation of the markup.
    If anyone is so incline with the Views markups, there are 19 Views templates, on my last count, that you can override to suit anyway you want it.

    As for the studio theme example, it is just pushing the codes to the template.php to give less on the template. Second designer comes in and will start complain that "only

    print $submitted
    ? I've to go to php to even change the html tags for $submitted?"

    CK Ng

    If the Views markup is a little too verbose, copy the templates and trim what you don't want.

    Especially now that D6 allows sub-themes, a bare bones base theme can easily redefine stripped down default tpl files for Views, CCK, Panels, etc. Then people can see how fun it is to add classes and divs from scratch on a case by case basis.

    Just don't go asking Earl for better template documentation when you can't figure out how to make a class name or something, that's what the default tpl files are for.