somedirection » Agile Development

Debugging Internet Explorer CSS – My Methods

Kyle — Sat, 22 Mar 2008 22:27:47 +0000

I recently spent the day debugging Internet Explorer. I save it for the absolute last step in front end development before pushing a site live. I want to avoid Explorer as much as possible.

I figured my process would be worth sharing. This is my setup.

MacBook running Firefox with the Web Developer Plugin and Firebug plugins installed.
Old Toshiba Laptop 1.8ghz barebones Windows XP installation with IE6
Parallels installed on the MacBook with IE7 on Windows XP SP2

With this setup I can test for any modern browser with any kind of significant market share.

Firefox Mac
Firefox Win
IE 6 + 7 (soon to be 8 as well)
Camino
Safari

Debugging IE issues is probably the most painful thing about my job, but one that’s made a little bit easier because of my approach so I thought it’d be useful to share.

I develop 9-5 in Firefox so any rendering bugs usually come to my attention right away and I’ll fix them immediately. Camino is based on the same Gecko rendering engine so I don’t have to worry about anomalies there. Safari does a good job rendering everything and my colleagues use it as their day to day browser so we usually catch any rendering bugs that way.

Then it comes down to IE debugging. I only concern myself with IE6 and above, I can handle well for modern browsers, besides the market share of browsers that fall outside this range is really insignificant statistically. For small development teams it’s hardly worth the extra effort to pay attention to the long tail of browsers.

Looking at Google Analytics for a heavy traffic site that I work on:

5.6m Visitors from 8/1/07 – 3/20/08

IE is still dominant – so testing for these browsers is essential.

If we look at the last 6 months, IE7.0 and IE6.0 are neck and neck ~50/50, however:

In the first 3+ months of 2008 you can see that IE7 has taken a significant leap above IE6 in the market 61/39 and IE 5.5 has gone to a 0.12% market share to a meager 0.07% market share.

That leaves us only concerned with IE6 and IE7 (and hopefully upcoming IE8 will be a non factor). The best way to deal with CSS and IE is by leveraging something called conditional comments

Before conditional comments I relied on browser hacks to differentiate between browsers, but conditional comments are a lot easier and so much more effective. Currently I use these declarations:

<!--[if IE 6]>
<link rel="stylesheet" href="/stylesheets/ie6.css" type="text/css" />
<![endif]-->
<!--[if IE 7]>
<link rel="stylesheet" href="/stylesheets/ie7.css" type="text/css" />
<![endif]-->

I start with IE6 and clean up any rendering issues – then I move on to IE7, which invariably has fewer issues to deal with. Because IE does not have a handy dandy tool like Firebug to help me diagnose the problem this process usually involves a lot of trial and error. It’s a very iterative process and one that my Agile Development Workflow is well suited for.

One technique I’ve found to be indispensable is assigning various background colors to the markup that I’m trying to debug. Often this is all I need to target CSS rules run amok. Over time you can avoid generating certain CSS + HTML that will break IE altogether – and that’s what separates the experts from novices.

Was this helpful? How do you approach debugging CSS in IE? Share!

Agile Development Workflow Part 2 – Love the sync

Kyle — Sat, 12 Jan 2008 05:13:26 +0000

Continuation of Agile Development Workflow Part 1 – Setup (I’d start there). My lively-hood depends on the sync. It’s really what pulls all my projects together and unifies my workflow. It allows me to develop in numerous web technologies like Ruby On Rails, PHP, Django, Catalyst with relative ease, all at once. The Sync process is based on customized rsync commands. Assuming that you set up ssh properly (see Part 1), all we have to do now is create our shell script that does the heavy lifting for us. Essentially we’re pushing all of our changes up to the server as we see fit. Rsync can be customized to upload only the files that change with relative ease.

The first thing we’ll want to do is create the sync file which will be responsible for handling the rsync process. In the command line do:

macAttack: kb$ sudo touch /usr/bin/sync 
macAttack: kb$ sudo chmod +x /usr/bin/sync 
macAttack: kb$ mate /usr/bin/sync

You should be staring at an empty file. What we want to do is replicate the process you would usually do to push the site up live, or upload it to your development server via ftp.

It’s important that you have a consistent directory structure for your websites to get all of these “rules” setup (assuming that you’ll be working with multiple sites) properly. It will allow us to setup new rules with minimal effort.

I use Subversion (svn) for all of my projects and because of this I have a common directory structure for most of my web apps. It looks like this:

macAttack: kb$ /Development/Project/trunk/

For branches the directory structure looks like this:

macAttack: kb$ /Development/Project/branches/name

The beauty of syncing is all changes get moved over, overwriting the previous files so you rarely run into any sync errors and if you do it’s usually user error.

Here are the contents of my sync script (simplified)

#!/bin/bash

REPO=""
SRC=""
BRANCH=""
DEV="Development"
HOME="/Users/kb"

case $1 in
    s) 
      rsync --exclude-from=$HOME/.rsync-exclude -e "ssh" -ruv $HOME/$DEV/somedirection/trunk/blog/  serveradmin@mediatemple.com:~/domains/somedirection.com/html/
        exit
        ;;
    *) echo "Unrecognized"
        ;;
esac

Let’s break it down.

–exclude-from=$HOME is setup to be the same path that relates to ~/. In my user home dir ~/ there’s a file named .rsync-exclude, this file is a line-break separated list of filenames we want to exclude in our sync. Check out my exclude list » rsync exclude. The exclude list prevents .svn (subversion dir’s) from being pushed to the remote server, so you can work on a checked out copy of your web project, but the server only gets what it needs without any unnecessary files.
-e “ssh” tells rsync to go over ssh to sync the files, since we already set up ssh to enable auto-login to the remote server we won’t be prompted to provide a password on every sync (and you will sync alot).
finally we pass the parameters -ruv -r, –recursive recurse into directories #this way you only have to pass a top level path -u, –update update only (don’t overwrite newer files) #it’s important that your computers internal clock matches the remote servers -v, –verbose increase verbosity
The Local Path: $HOME/$DEV/somedirection/trunk/blog/
The Remote Path: serveradmin@mediatemple.com:~/domains/somedirection.com/html/ => username@remotehost:remotepath

If the following command is run from from Terminal:

macAttack: kb$/usr/bin/sync s

Rsync is a powerful tool, can work wonders with backups as well.

Let me know if you found this article helpful and give feedback. Stay tuned for Sync integration with TextMate that will really put your whole dev process in overdrive!

Agile Development Workflow Part 1 – Setup

Kyle — Mon, 28 May 2007 00:54:25 +0000

The cornerstones of the agile development workflow I’ve developed over time are speed and flexibility. As someone who has fallen in love with his mac and refuses to work on any other operating system – I’ve had to adjust my workflow for whichever frameworks I’m working with.

This workflow will be of no use to 9-5ers that punch in and out promptly, who work only on a company provided computer and exclusively work with Active Server Pages and other web technologies circa 2000. If you have a passion for the web and web technologies – this will meet all of your needs (and possibly desires).

I have had to work with many co-currently, from working with .net applications (yumdrop) to perl applications (quibblo) and php based solutions (this blog), etc. I needed something that was flexible and fast, that I could use at work or at home (I work on my MacBook Pro exclusively), with a speed that would not interrupt my development process – I make changes fast and frequent. Plus – I am a front end web developer – so I don’t have to worry about developing with IDE‘s (RIP VisualStudio.net) – TextMate is my monkey wrench.

I’m splitting up this series over numerous posts – I believe it’s just too much information. Once I get all the information maybe I’ll release a condensed version but I think a walk-through will serve everyone equally well.

The Connector

The first thing that is required is a way to build a bridge. Since I work mostly on remote servers (although this is not required) I run some automation scripts over ssh. The problem with ssh or any remote login is the dreadful password prompt. What good is automation if you have to type in your password everytime? Luckily ssh allows you setup your account in a way that will give you access to your servers sans password.

Setup Time

Since this is an agile dev workflow that is catered towards Mac users – I’ll assume you have ssh available by default.

Fire up terminal (I prefer iTerm)

Navigate to

~/.ssh

macAttack:~/.ssh kb$ ls
idrsa          idrsa.pub      known_hosts

Upload your

id_rsa.pub

file up to the root folder of your remote ssh-enabled server via FTP

This is an IMPORTANT step. If you are logged in via ssh do not copy and paste your key – it won’t work!

ssh username@server.whatever

In the directory you uploaded your idrsa.pub file – run the follow command:

cat idrsa.pub >> ~/.ssh/authorized_keys

This will append your computers public rsa key to your remote computer

authorized_keys

file

Test it out! disconnect and reconnect – it should be automatic!

If I lost you, I found these resources that go into a bit more depth of the setup process and may clear up any confusion:

Setup Complete!

If you got tripped up feel free to contact me and I will try to help you out.

Watch for updates here: Agile Development Workflow Series

Next in line: Agile Development Workflow Part 2 – Love The Sync

The Most Agile Web Development Workflow – Ever

Kyle — Thu, 03 May 2007 03:59:43 +0000

Over time, I’ve developed a perfect workflow for all of my web development needs. My MacBook Pro has become the epicenter of my dev universe. Below are just a view of the frameworks I have worked with.

Asp.Net
Catalyst
Ruby On Rails
PHP

Whether I’m developing on my local host or a remote server, the workflow can adapt to the situation. I’m going to split this up into a 3 part series; this is just the teaser. Consider yourself teased!

Watch for updates here: Agile Development Workflow Series