As I've said before, and I'll say again, the last thing the web needs is Buzzword Hell. All buzzwords do is distract from the real tangible ways we can improve the web. So now, I introduce a way you can help save the world from Web 2.0 buzzwords!

Buzzword Hellfire

I just had a look at the WayBack machine for thefutureoftheweb.com. Turns out someone else had it before. Creepy.

Have you ever wanted to prevent a JavaScript event from firing when it has been bubbled up from a child element? For example, let's say you have an onMouseOver event for a parent element. Anytime the mouse moves over any of the children elements, the parent's onMouseOver event will keep firing. Or, let's say you have an onMouseDown event on a parent and another on its child. Both onMouseDown events will fire when someone clicks the child. Sometimes this can be a real pain.

Anyway, enough examples, let's look at a way to avoid this. We need a way to fire an event only when the element with the event handler is the target element of the event. Here's the solution event handler:

function eventHandler(e) {
     e = e || window.event;
     var target = e.srcElement || e.target;
     if (target != this) return;
     
     // the rest of the function
}

Simple enough, once we have the code. Let's look at what it does.

First, we find the event object. In Firefox and Safari, it's a parameter to the function. In Internet Explorer, it's in window.event.

Having that, we need to find the target in the event object. This is the first element the event fires on, the inner-most or top-most element. In Safari and Firefox, it's target, but in Internet Explorer it's srcElement.

Finally, we will compare against the element the event is attached to. The element the event handler is attached to can be accessed easily with the this variable.

For more information on event handlers, I highly recommend the excellent resources at QuirksMode:

• Events order (event bubbling vs. capturing)
• Event Properties
• Event compatibility tables

Update: you need to do a little bit more if you are dealing with mouseout events. If you move the mouse into a child, this triggers the mouseout event on the parent. In this case, the target will match the parent. So, you'll also have to get the 'related' element (the child) and make sure the target isn't one of the ancestors. Here is the updated function for mouseout events:

function mouseOutEventHandler(e) {
     e = e || window.event;
     var target = e.srcElement || e.target;
     if (target != this) return;

     var related = e.relatedTarget || e.toElement;
     while (related != this && related.nodeName != 'BODY')
          related = related.parentNode;
     if (related == this) return;
   
     // the rest of the function
}

Special thanks to QuirksMode's Mouse Events page for helping me figure out that one!

I know, this question has been answered thousands of times. Even still, nobody can agree on what it is exactly. Here's my take.

Web 2.0 obviously implies the "next version" of the web. Ask Tim O'Reilly (who coined the term to promote a conference), and he won't really be able to summarize it either. He'd rather define it by example. DoubleClick is Web 1.0, Google Adsense is Web 2.0. Personal websites are Web 1.0, blogs are Web 2.0. Content Management Systems were Web 1.0, wikis are Web 2.0.

Web 2.0 is said to include everything from tagging, Ruby on Rails, AJAX, peer-to-peer, RSS, the perpetual Beta, and user-contributed data. Let me propose this: Web 2.0 includes anything that was done successfully on the web in 2005. There, I've said it. Now, I'd like to propose something else: Let's focus on the different ways the web has improved, and let's never use the term Web 2.0 again. Seriously, starting right now. Who's with me?

Having said all this, the many different definitions can finally be read without that nauseous feeling. Don't worry any longer that your website is running the wrong version of the Internet, just relax and take a look at how far we've come. It's not worth much to say "This website follows the new trends in web sites, this one doesn't". There's certainly no need to start a new industry over it. Instead, let's just see what works and what doesn't.

If we spend all our time defining such a vague marketing term, we're going to severely miss the point. There is no Web 3.0, and there needn't be a Bubble 2.0. We have a lot of really great examples to follow, and there's still a lot that hasn't been done. So let's just keep doing what we do best.

So let's see what we can do with Folksonomies, let's find things every web site can learn from blogs, and let's see what new directions we can go in in the future of the web.

Over the last few posts, I've been trying to redefine "Web Standards", or rather, expand the definition to include things outside the validation of HTML and CSS. I wanted to talk about the larger picture of doing things the Right Way. Then, Jim left this comment:

I have to admit, he's absolutely right. "Web Standards" refer to the actual specifications for web technologies, notably HTML and CSS. Indeed, the Web Standards Project are only advocating adherance to the W3C Standards for XHTML, XML, CSS, etc.

I asked Jim for a better term, and citing this blog post he suggested "Best Practices". This really expresses the intention here, that we should be doing things a certain way because it's the best way.

I've been thinking about this a lot since, and went back to Molly's infamous post where she coined the term "New Web Professionalism" to describe this Right Way Of Doing Things. This is just expressing the same concept in different words, and it's never the words that matter. It's what the words represent. As an industry, we need to encourage a certain level of quality, a certain, shall we say, standard.

So, Web Development Best Practices? Web Professionalism? Web Professional Standards? I hate buzzwords as much as anyone, but it seems like we need one here, some piece of jargon that lets everyone else understand what it is we're talking about. Don't we?

Then again, a buzzword is the last thing we need here. It would only distract from the underlying point. We can still refer to Accessibility, Web Standards (that is, valid HTML and CSS), Semantic Markup and Unobtrusive Javascript. And by doing so, we won't forget what it is we're talking about. We won't end up with some empty marketing speak promising something as vague as "Best Practices" when they have completely ignored Accessibility.

I won't go so far to rename my last posts, but for now on I will be much more clear when I talk about these and other Best Practices, and will forever hestitate to throw around the term Web Standards to mean anything except valid code (which, to be honest, is the least interesting topic amongst Best Practices).