regarding additional CSS classes

 
From: "Shane Clintberg" <shaneclintberg@PROTECTED>
In-Reply-To: Re: any and all CSS bugs, suggestions and snippets welcomed
Date: July 25th 2005
 
> Although a hack, doesn't IE allow you to put conditional statement 
> comments in css?
 
Yup, ...but it's a particularly ugly and wordy hack, so I'd personally hesitate to use it for a non-essential purpose in a default stylesheet. Here's roughly what it would look like...
 
input { border:1px solid black; }

, if applied only to text and password controls, would end up reading:

/* for CSS3 (NN, FF, Moz): */
input[type="text"], input[type="password"] {
    border:1px solid black; 
}

/* for IE 5.0+: */
input {
    border: expression(this.type=="text"?     '1px solid black':
                       this.type=="password"? '1px solid black':
                       'default');
}
 
Add properties for each of the four borders separately (to get that nice 3D effect), and you'd start to see some serious bloat.
 
By comparison, targeting a single, added class for both text and password fields would look something like this:
 
input.textfield { border:1px solid black; }
 
 
> for the moment, I'd rather not have to use classes for each of 
> the different form widgets - it'll never ever get applied to every 
> single thing - the buttons are bad enough, but it makes you have to 
> stop and think.
 
If you're questioning whether it would get applied to every single thing in the current version, all I can say is that my work here would be very, very thorough. :-) Do you mean that you don't want to have one more thing to remember when you're writing a new template or updating/adding code once I'm done with those revisions?
 
The reason I ask -- and the reason I'm in favor of adding those classes in there -- is that they would add functionality (a greater ability to customize) without affecting any existing function or aesthetics; and because fixing CSS bugs (like the form-widget height/alignment bug Alfred mentioned earlier today) or adding future CSS functionality (like the possibility of including more than one template to choose from in future releases) would be severely limited, if not impossible, without being able to "hook into" and style those different <input> types individually.
 
My question isn't rhetorical; I'm genuinely interested in your thoughts on this.
 
 
> I'd rather accept the consequences of the current 
> stylings, or take out the css that's causing it - whichever the 
> majority thinks is best - I'm leaning towards accepting the 
> consequences, as IE 7 is coming out soon :)
 
Well, if these are the only options to choose from, ...I'd actually lean the other way. [Gee, isn't having a new developer fun? ;-) ] My reason for that preference is one of usability over aesthetics.
 
Here's a screenshot of the current IE/Win radio buttons :
 
 
 
The first problem is that some less-worldly visitors may not realize that they are buttons. After all, they don't look like "the regular" (read: browser default) buttons, and they sure don't look like "those fancy" (read: beveled-edge, Photoshop-created) ones either.
 
The second problem is that even when someone understands what they are and what they do, their surrounding borders distract visually, making it a little more difficult to tell at a glance which one is checked. (This is a difficult thing to show you, seeing as you most likely have perfect vision and definitely know what you're looking for, ...but by taking a few steps away from you monitor, glancing away, and then quickly glancing back, you might get a better idea of what I mean here.)
 
...Of course, this is just one man's opinion. I look forward to everyone else's thoughts!
 
 
And while we're on the topic of CSS functionality: I was also thinking about adding a couple of extra id's to the templates: id="Breadcrumbs" was the main one, although id="RSSlinks" might be a possibility too. This isn't because anything in either the current breadcrumbs or RSS/Atom links need changing (that I can see, anyhow!) but simply so that designers could more easily customize those page elements without digging into the .tmpl files themselves.
 
Any objections to this? And if not: Any other page elements I haven't thought of? (...No, I won't be adding that sort of CSS hook to the non-Pro-Dada footer, thankyouverymuch. Anything else?)

Post:
mailto:dadadev@PROTECTED

Unsubscribe:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/u/dadadev/

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

Archive:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/dadadev

 
rss/atom
‹ New Coding Styles Doc
Index
Re: New Coding Styles Doc ›
  • 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.