Tuesday, January 8, 2013

Fun Things I (Re-) Learned About IE CSS

We're building a customer's web application, which means I've been getting my hands dirty in CSS again. Our front end stack is pretty standard: Sass, 960 Grid System, and Compass. I frequently use bootstrap but here the design just doesn't work with it.

Now, I have two confessions to make that are relevant:

  1. I'm a mac user.
  2. The designer we're working with on this one has an aesthetic that I would call "application-oriented corporate clean".  (This is a compliment, I swear!)
The design language calls for gradients in a lot of places for texture, uses rounded corners and button edges, and favors text on whitespace over controls and cluttered layouts. 

So I went along styling things, and I think it looks pretty good. Here's what it looked like in Safari and Chrome:

Not too bad! There's still some polish needed, but it's looking pretty nice.

Then I launched Internet Explorer (this is IE9), and here's what I saw.


Oooops. Forget polish. That's just ugly. A few hours later, I've got it looking better. There were some fun things I learned (or re-learned) about IE9 CSS along the way. The rest of this post shares the changes I made to get Internet Explorer up to snuff. Note that I've just included the Compass includes where I was using them.

No Image Borders
The logo had that purple image border. No, I don't know why it does. Let's get rid of it. Just add this to the img tag CSS:
border: none;

Create Non-Gradient Backgrounds
I warned you - lots of gradients! IE9 doesn't like gradients. See that header? It looked like this:
@include background-image(linear-gradient(#7184a8, #27486b));

I changed it to look like this:
         background: #536d96;
@include background-image(linear-gradient(#7184a8, #27486b));

Notice that the background color is neither the start nor the end stop color from the gradient. It's in between the two. Also notice that I specified the background first.

IE9 Doesn't Like Text in Button Tags
This showed up with no text at all on the button. The text was in the DOM but it wouldn't display.

This worked like a charm:

jQuery Required for Placeholders
We use placeholder text in a few forms (not shown in the screenshots) for questions that might be confusing. Too bad placeholder is an HTML5 thing that isn't supported on IE9 and earlier. Unfortunately, you have two choices: put the text elsewhere on the page, or use JavaScript to set values. I added the jQuery placeholder plugin and a little bit of CSS styling, and it magically worked. (whoo hoo!)

And we're done! Sure, IE doesn't look quite as polished without the gradients, but it's at least not hugely bad. Just four things take"yikes" to "could use polish". It's amazing how big a difference just a few things can really make.

Friday, January 4, 2013

On Resolutions

New Year's Resolutions are hardly a new phenomenon. They're ubiquitous in our daily lives. Everywhere you turn magazines and TV shows and friends and family are making resolutions and encouraging you to make resolutions: lose weight, exercise more, give up smoking, tidy the house, get organized, be a better friend, laugh more, get that raise, find a new and better job, etc.

It gets tempting to make work resolutions, too, either individually as a team. THIS is the year we finally get serious about technical debt. This year we resolve to not let product management impose arbitrary deadlines. This year we're going to pair program at least 25% of the time. Work resolutions are great. They're basically goals, and goals are good things in general. They give you a direction and something to strive for as a team.

January is a terrible time for work resolutions.

Think about all the things going on during January at work:

  • Those year end projects that didn't quite get finished are now really urgent so they still count toward last year. (No kidding - I have more than one client that counts the end of the quarter as January 15th for bonus and goals purposes.)
  • The business is often making annual and quarterly goals
  • It's roadmap update time: the 6, 12, and 18 month roadmaps all need a quick refresh
  • People are still rolling in from vacations at the end of the prior year
  • Finance is doing end of year close outs and bugging everybody for final paperwork and expense reports and whatnot.
  • Many teams have new members or offer internal reshuffles around this time.
All of that activity means that in January you're spending less time doing your day to day job and more time dealing with the activity. This isn't a bad thing, but it's the state of the work world. Adding work resolutions on top of that, though, is a recipe for failure. Sure, we'd love to pair program more, but we've got 4 hours of meetings today, and can't get two people at a keyboard for longer than 30 minutes.  Yes, we do need to tackle technical debt, but gosh, we just sat through a presentation of the quarterly business goals and truly I don't know what that means for development.

All that conspires to make sure that we're not going to succeed at our new resolutions. There's a lot of change going on. There are more distractions than normal. It's just not a good environment to succeed.

So don't try. Don't make work resolutions in January.

Make work resolutions in April.

By April, we've all achieved a routine.  Things are back to normal, and we have a good idea of how busy we're going to be (so just how ambitious was the business back in January?). April is a good time to make resolutions that you'll be able to keep. You'll know how much you'll be able to work together, and how much technical debt you really can tackle among the features you're being asked for. In other words, you'll be in a position to make resolutions you can keep.

And making resolutions is good, but keeping resolutions is great.