Archive for May, 2006

When it’s okay to use ‘blink’

Tuesday, May 30th, 2006

The CBC’s Doctor Who page has a blinking cursor (of sorts) that preceeds the text “Transmission interrupted. Re-initializing…” In this example, for the first time ever, I think I’ve found a decent use of “blink”.

Blink state: on
Blink state: on
Blink state: off
Blink state: off

Memorial Day

Monday, May 29th, 2006

Posted originally as a comment on SonSpring.

Tomb of the Unknown SoldierWar is such a terrible thing, and yet we constantly find ourselves thrust into it by the actions and decisions of a select few. These people believe themselves justified to drag entire nations into battle, indiscriminately destroying not only the lives of those on the battlefield but the countless marriages, families and other relationships of those back home. I wonder if countries would go to war so quickly if the “king” were to still lead his men in battle instead of hiding in a bunker somewhere.

My heart goes out to those who have lost loved ones to war as well as those innocents who are caught in the middle of the fighting—very often in their own backyards. God only knows the suffering people in countries like Iraq have to go through. I have a very hard time reconciling any suffering, especially when it’s for one’s ethnicity or for being born in a country that is inconveniently located. We are so blessed to live in countries that are so far removed from the fighting. But I guess that didn’t make much of a difference for some 60 years ago. :-(

Hooks: How to Keep CSS and JavaScript Separate

Saturday, May 27th, 2006

Fish hooksOne of the defining principles behind the Web Standards Movement is the separation of structure (HTML), presentation (CSS) and behaviour (DOM Scripting) in a document (web page). Meaning of course that all of your content gets marked up as HTML, everything that has to do with the way that it looks goes into style sheets and any behaviour is handled via DOM Scripting (aka JavaScript). As with any such methodology the three aforementioned layers of separation are nice and neat on paper, but when you get out into the real world of web development it can sometimes get a little messy.

Case in point, in a recent conversation with Sarven I was asked whether I thought the :hover pseudo-class in CSS belonged to the presentational or behavioural layer. After all, to “hover” is to perform an action, and an action is behavioural by it’s very nature. So why is the :hover pseudo-class then found in CSS, the presentational layer? To make things potentially more confusing, using JavaScript you can change the presentation of your document via the DOM’s style property collection. So in effect you can affect the document’s behaviour through the presentational layer and vice versa. This then begs to ask: what belongs where?

CrayonsWell, let’s deal with CSS first. After being asked Sarven’s question I thought about it for a moment and realized that no, in fact, the :hover pseudo-class is not so much a behaviour in and of itself as its a behavioural hook exposed to the presentational layer for the purpose of styling elements that find themselves in a “hover” state. In other words, CSS doesn’t handle the behaviour, the browser does. CSS is simply being allowed–by the browser–to style an element that’s in a hover state.

A wrenchThen of course there’s JavaScript’s ability to manipulate the document’s presentation. This is where I believe discretion is necessary. I’m of the mind that unless absolutely tied into the behaviour, all styling should remain in CSS. For example, rather than toggling an element’s display attribute value from block to none and back again in JavaScript I prefer to only toggle the element’s class name. That way I control the presentational aspect of the element in CSS. This keeps both layers as separate as possible by only offering CSS a hook from JavaScript in the form of a class name instead of applying the style rules directly from within JS.

A hand giving a thumbs upSo how do you tell when to write style rules directly from the behavioural layer and when not to? My rule of thumb is to only do so when I’m calculating positions or colours that aren’t simple predefined states–like show/hide. In other words, if the user is going to interact with the behavioural layer and cause it to recalculate position or colour values, then those values should be set via JavaScript. Otherwise I try and steer clear of writing entire sets of style rules directly in JavaScript. Doing that just defeats the purpose of good clean code in separate appropriate layers connected simply by hooks.

Who Killed The Electric Car?

Thursday, May 25th, 2006

The electric vehicle is not for everybody. It can only meet the needs of 90% of the population

–Ed Begley Jr.

Don’t see anything? You’re using IE right? Then try viewing it at YouTube: Who Killed the Electric Car.

Visit the film’s official website: Who Killed the Electric Car?

Get FireBug

Wednesday, May 24th, 2006

FireBug Logo

Any web developer worth their salt will want to have this Firefox extension in their toolbox. Once you’ve used FireBug you’ll never want to work without it!

Some Features:

(features copied verbatim from the FireBug site)

Logging for web pages
Web developers have suffered with “alert debugging” for centuries. If you enjoy clicking the “Ok” button 40,000 times a day, FireBug is not for you. Otherwise, you’ll enjoy having the ability to log messages from JavaScript in your web page directly to the FireBug console.
JavaScript Debugging
Want to stop your JavaScript and step through it line by line? No need to fire up a big fat debugger. FireBug includes a simple lightweight way to set breakpoints in your scripts and examine every step of execution.
Errors at your fingertips
Nobody likes to see errors in their web pages, but with FireBug you won’t mind as much. FireBug adds a little icon to the Firefox status bar which tells you if your page is busted. Open up the FireBug panel and you’re looking at the errors that occurred in that page, and only that page. No more digging through the muddy pile of errors in the JavaScript Console window.
Inspectors galore
Elements and styles and events, oh my. There’s a lot going on behind the curtain of a web page. FireBug’s inspectors let you stroll lazily through the DOM using the familiar hyperlink model of the web. If you see an object reference, you can click it to inspect it.
Command line
If you enjoy “alert debugging” then you probably also enjoy typing “javascript: ” urls in the location bar all day. If not, then you’ll enjoy using FireBug’s JavaScript command line instead.
Ajax Request Spy
If you feel hip every time you fire off an XMLHttpRequest on your Ajax website, FireBug will secure your place amongst the avante garde. The FireBug console can log all Ajax request traffic as it happens, and allows you to inspect the responses.
Live Editing
It’s no fun just looking at the DOM. FireBug’s inspectors let you edit some parts of the DOM. More editing features to come in a future version…

So what are you waiting for? Get FireBug!