These are my actions. These are my words.

Firebug bundle for TextMate

My two most indispensable web development tools are Firebug and TextMate. I’m sure the same goes for many web developers the world round. Firebug brings with it a complete set of debuggers and problem-solvers that is unrivaled by any other application. And TextMate is the little text editor that could (and does). It’s versatility is unmatched. I constantly find myself shuttling between the two in the eternal edit/debug dance we webbies know all too well.

It seems odd to me that there isn’t (as of yet) anything out there that brings these two fan favorites together. If any two applications are deserving of a mashup, it’s these two. So I said to myself, “Self, why not build your own?”

A few hours later, I had myself a bona-fide Firebug bundle for TextMate.

Read More »

So, SXSW Happened…

…and I didn’t make it this year.

Unfortunately, personal events kept me from attending geek nirvana for the second year in a row. Now that participants are back and in a blogging frenzy, it adds salt to the open wound.

But thankfully, fellow webbies Micah and Brion were awesome enough to set this up for me.

What more can a guy ask for? A personal message from one of my web heroes, Jeremy Keith. He has truly been the catalyst I needed to add the third of the Holy Trinity (XHTML, CSS, JS) to my repertoire. If you haven’t read his DOM Scripting book, and you want to get into javascript, you will not go wrong with his book. It should be required reading for it’s easy-to-understand methods and examples.

Personal to Jeremy: You’ll be happy to know I’ve already started doling out your cut. Your Bulletproof Ajax book is as good as advertised, and just as incredible as your previous literary art.

Show love to the <body> element

As you begin to wireframe your next big web thing, it’s a good idea to keep this in mind. The body element can be styled just like any other element.

Let’s get a disclaimer out of the way: I am a markup purist at heart. There’s nothing that tugs at my heartstrings than well-structured markup. So it pains me to see the body element so underused, especially when that #wrapper div you created can do exactly what <body> can.

There are situations where you will no doubt need that #wrapper element, and I’d bet it will have something to do with Internet Explorer. But the remainder of the time, I’d wager that element is just plain expendable. Let’s take a look at an example:

body {
  margin: 0;
  padding: 0;
  font: 76%/1.6 "Comic Sans", Arial;
  text-align: center;
}
#wrapper {
  margin: 0 auto;
  padding: 1em;
  width: 750px;
  text-align: left;
}

Here we have a sample of what I constantly see. Usually, margins, paddings, and maybe a font declaration is relegated to the body element, and then it is left alone to spend the rest of its days in CSS purgatory. Subsequent properties are then added to a superfluous and unnecessary element.

But the same feat can be accomplished with just a body element!

html {
  margin: 0;
  padding: 0;
  font: 76%/1.6 Helvetica, Arial;
  text-align: center;
}
body {
  margin: 0 auto;
  padding: 1em;
  width: 750px;
  text-align: left;
}

Think of the Document Object Model as a staircase. By merely “stepping up” a level and utilizing the oft-ignored element, we save ourselves a wasted element. It may seem like a small thing, but remember that a div element has no semantic value anyway. And search engines will adore you for making sure your content gets to them without crawling through another div.

Cross-browser opacity

With the rapid proliferation of IE 7, I think a closer look at cross-browser opacity is needed.

Please note that I’m not talking about image-based opacity, but rather opacity on any given element. There are articles on image opacity that are still relevant to today’s browsers.

The current favorite method is a combo opacity/filter fix to placate Gecko and Webkit browsers, as well as IE 6 and below. This involves setting a opacity value for browsers that support the spec, and hacking out an acceptable solution for browsers that don’t (read: <IE6). The fix is outlined below:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
      -moz-opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->

As you can see, the code is quite verbose for what it is. Let’s take it step-by-step. The first style block contains the supported opacity properties for Safari and Opera (opacity), as well as Gecko-based Firefox and Camino (-moz-opacity).

The latter block is designed so that only Internet Explorer receives that code (in real-world application, this code would appear in a separate “<IE 6 only” style sheet. The block contains a proprietary property called “filter”, supported by Microsoft browsers. This property is not approved by the W3C, and is therefore invalid. Thus the need to “hide” it from validators and place it in its own style sheet.

While the code is slightly complex, it has served its purpose. But with the evolving nature of the web, its status has changed since this method was concocted. New browsers have emerged, others have updated. Essentially the web has changed enough that we must tweak this fix in order to get true cross-browser opacity. There are a few ways to handle this depending on your preference and whether or not you care about style sheet validation. Lets take a look, first at the browser changes, and at a couple of updated fixes:

Internet Explorer 7

Its characteristics are impressive. It supports quite a bit more W3C approved properties than it’s predecessor. However, the powers-that-be decided that it would not support the opacity properties– not yet, anyway.

On the other hand, IE 7 does still support the proprietary filter property. This means that IE 7 will respond to the same fix created for IE 6.

However, one of the many improvements IE 7 brings to the table is its native support for PNG transparency. This is an important point, as it allows us to devise a fix that will play better for those not interested in yet another conditional comment.

Gecko-based browsers (Firefox, Camino)

Gecko browsers support their own proprietary CSS property, the -moz-opacity property. However, it’s no longer necessary to declare this property, since current versions now include support for the standard opacity property.

So, given these bits of info, we’re left with the following cross-browser opacity methods:

The single conditional comment fix

The simplest method of all these is to simply remove the -moz-opacity property and open up the IE conditional comment to include IE 7. Example below:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 7]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
    #someOtherElement {
      height: 1%;
      margin-left: -3px;
    }
  </style>
  <![endif]-->

While this is an easy solution, it is not often the best. For example, your CC was probably specified for IE 6 and below for a reason. Remember that IE 7 is much more standards-aware than previous IE incarnations, and probably does not need any of the hacks defined in the <IE 6 stylesheet. Thus, you’d most likely have to do some more work hiding those hacks from IE 7.

The multiple conditional comment fix

Another method is to create another stylesheet, and wrap it around an IE 7 conditional comment:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
    #someOtherElement {
      height: 1%;
      margin-left: -3px;
    }
  </style>
  <![endif]-->
  
  <!--[if IE 7]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->

This fix addresses the problems of the earlier fix, but creates additional markup, not to mention yet another stylesheet to maintain. If all the IE 7 stylesheet does is add opacity support, it would hardly be in your best interest to keep it around.

The IE 7 filter fix

There is another way to support IE 7, and that involves using an IE 7 CSS filter to target only that browser:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
    *:first-child + html #element {
      filter: alpha(opacity=50);
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->

This works a treat, but it also carries the inconvenience of invalidating your style sheet.

The PNG transparency fix

This is my favorite method, merely because it eliminates the issues of the first three methods. However, that’s not to say it doesn’t come with it’s own flaws:


  <style type="text/css" media="screen">
    #element {
      background: url("/path/to/image.png");
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->

This method eliminates the opacity property altogether, and instead relies on a transparent PNG to mimic transparent color. Because IE 7 supports native PNG transparency, the fix works for all advanced browsers. The <IE 6 stylesheet is left alone, since it’s PNG support leaves much to be desired.

The downside of this method, of course, is that you lose the ability to easily update the element you are editing. Rather than changing a hex value, or tweaking the opacity value, you’d have to go through your photo editor and change a PNG in order to see changes.

So there you have it, four distinct ways to implement cross-browser opacity. Each with its benefits, each with its flaws. It’s ultimately up to you to weigh those against each other, and choose what best fits your needs.

Bagels vs. Donuts

How does that old proverb go?

You can catch more flies with honey than vinegar.

A peace offering is meant to be a friendly gift; a way of trying to mend a relationship (whether it be personal or professional). It’s a tried and true tradition, passed down from the hunter-gatherer era. Over time, the human race has adapted and perfected this action. Nowadays it is evidently clear when one is presenting a peace offering.

Offerings can dilute over time if repeated by an individual. It is the doom of many relationships. But when done right, an impromptu offer can often become a catalyst towards a friendly resolution. A presenter must choose carefully what, where, and when to give, lest their gesture be thought of as expected or even forced.

This is important because as the presenter, you want there to be no doubt of your actions, and the meaning behind it, so that it is clear that you are willing to atone. It is only natural that the presentee (sic) will then acknowledge the peace offering, accept the gift, and begin the healing process.

This is the tradition inherited from our forefathers. It has been so for many generations.

So, why then, would you pick bagels over donuts as a suitable peace offering?

A note to anyone hiring for a web project

When finished with a web project, it is generally considered polite to thank your web designers and/or developers for the countless hours poured into said project.

These are just general thoughts about life, nothing specifically related to anyone.

A tip on avoiding innerHTML

Not that innerHTML should be avoided at all cost, but I’m currently in a purist kinda mood. Generally I like to avoid proprietary functions whenever possible. Now, sometimes it just makes sense to dip into Microsoft’s old trick-bag and pull this out.

Anyway, as I was making my way through Jeremy Keith’s amazing book, Bulletproof Ajax, this tip came up again and again. It’s not exactly a new trick, but it’s new to me, and it might help out a fellow javascripter:

Let’s say you have a target with a bunch of child elements:

<div id="target">
  <p>I am an example.</p>
  <a href="#">I am also an example.</a>
  <img src="example.gif" alt="I am yet another example." />
</div>

Let’s face it, the easy way to replace those child elements is with innerHTML:

target.innerHTML = newValue;

However, there’s also an easy way to replace the child elements using W3C approved methods:

while (target.hasChildNodes()) target.removeChild(target.lastChild);
target.appendChild(newValue);

Easy as pie! The while loop will continue as long as there’s a child node present. Out go the children, in goes the new value. No fuss, no muss.

Seattle will have to wait.

If you’re one of the three people who actually read my previous post, I either know you in real life, or you’ve scouted me for a possible job opportunity. In either case, thanks for viewing!

In my last post, I expressed my newly kindled love of the wonderful city of Seattle. I was absolutely awestruck by its bustling art community, it’s very unique architecture, and it’s overall diversity.

But Seattle will have to wait.

See, I’ve had an interesting couple of weeks, wherein I’ve explored other avenues of employment. I interviewed for a few companies; some you know, some you don’t. The whole experience was both exciting and frightening. When you start the job hunt, several areas of your persona are thrust to the spotlight. Mainly, you have to place a value on your offered skills, a daunting task for anyone in that position.

Fortunately for me, there was a company that believed enough in my abilities to offer me a more-than-flattering offer. And so I am happy to say that I have accepted a position as a Senior Software Developer at Schematic.

My role at Schematic will revolve around front-end code, i.e., XHTML, CSS, DOM scripting, and web standards in general. It’s a position I’ve been dreaming of for a while, so I am truly excited at the opportunity.

Sadly, this puts the dream of a Seattle move on the back-burner. I won’t kid myself: I’m definitely a little bummed about that. For the past few months, I convinced myself that my next move was the Seattle move. But for now, I’ll consider it a dream yet to come true. An amazing opportunity came along that I absolutely need to pursue. It will allow me to interact with peers among my chosen field, as well as allow me to work for an impressive company.

And hey, Seattle would make a great retirement village. :)