CSS-friendly templates in Dada Mail 2.10, part 2: things fixed along the way

 
From: "Shane Clintberg" <shaneclintberg@PROTECTED>
Date: August 29th 2005
[Note: Even if you have no desire to read through this, please check out "Bug #4" at the bottom: it's currently unfixed, and I'd like your opinion on which way we should do so!]
 
 
CSS-Friendly Templates in Dada Mail 2.10
Part 2: Things Fixed Along the Way
 
Part 1 explained the general reasons why default_list_template.tmpl, default_admin_template.tmpl, and default_css.css look so different between 2.9.2 and 2.10, even though they still work much the same. (Yes, there are good reasons; a quick-and-easy summary is available at:
)
 
In this follow-up, I'll look at the bugfixes and other functional changes to the CSS that were made as part of that overhaul.
 
 
Bug #1: In 2.9.2, tables and textareas extended beyond the screen edge in Internet Explorer for Windows
 
If you haven't had the pleasure of seeing this bug for yourself, here's a screenshot:
 
Why it happened:
 
Percentages are only vaguely defined in the W3C spec. The admin screen's tables are supposed to be 100% of...what, exactly? The containing element?
 
Well, in this case, their container, <div id="AdminContent">, should have told things what size to be. But because #AdminContent started at the width of the full viewport (and then used margins to push the content away from the left-hand menu and the right-hand screen edge) IE got confused, figured that 100% of #AdminContent was still the full viewport size, and scaled its tables and textareas accordingly. And *then* it pushed them to the right, away from the absolutely-positioned menu (and off the screen).
 
How we solved it:
 
As part of the "Zen Gardening" process of grouping the templates' contents into meaningful sections using extra <div>s or <span>s, we also added a few redundant "wrappers" around pre-existing sections. Why? Because due to browser differences, they can help solve layout problems like this. 
 
In this case, <div id="AdminContent"> now had a new wrapper surrounding it, creatively named...<div id="AdminContentWrapper">.
 
So essentially, all we did was move the old styles from #AdminContent to #AdminContentWrapper (no functional change so far), and then defined #AdminContent -- the inside one -- at 100% width. IE doesn't get confused with this percentage-width <div> element (unlike its confusion about tables), so *it* fits right where it's supposed to. And now, this new inner container is what IE looks to when answering the "100% of...what?" question.
 
Confusing? If you're a visual thinker like me, you can see for yourself what each <div> is doing by adding the following "testing rules" into the bottom of your version 2.10-whatever stylesheet, and then visiting any admin page:
 
/* FOR TESTING ONLY! */
#AdminContentWrapper {border:3px dotted green;}
#AdminContent {border:1px solid red;}
 
[One extra note: You may have noticed that the admin menu now also has a redundant <div> around it, with an id of "AdminMenuWrapper". Why? No reason whatever, as far as the default CSS file is concerned: it's doin' nuthin' for us right now! But for someone customizing the default template, it might come in handy. While I said in "part 1" that we don't want to go overboard with this kind of thing, a few more redundant wrappers *may* be added down the road to make things even more customization-friendly. Not to worry, though: we'll chat about it here on the dev list first, ...and in fact, my query in "Bug #4" below does just that.]
 
 
Follow-up Bug #1A: After fixing Bug #1, the vertical spacing of the admin page's content changed
 
This is easier to see if you add the above "testing only" CSS rules into your stylesheet and then compare the results in Moz and IE/Win. It seems the vertical padding in #AdminContent -- that is, the space between the top of the (testing-specific) red-bordered box and the first bit of page content -- renders differently in each (even though it's not specified by us anywhere).
 
Why it happens:
 
I have no idea. At the time, I just hacked in a temporary workaround, and then kind of forgot about it. Until now.
 
How we solved it:
 
We (I) haven't yet, ...but if someone else would like to give this one a go, please do!
 
FWIW: My little hack was to add 8px of top padding to #AdminContent, to push things down just a smidgen in both browsers. The content now aligns with the top border of the menu in IE, ...and with the first line of the menu in Moz. Hopefully, the fact that it's always aligned with *something* will appease everyone's aesthetic sensibilities...and if no other fix is found, I'd be quite happy to simply leave this hack in there even beyond 2.10. (Which is to say also: unless someone else takes it on, I don't expect to have it fixed before 2.10's stable release.)
 
 
Bug #2: The "logo" in the header (".:Dada Mail" by default) couldn't be styled independently in 2.9.2
 
This wasn't a bug in the default style that shipped with the program, mind you. In there, both the logo and the page-specific title (e.g.: "::Sign Up for a List::") happen(ed) to use the same styling. But if you tried to customize one but not the other, that's where the trouble began: anything you did to the logo would then have to be undone in the title.
 
Why it happened:
 
The logo [well, the de facto logo, anyway ;-) ] didn't have its own container apart from the header, and any changes made to the #Header selector would be inherted by the #Title also.
 
How we solved it:
 
Easy: we just added a <div id="Logo"> around the logo and floated it left.
 
But...
 
There's a quirky little rule about floats that came into play: if a non-floating container (the header) contains only floats, its height should not normally expand to contain them. Here's a screenshot of the initial result:
 
There are a bunch of different ways to "clear" those contained floats and make the header expand to hold them as a result. All the ones *I* know are well summarized in:
...and of the various options, I chose the first, old-school way of doing it by adding:
 
<div class="spacer"></div>
 
into the headers of both default_list_template.tmpl *and* default_admin_template.tmpl. So...that's what those new additions are doing there, in case you were wondering. (P.S. - I'm not bought-and-sold on this particular solution, so if you have a different preference, I'd love to hear it.)
 
 
(Not actually a) Bug #3: Some styles were not controllable from the external stylesheet
 
Up to and including 2.10.0 beta 1, default_admin_template.tmpl has included an internal stylesheet which overrides a couple of the external stylesheet rules. In most cases, it's a Very Good Thing to use an internal stylesheet like this.
 
However, doing so creates hindrances for Justin's since-stated interest:
 
> I'd love to see you whip up a no holds barred new styling for Dada Mail
 
because those few overrides *can't* be changed or customized through the CSS file alone. (And they'll always take precedence over anything in an external stylesheet, ...which is why they're so darn good at being overrides!)
 
So while there's NOTHING wrong with how this has been handled to date, shipping Dada Mail with two or more alternative styles in the future will be much easier if the overrides in the admin template's internal stylesheet were moved into the external stylesheet instead, so all the styling could be tweaked from that one CSS file.
 
So with an eye to the future, that's what I did. Just today, in fact. [So unless everyone detests this and we decide to revert it, you'll see it in the next release -- either "2.10.0 beta 2" or, I suspect, "2.10.0 release candidate 1".]
 
How I changed it:
 
First - I added 'id="DadaAdmin" ' to the admin template's <body>, so that rules in the external stylesheet have a way of targeting it (and anything inside it) exclusively.
 
Second - I removed the internal style rules from the admin template's <style> element, leaving only its external-stylesheet call.
 
Third - I put the style rules I just removed from the admin template into default_css.css , but with more specific names. So:
 
    body {rules}
 
became:
 
    body#DadaAdmin {rules}
 
and:
 
    #Header {rules}
 
became:
 
    body#DadaAdmin #Header {rules}
 
Fourth - As a bonus, I also added 'id="Dada" ' into the <body> of the default *list* template, so it's possible to target just the list/archive pages (if anyone ever needs to) using the CSS file alone. Just a bit more customization flexibility added in along the way. :-)
 
To easily see all of these differences put together, you can visit the CVSWeb's diff pages for all three pages:
 
 
 
 
Consequences:
 
Although a lot of things got shuffled around by this, not a single functional change was made as a result: all the style rules still exist, and all of them still apply in exactly the same ways, and to exactly the same things.
 
The only difference is that everything is now in one place: default_css.css. So now, if a an alternative style is ever included in a future release (or is shared or distributed by other means), it will only ever *need* to be one CSS file.
 
 
Bug #4: The main/archive pages are different widths in different browsers
[Note: This bug is still unfixed; your opinions about the available bugfix options are welcomed!]
 
In most browsers, the total width of the list and archive pages is 592 pixels, but in IE/Win, that width is only 550 pixels.
 
Why it happens:
 
...The usual box model differences, as shown/explained in detail in the following screenshot:
 
How to solve it:
 
There are two options here. The first is less hack-ish, but changes both the stylesheet and the templates; the other *is* hack-ish, but changes only the stylesheet.
 
Option 1 -
 
Add <div> wrappers around both templates' headers plus the list template's content, and then use "trick #6" at:
for each.
 
Pros:
- This is not a browser-specific hack, so it's the most robust and best future-proofed option of the two.
- This is the option that's easiest to look at, think about, and understand on your own if you've never seen it before. As such, it's also the easiest to customize to your liking, if you swing that way.
- Those extra <div>s could also allow *other* CSS customization flexibility, Zen Garden-style, for alternative stylesheets and/or those who just like to tweak things.
 
Cons:
- This option changes not only the stylesheet, but also adds wrapper <div>s to the default list template and the default admin template. You may not want those templates "mucked with" any more than they are already for personal/aesthetic/bandwidth reasons. Or, you may be concerned that end-users who have never seen "extra" wrapper <div>s before, ...or who are just used to the simpler templates in 2.9.2 and earlier, ..may see those extra <div>s and say, "WrapperContentHeaderHuhWha...?" and freak out at me or Justin.
 
Option 2 -
 
For both the #Header and #Content selectors in the stylesheet, use a box model hack. Either Tantek:
or Tan:
or something better, if you know it.
 
Pros:
- This option doesn't add any extra <div id="ThingWrapper"> elements in the templates, which keeps the templates simpler.
 
Cons:
- This option adds some very hackish-looking hacks in the stylesheet, making it more complicated (and harder to figure out how to change by the less experienced).
- If a new browser (or different doctype) ever "breaks" this/these hacks, they may have to be changed down the road.
 
 
...So, do you prefer the first (as I clearly do, being comfortable with seeing wrapper <div>s in my HTML)? Or the second (for the reasons given, or other reasons altogether)? Or: "Option 3 - Do nothing"? Or do you just not care either way?
 
Please do tell....
 
_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: improved CSS customization coming in 2.10 alpha 2
Index
Re: improved CSS customization coming in 2.10 alpha 2 ›
  • 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.