CSS-friendly templates in Dada Mail 2.10, part 1: the big picture

 
From: "Shane Clintberg" <shaneclintberg@PROTECTED>
Date: August 26th 2005
 
CSS-Friendly Templates in Dada Mail 2.10
Part 1: The Big Picture
 
 
Introduction
 
When I first introduced some of the broader (and not just bugfix-specific) benefits of the templating overhaul work I've been doing to Dada Mail in recent weeks, Justin's response, in part, was:
 
> I'd like to encourage you to keep going forth on this type of experimentation.
 
And given the incomplete way I had presented things at that point, this was a *perfectly* reasonable statement for him to make.
 
But what I'd like to do now, by more completely detailing the "big picture" concepts behind this templating work, is to show that there's actually nothing at all "experimental" about it: it's just a methodical and thorough application of some very basic, "first principle" Web-design techniques...but techniques that, in combination, ultimately open up some very flexible visual (and in some cases, also functional) customization possibilities.
 
Now, because I *am* methodical and thorough, I'm first going to describe the different areas of work involved, then follow up with some examples from where these ideas came to me from, and finally, offer some ideas of how those examples might relate back to Dada Mail. (Part 2, in a separate post, will detail the particular benefits that Dada Mail's default style has already received as a result.) If you're not that into knowing all the how-to details -- even though they're really easy! -- you may prefer to scroll down to the second section with all the different examples of the customization awesomeness, and then pop back up here later if you're interested.
 
 
What's the Big Idea?
 
Essentially, the overriding goal in much of my recent template-revision work has been:
 
To make Dada Mail's templates structurally robust, so they're fully CSS-customizable without any further changes being made to the templates themselves.
 
For anyone who's already familiar with the very popular "CSS Zen Garden," a single template (or in our case, a set of templates) that's robust enough to be styled in numerous and dramatically different ways will sound quite familiar, ...and everything else below will probably be just be a refresher. But if the name "CSS Zen Garden" didn't mean anything to you there, don't worry: like I said above, it's really easy stuff.
 
By  "structurally robust," I'm really referring to three related areas of work:
 
The first is the templates' XHTML compliance, which CSS likes (and often needs), and which is therefore the foundation of the whole thing.
 
Just like a building's foundation, it's very important to have this right from the beginning, so we don't run up against structural problems later. And also just like a building's foundation, it can be quite tedious to make or to watch being made, ...and the end result, by itself, isn't all that exciting either. (When Justin announced my XHTML-compliance work as one of the improvements in 2.10 alpha 1, there really wasn't all that much else to say about it: on its own, it's just not that big a deal.)
 
...So the XHTML was the first thing I put my mind to -- and as Justin has already announced, it should be really, really good now. But if it still needs fixin' anywhere, please let us know!
 
The second area of "structural work" is using proper structural markup: for instance, making sure that all headings are in <h#> elements and not in, say, <p> elements styled with big fonts. To extend the above architectural metaphor, this is simply having, and using, the proper materials on the worksite.
 
For the most part, Dada Mail was already excellent in this respect, although there were -- and still are -- a few table-based layouts that will be a lot more flexible once things are pulled out of those tables. So that's still work to be done (which I don't see being finished by the pending release of Dada Mail 2.10 stable, so I've already put it on the roadmap for 2.11). But besides those remaining table-based bits, things are lookin' really nice.
 
And the third area of work involved in making the templates "structurally robust" is the one that's newest to Dada Mail and has the most interesting consequences, ...even though it, too, is quite simple in itself.  Basically, it involves taking each template (or part thereof) and using extra <div>s and <span>s (or more specific elements if appropriate) to divide and contain the templates' content in meaningful sections and subsections, so those sections and subsections can be individually targeted and controlled with CSS style rules, as desired.
 
And the only reason things get so "interesting" at this point is because CSS can be a very powerful design tool, ...and the more things it can "hook into" and control, the greater reach it can have.
 
In many ways, this sectioning and subsectioning is literally like framing up a building: it's essentially a matter of adding boxes inside, outside, or alongside other boxes in a useful and organized way. And just as you can get the sense of a building's overall layout and organization once it's been framed up, you can get a similar sense of the layout of Dada Mail's newly "framed up" pages by looking at their "framing" alone, as with my samples at the bottom of: http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/dadadev/20050823020009/ .
 
And the status of this work right now? Pretty good, ...but as I mentioned in that previous post, this "structural grouping" could probably still use a bit more beefing up as well. (In fact, I've added a few extra CSS-friendly id's myself since that message was sent!) So if you ever notice an area of the program that could be further subdivided into meaningful sections or subsections, but isn't -- or if you ever, *ever* have to add a class or id to a template to control something with CSS that you simply couldn't target otherwise -- please give us the heads-up on it. (For an example of what I mean by "meaningful sections or subsections," check out the new archive pages: displayed archived messages now have their own <div> "wrapper", with added subsection <div>s for the message head, body, and attachments list. (P.S. - To find out what else is new, just look in the default_css.css file: all the new CSS id's and classes are shown in there, even if they're currently unused.))
 
...Now, the strange thing about working on the three areas above for an existing website is that it's quite possible to work on all three "in the background," without changing how the site looks in any browser or viewing device, even by a single pixel. [In retrospect, this is why I didn't announce or explain this work on the dev list at the beginning: in my experience, I've found that folks don't particularly care about all this structural "tidying-up" work until they can start to see what it can do for them in practice. There are fables written about this somewhere, I think.] But once those three areas or work are complete (or start to get close), it suddenly makes all kinds of layout bugfixes AND design customizations  easy, ...because it's now possible to base such changes *not* around existing functional problems (e.g.: "let's hang a big painting there, so it covers the crack in the wall caused by our bad foundation") but on good design *decisions* instead ("let's hang the big painting there, because it will make a great focal point for that room").
 
Hey, just let me know when I've overextended the architectural metaphor, okay? ;-)
 
So that's pretty much it for the general "how-to" overview, and the summary of where we're at right now.
 
 
What's It All Look Like, Then?
 
The customization benefits of doing the above templating once-over were first brought to my attention by a site called the CSS Zen Garden ( csszengarden.com ) by Dave Shea. In it, Dave made a single-page template that's "structurally robust" to an absurd extreme, and then challenged designers to create different designs with it, using only CSS.
 
First, here's his raw template, with no style rules applied:
 
 
Upfront, it looks pretty much like plain XHTML, right? But look under the hood (by viewing the page source): Not only are the page's various sections and subsections surrounded by <div>s and most everything given a class or id, ...but pretty much every element also has an extra, redundant <span> inside it, and there are even a few empty <div>s at the bottom, "just in case"! Without question, it's utter structural overkill. (Note: Don't expect to see those last two "enhancements" added to Dada Mail's templates unless *absolutely* necessary because, as Dave himself points out, nothing that robust should ever be used in an actual production environment. The first two -- the sectioning & subsectioning, and the extra classes or ids where they might come in handy -- should be all we'll ever need.)
 
Okay, so here's where it gets good. Have a look at a few examples of what different designers have been able to do with that one template:
 
 
...and for an example with bonus CSS2 styling for modern browsers such as Mozilla (but which, like the rest, still degrades gracefully):
 
(hover over the left-hand nav to see the CSS2 in action)
 
Remember, the only thing that has changed between those examples is the external stylesheet: apart from the pointer to its location, not a single character of the template has been touched.
 
 
...And What Does This Have to Do with Dada Mail?
 
At the most basic level, making Dada Mail's templates even one-tenth as CSS-customizable as the Zen Garden will give end-users another way to change the default style that ships with the program: instead of reworking default_list_template.tmpl or default_admin_template.tmpl to their liking, they can do a lot just by tweaking default_css.css instead. It's just another creative option.
 
But in some cases, it's a more powerful option, too. Let's say that in the header, you want to change the words "Dada Mail" (or whatever else you've changed that text to if you've customized it per Pro Dada's option/advice). By applying a CSS image replacement technique to the new #Logo selector, you can kill two birds with one stone...because your image will appear in both the public pages and in the control panel without having changing two separate template files.
 
Or let's go one better, and say you want to hide the breadcrumbs that appear on the list pages. Formerly, the easiest way was to delete the content of the list_breadcrumbs_widget.tmpl file (but not the file itself!), which meant that you'd have to do the same thing over again with each version upgrade. Now, you can just hide them from the stylesheet with:
 
#breadcrumbs {
    display:none;
}
 
, then save your CSS somewhere special, and know that your customization will last across multiple upgrades.
 
And what might someone do with the new <div> around the archived message attachments? Well...I have no idea, actually. But it's a meaningful wrapper instead of something arbitrary (like a <span> around every fifth word), so I put it there in case anyone ever needs it, and because it makes no difference to everyone who doesn't. I'm sure someone will come up with some use for it.
 
...And beyond these sorts of piecemeal changes and customizations, the fact that substantially different designs can now be described as in a CSS file alone suggests some other, future possibilities as well.
 
Perhaps Dada Mail 2.11 or 2.12 could ship with two or three different default styles to choose/start from. Or maybe, like the Zen Garden, there could be a public repository somewhere on dadamail.org for user-submitted designs. Or one could add a bit of JavaScript somewhere and make a quite robust style switcher (for those of you who are into that sort of thing). And I'm sure there are other possibilities like this, that I haven't thought of.
 
The thing to remember is that there's nothing unusual about these new options. It's just your standard CSS, except now, Dada Mail is a lot more CSS-friendly.
 
 
...Okay, so that's the gist of the big-picture stuff. Questions & comments are welcomed if ya got 'em.
 
Coming eventually (but definitely before the next stable release!) in "part 2", I'll detail the post-2.9.2 bugfixes that have come along with doing this templating work, and how they might affect you and other end users.
 
_s.
 
 
 

Post:
mailto:dadadev@PROTECTED

Unsubscribe:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/u/[list]/

List Information:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/[list]

Archive:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/[list]

rss/atom
‹ Re: Compilation errors when Send Email Using SMTP
Index
CSS-friendly templates, pt. 1 - changelog summary ›
  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)

  • Start a new thread, email: dadadev@dadamailproject.com

This is the developer discussion mailing list for Dada Mail.

If you are just looking for support Dada Mail, consult the message boards at:

https://forum.dadamailproject.com

Documentation for Dada Mail:

https://dadamailproject.com/d

Specifically, see the Error FAQ:

https://dadamailproject.com/d/FAQ-errors.pod.html

To post to this list, send a message to:

mailto:dadadev@dadamailproject.com

All subscribers of this list may post to the list itself.

Topics that are welcome:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

Dada Mail is on Github:

https://github.com/justingit/dada-mail/

If you would like to fork, branch, send over PRs, open up issues, etc.

Privacy Policy:

This Privacy Policy is for this mailing list, and this mailing list only.

Email addresses collection through this mailing list are used explicitly to work within this email discussion list.

We only collect email addresses through our Closed-Loop Opt-In system.

We don't use your email address for any other purpose.

We won't be sharing your email address with any other entity.

Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.

All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.

All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.