I think there are two [CSS] issues - one that we've both talked about and that's the borders on the checkboxes/radio buttons

The problem Justin is referring to here stems from the fact that Internet Explorer applies CSS input rules to all input controls -- text boxes and checkboxes/radio buttons alike And because it doesn't understand CSS3, more specific selectors like

input[type="radio"]

don't help it distinguish one from the other So for IE at least, it's all or nothing: if you want to get custom-shaded text-box borders by targeting the element, you also get custom-shaded radio-button and checkbox borders :-(

The other problem is that the upper left/top and lower right/bottom borders on buttons/textboxes are slightly different

And essentially, this is just an extension of that first border problem

The long-term solution to this, according to our good friend, Mr Google, is to add redundant classes to each & every input element (e g :

<input type="checkbox" class="checkbox" 


 />

), and then target more specific CSS rules to each of those classes

Making that change will be a bit more involved than a simple, template-wide search-and-replace but for me that's a good thing, because the other tweaks required [there's also a bit of code in a few of the Perl files and in default_js js also, I think] will give me a better feel for what's where in the program So I'm on the job :-)

P S - If anyone who's using Dada Mail 2 9 0 or later is looking for a short-term fix for the IE checkbox/radio-button border problem in the meantime, the only solution, alas, is to remove all border properties from the CSS file's "input" and "input:focus" selectors, and let the input controls just revert to their default styles

Coincidentally, this segues perfectly into Justin's next comment:

when you first started, you had some questions I explained it no problem, but I really really should have commented the code when something like this arises

As part of my overhaul of default_css css, I included a comment at the end -- marked DEVCOMMENT -- that briefly summarizes the above border problem, the long-term fix, and the short-term "patch " I mention this because DEVCOMMENT -- yup, in allcaps -- is the convention I use for comments that I feel are important enough to "flag" for others (and sometimes, in the short term, for myself)

Unless you have another convention you'd prefer to use for this, I'd like to suggest that all Dada Mail developers use DEVCOMMENT -- sparingly, of course! -- where necessary as a "major comment here" flag

Keeping this consistent between different developers would benefit everyone: both the devs, who'd be able to do a program-wide string search for DEVCOMMENT to see what's been commented on already [and/or to review stuff that might need a-lookin' at down the road]; and also the users, who could more easily be pointed to -- or could just come across themselves -- any file-specific DEVCOMMENTs that may answer their questions (And of course, a quick search for remaining DEVCOMMENTs just prior to a stable release would make it easy to find and delete any big, "stray" comments that might be bulking up the code unnecessarily )

Does this sound like a good commenting convention to add into our devs' "best practices"? Or is it better left as just my thing, or left out altogether?