Tag Archives: code

The non-importance of !important

Molly Holzschlag raised a good issue via Twitter yesterday regarding the !important rules in CSS, reprinted here in more or less the order in which her tweets appeared thus far:

TwitterPoll: What does this mean to you? !=

TwitterPoll follow-up. What does this mean to you? !=good

TwitterPoll: Let’s remove the equal sign. What does this mean to you !good

yes, yes, I’m asking ultimately how the fuck !important means BANG IMPORTANT when realistically it should mean not important.

re: !important in CSS? Kill it. Specificity to the rescue.

Say it ten times fastL Specificity, specificity, specificity. Forget !important. Write specific selectors sez me. And night night!

I love Twitter. When it is up and running that is… 😉 Such a lively place for discussion.

Random photo of Taroko Gorge from my recent Taiwan trip, just for color.

Molly makes an excellent point here. My little position with the !important rule is that I always thought this to be somewhat of a funny-looking construct. It is just as Molly points out – the exclamation point preceding the word ‘important’ is odd, kind of stuck on there, and is especially confusing to those of us coming from that programming background where the ! means ‘not’ – as in != reading ‘not equal’ and that sort of thing.

The construct itself is generally frowned upon in production-level CSS code. The specificity of the !important rule overrides anything with normal inheritance values, and if your code is littered with it then you really need to go back and look at what your rules are doing with regards to the cascade. A good production stylesheet should be free of any !important rules.

I take from Molly’s tweets that she argues in favor of abolishing the !important construct and that people should use the cascade properly. While I understand this position and agree with it on a philosophical level, I think somehow this functionality should be retained. My proposal is as follows:

  1. Change !important to just important, doing away with the confusing exclamation point and instantly making CSS more legible
  2. Make some declaration that user agents should ignore the exclamation point and really just pay attention to the word “important,” for the sake of legacy support. Yeah more detail is needed here, but you get it.
  3. Make validation issue an explicit warning stating that important should only be used for debugging purposes.

How this would look in the wild:

#hyrule {
  color:blue important;
}

Not a big change really, but it gets rid of the somewhat confusing exclamation point, gets us more towards the ideal which is reduced abuse of the rule in question, and promotes better use of the cascade.

Yes that photo is completely random given the context of this discussion, but I thought it was pretty and it reminds me that I need to do a follow-up on my recent Taiwan vacation… 😉

Dogs and cats, living together. Mass hysteria.

Wha?

There has always been somewhat of a dichotomy in the world of web professionals between design & development.

Designers do their thing making pretty pictures, drinking cocktails at lunch, having social cliques, and little romances within the group. They frolic away in the meadows of Photoshop and Dreamweaver Design View, paying little attention to the nuances of the mechanical underpinnings of their creations. Or so I hear…

Meanwhile, the code monkeys toil away in the dark, unseen from the public eye, in caverns and closets and in back alleys where you dare not travel. Typically found unshaven in the wild, they hack away in text editors such as TextMate and Vim, write their code from scratch, and make jokes about algorithms in C in an Erkel-esque voice from behind Coke-bottle glasses. (Mexican Coke bottles, since apparently north of the border we’ve lost our flair for nostalgia and authenticity and now mostly distribute the plastic bottles which are unfit for ocular correction.)

I’ve had this debate at least six or seven times in my career, in some form or other, about this separation of church and state. Oil and water. Dogs and cats.

Stephanie Sullivan recently wrote this:

The root of my story and my point is — it’s the rare individual that has all the strengths needed for one web site. It’s the team that matters. Should everyone have a basic understanding of the other member’s jobs? How they work? What they can accomplish. Oh yes. Absolutely. Should they be able to do them? That’s just ludicrous. Absolutely not. Surround yourself with people more brilliant than yourself. Always learn. Work hard. You, and those around you, will be enormously successful.

Now granted, she’s posting this in response to the guys at 37signals, who by definition are an opinionated group making opinionated software. That’s why their stuff is so great – they set some constraints and they live by ’em. I’m not sure which posts she was referring to, but this could be one of ’em. And this is true. Designers who have strong developer kung fu are better designers for it. And developers who understand the issues of design are correspondingly empowered.

But I tend to agree with Stephanie. The reality of it is that there are a wide variety of personality types out there, and that translates into varying abilities and motivations for crossing over into the design or development realms one way or another. As a musician, I myself come from a deeply creative side (with some early code hacking expertise in the Atari days,) but have come around to being mostly a developer at this point in my career. I draw heavily on my design background when working today. But I certainly would want to get a good, web-experienced designer on my project. And I think that’s where the core of the debate has led to: Web designers who understand The Code create designs that make better sense within the constraints of the digital medium, and understand what the user interface objects are that the web-surfing masses are familiar with. Conversely, pencil-necked code monkeys understanding design principles won’t shackle their creations with masses of cruft and flotsam just because it worked 9 years ago and why not copy/paste that in?

There are so many faceted roles now applied to the web production line. We are all part designer, part coder, part marketing stooge, part librarian. There is no escaping that. But if the Industrial Revolution has taught us anything, it is that things will continue to specialize in the name of efficiency and progress. Multitasking sucks. For some of us (moi,) it sucks more than for others. It takes time for the brain to switch gears between the too-sexy-for-my-shirt design aesthete and the l33t h4x0r. Throw having to be a project manager, writer, or manager into the mix and you get all kinds of crazy flying around.

My take on it all is: Embrace what you are good at. Do what your passion dictates. Challenge yourself frequently, but never lose sight of your foundation. If your foundation migrates, then great! But always be aware of yourself and live in The Now™. If you do what you love, you are more likely to get good at it, more likely to stick with it for the long term, and good things will tend rise up around you.

Rails Tip No.1: Making datetime_select more appointment-friendly

This is the first of what I intend to have as an ongoing list of Ruby on Rails programming tips. These are as much for plugging my own memory holes as they are for the general Googlejuice. Each should be a brief illustration of some technique on how to accomplish something in Ruby on Rails – probably in the form of a short code snippet with explanation. I should preface this all by stating that I am by no means an expert on Rails – I’ve been using it since late 2007 – so any urge to expound upon these thoughts by the Lightning Rails Ninjas™ out there would be most welcome indeed. Please feel free to comment.

The first one I’d like to present is how to get the datetime_select helper method to be slightly more user-friendly for your garden-variety appointment form.

Consider you have a form set up already for booking appointments. You may have used datetime_select for the start and end times for your form. The default implementation gives you the current date and time as defaults, and each item is rendered as a select menu.

But rarely would you want to do a new appointment on the same day and at at 12:06 PM, right? More often those things are scheduled at least a day in advance, and on the :00, :15, :30, and :45 minute marks. Or at the very least, having five minute increments for the minute menu should help pare down the options and make things simpler. Here’s an example of how something like this could be accomplished:

For the above example, we have a datetime_select form helper for the appointment_start column in our database. Simple enough – this is probably how a default code snippet would look from say a scaffold generation. Following that, we’ve passed a couple of extra bits of information to our helper – a default date and time, and a specification on how we should increment the minutes column.

:default => 24.hours.from_now does exactly what you’d expect – sets the default date and time for all the menus ahead one day. You could just as easily say three days from now, four years from now, and so on. And :minute_step => 5 gives us the five minute increments that we want. Set it to 15 if you’d like to pin it down to the :00, :15, :30, and :45 minute marks. Simple!

Diff-ing commands on Mac

There are several tools to compare files for changes out there for Mac OS X. I’ll cover a few here. The first and most basic is diff. From the command line, it looks like this:

diff -u old_file new_file

Where of course old_file is the old suspected filename, and new_file is the new one. This will give you a quick glance at what is new. Each line of difference in the new file will be preceded by a plus (+) symbol, and each difference in the old one will be preceeded by a minus (-) Last saved timestamps will appear at the very top of the output.

A cool trick – if you use TextMate, you can pipe your diff output to it and take advantage of TextMate’s fancy-schmansy code coloring:

diff -u old_file new_file|mate

Shift + Control + Option switches Textmate to the Diff bundle, and Shift + Control + Command + D will give you access to the context menu for all of the diff commands. Great for you Lightning Ruby Ninja™ coders out there who insist on never letting the tips of your fingers leave your keyboards.

If you have the XCode Developer Tools installed, you get a second option installed: opendiff, laced with a GUI app called FileMerge:

opendiff old_file new_file

What is cool about this is that if you run opendiff from the command line, FileMerge takes over and shows you your differences with sexy Mac-ness, replete with an array of search and code merging commands at your disposal. That’s hot.

If you like BBEdit, and who doesn’t, you have bbdiff at your disposal too:

bbdiff old_file new_file

BBEdit has a file comparison and merging utility built in which does not suck at all.

Extra Coolness for Dreamweaver users: Select opendiff or bbdiff in your prefereces to compare files with their corresponding GUIs this way:

  • Dreamweaver > Preferences > File Compare
  • Click Browse
  • Select bbdiff or opendiff from the file dialog, click OK, and enjoy.

Lusty. So there’s a few options for finding out what your colleague did to break your perfect code. Happy diff-ing!