Mu-mon-kan

I ran across something new (at least, new to me) today. Using window.location.hash, if the same value is being assigned to the hash, the browser looks at it as a non-operation. The value needs to be reset first before reassigning the same value (e.g. for the purpose of resetting the view to the top of a dynamic list). I’ve noticed this behavior in Firefox 3 and Safari 3+.

I rarely write about coding issues, but it might be a good way to catalog my findings for my own reference. My apologies to everyone else.

Update: I thought this could use an example.

var hashVar = 'content-top';

// ASSERT: hashVar contains the same value as window.location.hash
window.location.hash = hashVar;

// Expected behavior: Window scrolls back to the 'content-top' id
// Demonstrated behavior: Window does nothing

The way that I solved this was to reset the window.location.hash value to an empty string before the reassignment.

var hashVar = 'content-top';

window.location.hash = 'adkcj';
window.location.hash = hashVar;

// Expected behavior: Window scrolls back to the 'content-top' id
// Demonstrated behavior: Window scrolls back to the 'content-top' id

Update 2: Apparently, Firefox, in the latest update, changed the behavior of the hash property. If the value is “zero-ed out”—if you will—the entire page refreshes. I’ve amended the script above so that hash is given a (hopefully) non-id value. Feel free to use a real word, but I didn’t want to take the off-chance of hitting an id I’m using.

I’m not sure how I feel about this. There’s something unsavory about it.

Currently Rocking Out To: Jah Work – Ben Harper

OK . . . I understand the hype and fascination with Web 2.0–which, incidentally, is an unfortunate name since the web itself hasn’t really evolved, just the flavor of applications being run on it, but I guess you have to market it somehow–but I feel the interactivity is being used for trendy, unnecessary, inaccessible, and, sometimes, annoying purposes. I’m constantly inundated with flashing widgets with drag-and-drop functionality for . . . what purpose? Do I go to a website to play with the widgets? Maybe some, but, most of the time, no. Does this functionality benefit everyone? After listening to the EO Webcast today, these thoughts plagued me throughout the day. A great deal of this new technology is used for it’s slick “wow” factor and much of it that could improve the site’s accessibility falls by the wayside. Sure, I can make the site cool for 85% of the world . . . but what does that make the site for the other 15? I know that I sometimes fall prey to time constraints in my own applications. If I don’t have time to make it 508 accessible, then I skip that step. However, I am always XHTML and CSS compliant. Hopefully, that’s half the battle.

Simplicity is not a bad thing. I try to design the way I live. Objects don’t end up in my house unless they have a functional purpose (at least not the objects I buy.) So, I try to model my web apps the same way. Some of the greatest websites are the simplistically functional (check out dictionary.com if you’re looking for a great, recent example how simplicity can improve usability.) I absolutely encourage experimentation and the sharing of ideas and blogs are a great medium to accomplish this. So, by all means, let me know what you think about this issue. I’m not trying to keep anyone from doing cool things, but I am trying to keep the largest number of users in mind.

Currently Rocking Out To: Goodnight and Go – Imogen Heap