some other styling quirks (was: Re: Re: IE 5/Mac Template Breakage/body{} q's)
From:
"Shane Clintberg" <shaneclintberg@PROTECTED>
In-Reply-To:
Re: IE 5/Mac Template Breakage/body{} q's
Date:
September 3rd 2005
See, I told you we were close! :-)
And since I've now slept on it, I'm thinking that
the solution in my
testfixC might be the best (cleanest and easiest to understand) over
all....
But first: For
those of you who missed it, here's Manfred's latest screenshot:
Manfred wrote:
> The effect I meant was...that distance A (marked in RED at the
right) above the heading line is wider than distance B. In case, that is the
correct behaviour, we are done.
Yes, this is the way it's designed.
In version 2.9.2 and under this was controlled in
two separate CSS rules for the #Header:
padding:20px;
padding-bottom:10px;
(The first rule sets 20 pixels of padding for all
sides, and then the second rule overrides the first, making the bottom
padding -- distance B in your screenshot -- smaller.)
...But then for some dumb reason, I rewrote those
two rules into one harder-to-understand rule (that does exactly the same thing)
just after 2.9.2's release. My bad: I just reverted it back this morning. :-)
[Note to Justin: would you prefer that I also undo my
CSS rev. 1.61 changes for the same reason?]
Manfred wrote:
> However, I also found two more funny effects that I find no
problem but which are probably not desired. I have marked them with red arrows
at the left....
> a) In MSIE/mac OS9 the Popup menu content does not completely fill
the defined Popup Area as soon as you click on the menu item (this effect can be
seen on my picture)
Hmm, I don't see any suggestions at: http://www.l-c-n.com/IE5tests/forms/ that
relate to this. Is this normal behavior for IE/Mac/OS9 "popup/dropdown" menus,
or is it specific to Dada Mail? Does anyone else have any ideas for fixes here?
because frankly, I'm at a loss.
Manfred wrote:
> b) In both Opera 6.03/mac OS9 and MSIE/mac OS9 the radio buttons
have black squares around them (as to be seen on my
picture.
Ah, the return of the bordered checkbox/radio
button problem! (This was discussed about a month ago, but it looks like our
solutions at the time weren't quite robust enough....)
In version 2.9.2 stable, Mozilla Win/Mac is (to
my knowledge, anyway) the only browser that doesn't show those borders.
Every other browser (that I know of) properly applies the border
rules written in the "input{}" rule set.
The problem with removing those border rules and
calling it a day is that there are different types of <input>
elements, and we do want *some* of them bordered.
Ideally (I think), we *don't* want borders
on:
<input type="checkbox" />
&
<input type="radio" />
but we *do* want borders on:
<input type="file" />
<input type="password" />
&
<input type="text" />
...So, what can we do about this?
Well, there's a CSS3 selector ( input[type="foo"]
) that's made just for problems like this...but it's bleeding-edge CSS3, so
very, very few browsers can understand it. And then there's an IE/Win-specific
hack (which is currently implemented
in all 2.10.0 "pre-stable" releases)...but that, of course, only helps
IE/Win.
...And what does that leave us?
In no particular order, here are the possible
long-term approaches we might use for this still-unresolved
problem:
(1) Leave everything
as-is.
Pros:
- Hey, we're done!
Cons:
- Checkbox and radio-button borders don't appear
in Moz or IE/Win, but they *do* appear in: Opera/Win, Opera/Mac (both OSes),
IE/Mac (OS9 for sure, and OSX also I think), and maybe others.
- Most end-users likely won't be aware of these
browser differences, unless we provide a chart/screenshot set for
them.
- End users wanting to customize the default CSS
file's "input{}" rule set could be in for some nasty surprises, especially if
they don't have the same range of test-suite browsers that we (collectively) do,
and don't want to pay for something like http://browsercam.com to do a similar job
for them.
(2) Add redundant classes to
some of the <input> types.
If we change all instances of, say:
<input type="checkbox" />
<input type="radio" />
to
<input type="checkbox" class="checkbox"
/>
<input type="radio" class="radio"
/>
we could then remove the borders with a single
stylesheet override:
input.checkbox, input.radio { border:none;
}
Pros:
- Will work in all
browsers/platforms.
- Easier for end users to understand and
customize.
Cons:
- Extra markup in the templates.
- One more thing to remember when writing new
templates.
Notes:
- I originally thought that all the
different <input> types would have to be given redundant classes. As the
example above shows, this is not the case.
- Because it's unlikely that anyone would ever
want to custom-style checkboxes but not radio buttons (or vice versa), we
could give them the same class name. But what the heck would we call
it: class="not_a_text_field" ? (I prefer the two different class names
above.)
(3) Remove the border styling from
all input types.
If we remove all border rules from the input{}
rule set, all <input> types -- checkboxes, radio buttons, and
text fields alike -- will be displayed using their browser
defaults.
Pros:
- No more checkbox/radio-button
borders.
- Easy to understand for end users.
- Some argue that because the default appearance
of form widgets are more familiar to visitors, they increase understanding of,
and confidence in, the form. [See:
&
, for example.]
Cons:
- But it's not pretty like we want
it!
- It's no easier for end-users to customize than
option (1) above. [On the other hand, forms *are* notoriously difficult to
customize anyway, given the current state of browser differences. So a
reasonable rebuttal to this is that the customization difficulty isn't the fault
of Dada Mail but of wildly different browser rendering...and the same is true of
any web-based application.]
Notes:
- See:
for a multitude of default form-widget
screenshots.
...And those are the only three options I can
think of.
As always: Comments & opinions
welcomed!
Attachments
- 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:
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.