solidhex.com

Since my post on opening external links with jQuery has proven popular, I thought I would port that same technique to Prototype. Yes, it’s just as laughably trite of an example, but hey, it gives me something to write about.

My example will make use of the dom:loaded event, which fires once the document has finished loading, excluding images:

document.observe("dom:loaded", function() {
	$$('a[rel~=external]').each(function(el) {
		Event.observe(el, "click", function(e) {
			window.open(this.href);
			Event.stop(e);
		});
	});
});

Like I said above, dead simple. We’re perusing the document for anchor tags containing the rel attribute external, registering a click event to the anchor tag, opening the link in a new window, and finally, stopping the browser default action, which in this case means following the link.

It’s slightly more verbose than my jQuery example, but it gets the job done just the same.

How Design Can Save Democracy has been generating a lot of buzz lately. After all, it has been roundly recognized that some folks found the 2000 General Election butterfly ballots confusing, so why not let designers address the issue?

That’s a good start, but why stop there? Why not move voting online? We can already do our taxes online and that’s much more sensitive and private data then a hacker finding out which gum flapping bag of hot air I voted for. What could possibly go wrong?

I suppose a malicious user could game the system to vote for a particular candidate or proposition multiple times. But someone could also steal your Social Security number from your online bank account, open a bunch of credit cards and retire fat and happy in the Cayman Islands.

Since no one keeps their politics private anymore anyway, what about tweeting our votes? People already plaster stickers of their favorite candidate all over their hybrid’s bumper like it’s the local basketball team so why not increase the exposure to millions of users rather than just a few fellow motorists? And while I am on that topic, it’s safe to remove those Kerry/Edwards stickers now. You know who are.

With that voting mess all sorted out, we can now focus on something much more important - the release of Firebug 1.2. If you’ve been using one of the beta versions (1.2.0b1-15) with Firefox 3 I highly suggest you update now and start enjoying the good life.

Sensei Resig has a write up about it over on his cyberspace if you want the lowdown.

Of all the questions I get in regards to HTML and CSS, one tops the list by a wide margin (couldn’t resist a cheap pun); what’s your workflow for building out a page template?

There is a good reason for asking this, because doing things incorrectly in the beginning will no doubt come back to bite you in the arse at some point in the development phase.

The fact of the matter is, there are lots of things to consider besides code. Down below you will find a general overview of the thoughts that go firing around my brain whenever I sit down to carve out my latest slice of hypertext pie.

Always Allot Bug Fixing and Tweaking Time

CSS and JavaScript support in browsers is eons ahead of where it was just a few short years ago, but let’s face it - the dream of coding once and having it work everywhere is still nothing but a hallucinogen induced fantasy. Figure out a percentage of how long it generally takes you to plug the holes in a fussy browser and tack that on to your total estimated development time. I suggest somewhere in the neighborhood of 10%.

Try Thinking in Terms of How Much You Can Get Done in a Day, Versus in an Hour

A lot of times we get caught up in what I like to call the Hours Game. Typically, project managers, clients, bosses (or whoever you report to), need to know how many hours something is going to take you to complete. It sounds reasonable enough. You know how many hours are in a day, you know how many hours in a day you work, so on and so forth, so it should be pretty easy to ballpark how many hours it will take you to recreate a Flash site in HTML.

There’s just one problem - the longer you work, the less efficient you become.

Let’s say you give a quote of 40 hours and you typically work a 50 hour week (minus lunches). By this rationale, it seems a safe bet to think that if you start first thing on Monday morning, you should be done by end-of-day Friday.

That’s what theory tells you. But in reality, you will probably be done closer to Wednesday. In my experience, I’ve found that developers can generally only get 4-5 highly productive hours cranked out on a given day. That’s not to say that the rest of the time is spent looking at lolcats (there is this thing called email), but it’s impossible to operate at the same high level from dawn to dusk. If you find a developer who can, you’ve struck Texas tea.

Pick One Browser to Develop In

Almost any client side engineer will tell you to develop in one browser first, then test on other browsers and platforms later. He or she may take that a step further and highly recommend that said browser be Firefox. One word: Firebug. ‘Nuff said.

You want to run your CSS in the most compliant browser available to you, but there is one major caveat - make sure you know your target audience. I wouldn’t recommend using cutting edge CSS techniques if 50% of your users are a dog’s year behind in technology and are still using IE6.

Markup and Style a Wire Frame of the Document’s Structure

I am using wire frame here to refer to the basic outline of the page which includes elements like the header, sidebar, footer etc. One thing you do not want to do is start obsessing about the micro details at the outset. There are bigger fish to fry. At this stage, you need to look out for any serious flaws or drawbacks in the design. Is the content dynamic or static? Does the layout need to be fixed, elastic or fluid? You’d certainly rather know that type of info upfront rather than coding out 200 pages to find out the header needs to flex when the user resizes her screen.

Plus, if you get carried away fiddling with line-height and letter-spacing for two hours up front, I can promise you will be like a runaway locomotive roaring past your deadline. At this point, just make sure you have the skeleton of your page.

Keep Your CSS Tidy

Most of your time will be spent in the CSS files, so it’s important that you have a structure that makes sense to you (and others if you are working on a team). Smashing Magazine has put together and exhaustive collection of ideas and tips for doing just this, so check it out for some ideas. As with most suggestions, some are purely subjective - such as reset and typography style sheets - while others, like flags, will be quite handy when you need to quickly navigate through a large CSS document.

The Devil’s in the Details

Finally, once your page is fully marked up and your base styles are in place, it’s time to make that HTML proud. Try to write as many of your rules as you can before checking in the browser. The more you check, the slower you will work. I like to check after I finish off a section or module, then tweak from there. Alternatively, some people like to code directly into Firebug and see their results in real time.

If you’re the obsessive type like myself, you may then want to take screen caps and compare them to your comps so that you can be sure that text line-heights and margins are precisely as the designer wishes. I spend A LOT of time refining my HTML/CSS but it’s worth it - in the end everyone is satisfied.

Test and debug

By far the most tedious of the above listed activities but perhaps the most rewarding. Who doesn’t get an elevated sense of self worth from setting bugs to ‘resolved’ in a bug tracker system? It can be maddening to spend 3 hours fixing a positioning bug in IE, but once it’s fixed, your breakfast will taste sweeter than it ever has before.

That three hours is exactly why we’ve factored in bug fixing ahead of time. Some bugs have well documented quick fixes while others can take a full day, which is exactly why we’ve accounted for this up front.

Design Review

Once I have all the comps transformed into glistening HTML files, I send them off to be carefully reviewed by the designer. If you can please the designer, the client will be a walk in the park. Remember: it’s their blood, sweat and tears too, so they want everything to be ‘pixel perfect’. It’s your job to get as close to that as possible within reason. Once your both satisfied, it’s time to ship that puppy off to the client and recollect what’s left of your sanity.

JavaScript has become much easier to write over the past two years with the help of top notch libraries such as Prototype and jQuery. Before getting my feet wet with either of the two aforementioned heavy-weights, I spent my time slugging it out with tedious DOM methods and ‘vanilla’ loops. It was certainly time consuming, but I knew exactly what my code was doing and would still know what it was doing six months from then.

Now, much like the rest of the world, I can’t seem to get by without jQuery or Prototype to do most of the heavy lifting for me. This is all well and good, but if/when the occasion arrives when you can’t rely on a library to plug all the holes for you, you might be surprised how much plain ole JavaScript you’ve mis-remembered.

I certainly was. I had to lean pretty heavily on the ole Rhino book - which by the way, is a book no serious JS scripter should be without - because I had forgotten stuff I used to be able to do in my sleep.

So, as a healthy exercise, I think it’s a good idea to try and write some scripts without using one of the fantastic libraries and frameworks out there, so you can spend some quality time reacquainting yourself with JavaScript. In fact, if you have some time to kill, you might want to run through Chris Heilman’s JavaScript course and work on the demos. Though the course is a few years old by now, the exercises are still worth taking a shot at to keep your skills in check. It’ll force you to think a little bit differently once you can’t rely on CSS selectors to whiz up and down the DOM tree for you.

Don’t worry - I am not suffering from a fit of dementia in which I want to do away with libraries and frameworks - quite the opposite. Why, I even helped debug a famous jQuery plugin. I just think it’s healthy to approach code from a different angle every once in a while and realize how good these libraries make our lives as developers.

Fluidesign, my home away from home, has just launched our new website and identity. We think it’s pretty groovy and we think you will feel the same way.

Of particular note is the fact that users can comment on our portfolio - as we far as we know, no other interactive agency allows this type of public discourse on their site. We like to encourage people to give us feedback wherever possible, and this puppy is no exception.

The team is still ironing out some kinks, so if you see something funky, get in touch.

I think I can safely speak for all of us at FD World Headquarters that we are amped beyond all belief to have this sucker live. The previous version of fluidesign.com served us for roughly 3.5 years. It did it’s job, got us clients and put our name out there, but after a while, it simply didn’t feel like us anymore. Now, we’ve been refined and reloaded.

Here’s to the next four years.

Update: QBN has featured our new site, woo hoo! Check it out.

If you’ve launched a large site recently, you may find yourself surprised at the amount of traffic IE6 drags in. In some cases, as much as 18% of our user base for large sites has been using the lil browser that could. It’s even more shocking considering these are cutting edge, community based sites. This breeds one (okay, maybe more than one) unfortunate drawback - lack of transparent PNG support in IE6. I don’t know about you, but I simply can’t live without transparent PNGs.

Fortunately, there are several work arounds. Even more fortunately, there is an updated version of a well known PNG fix - IEPNGFix 2 - and according to Angus Turnbull, it now supports background position and repeat!

via Ajaxian

The ‘clearfix’ or self-clearing method as published at Position is Everything, is my favorite method for clearing floated elements. My only quarrel with it is that it requires you to add the class ‘clearfix’ (or whatever you have renamed the class to) to the parent container of the floated elements. While this is not such a big deal if you only have one or two containers that require the class, it can quickly get unwieldy in a document that has multiple containers embodying floated elements that need to be cleared.

My preferred method is to add the necessary clearfix rules to each element as needed in the external CSS file. It helps reduce ‘classitis’ and keeps the HTML document from getting cluttered with extra class names that have no structural meaning.

For example, if there were, say, 5 divs that needed the clearfix technique, we would apply the following rules to our style sheet:

#div1:after, #div2:after, div#3:after, div#4:after, div#5:after {
	content: ".";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

And we’re done! Well, that is if we don’t plan on supporting IE6 or IE7. Those two browsers require some additional rules to cooperate because we need to trigger hasLayout for the auto clearing to kick in. Fortunately, that’s pretty easy to do:

#div1, #div2, div#3, div#4, div#5 {
	min-height: 1%;
	display: inline-block;
}

min-height alone will do the trick in IE7, but it’s older sibling needs more help, which accounts for the display: inline-block; bit. The above should be included in our separate IE style sheet so that only IE 7 and below see it. This will keep FireFox 2 from chucking up errors in the console when it doesn’t understand the inline-block; rule we’ve applied to the global clearfix class, plus it has the advantage of keeping our IE hacks, filters, patches etc. from overriding anything in our master style sheet.

But, wait there’s more! If we don’t want to use the clearfix method and we STILL want a self-clearing element, we can also apply overflow:hidden; to the element shrink-wrapping the floats. One thing to beware of here though is that negative margins won’t work. I first discovered this handy trick courtesy of Jonathan Snook’s Top CSS Tips write-up.

In a similar fashion, setting overflow: auto; also seems to work. This technique can produce unwanted scrollbars if not used with care, so be on the look out for that. Alex Walker covers this technique in some detail in his article, Simple Clearing of Floats.

Ultimately, there are lots of options for clearing floats - usually the task at hand dictates the best technique. Call me old fashioned, but I still like to include a rule in my master style sheet that will apply to a non-semantic element in the HTML document, just in case I need it. You’ve all seen this guy before:

.clear {
	clear: both;
}

I keep him around in case the parent container of the floated elements experiences unwanted vertical margin collapsing. I generally use this pretty sparingly, but on a large site, it could turn up in the source code here or there, causing someone to poke me in the ribs and ask why it’s there. Now you know. And unless I’ve been misled up until now, knowing is half the battle.

Sometimes as front-end developers, we have to use a little necessary evil. When that happens, learn to forgive yourself and move on: your therapist will thank you.

Eh, this probably seems inexplicably lame to the casual observer, but Teddy Ruxpin is something of a cult hero around the office. Maybe we just have too much time on our hands…

A tried and true use of JavaScript is to open external links in a new window (or tab, depending on your preferences). I’ve come across countless scripts written to do this task, and even though some are using jQuery or Prototype, they are not making the most out of the library or framework they are using.

Basically, there are three ways to open an external link in a new window:

1. Give the a tag a class of ‘popup’, or something to that effect, iterate through the links and open those with class of ‘popup’ in a new window.
2. Set the rel attribute to external, and again, iterate through the links in the document, find the ones that contain this attribute and value pair and open the links in a new window.
3. Iterate through all the links in the document, check to see if the href contains the current site’s URL and if it doesn’t, pop it open in a new window.

For this example, I am going to assume my links are marked up like so:

<a href="http://google.com" rel="external">google.com</a>

With jQuery, there’s no need to iterate through each link and test for the rel attribute, and it exists, test for the value external. You can simply use CSS selectors to grab only the links you need without having to loop over them, then simply apply the Click Event Helper directly to those links like so:

$(function(){
	$('a[rel=external]').click(function(e){
		open(this.href);
		e.preventDefault();
	});
});

That’s what I like about jQuery - you get in, get what you need and get out.

At Tripkick, we aim to take the guesswork out of your hotel experience. Not all hotel rooms are created equal, so we sought to devise an online concept which would deliver more choices to travelers.

Early Monday morning, Tripkick.com was unleashed to world.  Cédric, David and myself handled the code while Amanda Halbrook designed it to look beautiful. They’ve already been written up on TechCrunch and featured on NBC to much good praise, so a hearty congrats and a round of back-patting are in order for both Tripkick and Fluidesign.

Having recently started to travel more frequently to various web conferences, I have been thumbing through the hotels in the most frequented cities of the top conferences: San Francisco, New York, Austin and Boston. Because really, who DOESN’T want to avoid the dreaded ice machine and it’s guttural roar as it springs to life providing the much needed ice for my Champale?

I sure do.