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) {
		el.observe("click", function(event) {
			window.open(this.href);
			event.preventDefault();
		});
	});
});

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.