Scenario: You’re working on a web application or web site with a number of other developers and designers. Everybody is responsible for her/his modules, but in the end, everyone needs to adhere to the company’s look-and-feel.
If you’re working for a start-up, where nobody has time to write a style guide, and the delivery date was supposed to have been two days ago, that means, everybody is going to run into situations in which certain page elements need to be styled just a little bit differently than they are on all the other pages. Sounds like chaos, but it can happen. For example, your team might have assigned a standard width to <select> elements, but then you end up building the payment page, and you need smaller <select> fields for, say, the expiration month and year.
Even though you may give your <select> elements specific class or ID names, if there’s a “global power CSS” somewhere that sets the styles for <select> elements, you could be hosed.
On top of that, the three other designers/developers on your team need to have the width of the <select> element to be set to auto, of course. So your page looks something likes this:
Chaotic Form Fields
There are a number of solutions to address this issue. For example, you could specifically target a <select> element, based on its position in the document, considering the surrounding elements, class names and IDs. Or you could target the form, and then count which nth-elements the <select> elements are and try your luck that way. You could get as specific as possible and precisely define the entire element, class, ID chain leading to the select element (but that’s overkill and can lead to other problems).
Several similar approaches to the ones mentioned above all have one thing in common: What happens if somebody moves the form elements around? Or what would happen if additional form elements got added somewhere before the <select> elements? Then the hierarchy is no longer accurate and you’re back at square one.
Now most seasoned CSS designers would advise you to use classes or IDs for those particular elements, and that makes perfect sense, of course. Actually, I would presume that you’ve done this all along. However, that in and of itself does not always solve your problem. Especially when you’re using a third-party CSS framework, such as bootstrap.css, for example.
At least in my experience, I have found it difficult to “escape” or “override” the confines of bootstrap.css for one-off solutions. Too many CSS definitions for the <select> element. (If you want to check it out yourself, just open up bootstrap.css and search for SELECT, and you’ll see what I mean.)
Of course, I can already hear several readers protest, “But why use bootstrap.css in the first place?” Let’s just say it is there, and you’re ranking very low on the totem pole, so there’s not much you can do, for argument’s sake.
Scope: Most likely however, you will be able to add an opening <div> at the very top of the document (even if you only get to work on a template file that represents the web page’s contents) and a closing </div> at the end of the document. Typically, I simply add a class name to that <div> to represent the page (or the module), like so:
|
|
<div class="pg-credit-card"> |
And that’s it. You won’t do anything else with that <div>. No style assignments or anything. Just let it sit there. (If a <div> causes any kind of a problem, use a <span> tag instead.)
Now you can specify your <select> elements like so, for example:
|
|
.pg-credit-card .expiry-month{ width: 8%; } |
Or use your own preferred measurement unit (rem, em, px, etc.).
What this does is apply a specific width to the <select> element with a class of .expiry-month that is located between the opening and closing <div> with a class of .pg-credit-card.
Now in some cases, you might still encounter problems, and the width of the <select> element won’t budge. In that case, I would first check and see if somebody has hard-coded the width of the <select> element, using inline style attributes. You can use Firebug (or any equivalent web developer tool) to find out stuff like that.
Occasionally, somewhere somebody is running a piece of JavaScript code to set the styles of specific elements. If that’s the case, go put an end to that. If you need to work this out with a co-worker, be tactful and explain to her/him that setting styles should take place in CSS (or LESS/SASS) files. It’s simply impractical to define styles in JavaScript, and in most cases that I have been involved in, that only leads to maintenance and scalability nightmares.
Let’s say you have exhausted all your resources, and the <select> element still won’t budge. In that case, try the following:
|
|
.pg-credit-card .expiry-month{ width: 8% <strong>!important</strong>; } |
Yes, yes, yes . . . I know! Nobody who wears an I HEART CSS button would ever do anything like that, leave alone suggest it to the readers of a web design & development BLOG. However, if that works for you and solves your problem, go for it. It is valid CSS and has been established for a reason – just don’t overdo it with the !important attribute.
Most importantly: Whatever you do, make sure it only affects the page elements on the page on which you are working. You don’t want to cause anyone else the same kinds of problems you have just resolved. Right?
The alternative, of course, would be to have a CSS / Style technical lead, who would reign in all those codewranglerss to come up with a living style guide and a master CSS file that would 1) address the overall CSS and 2) provide special sections for page-specific (or purpose-specific) CSS.
At any rate, if you’re in start-up mode, or if you’re working on the third proof-of-concept design for a project, give the CSS Page Scope a try and see whether that might help resolve some specific CSS issues.
Be well, do good work, and keep in touch!
