Classitis is the measles of markup, obscuring meaning as it adds needless weight to every page. The affliction dates back to the early days of semi-CSS-capable browsers and the many designers’ initially childish comprehension of how CSS works.
Alas, many have not yet outgrown that childish misunderstanding of CSS … Classitis is as bad in its own way as the <font> tag ever was; rarely does good markup require it … At other times classitis is exacerbated by a still more serious condition … divitis … Classitis and divitis are like the needless adjectives with wich bad writing is strewen. They are the weeds in the garden of meaning. - Jeffrey Zeldman, Designing with Web Standards

An example of markup wraught with divitis and classitis:

13 div elements and 11 classes for a single item. What a stench! :)  View this markup in action.

The equivalent markup disease free:

Cleaner, more meaningful, and with all the functionality of the former code. One div element and 3 classes for a single item.  ShamWow! View this markup in action.

Both of these markup snippets are visually and functionally equivalent. In the first example the divs, classes, and cryptic ids weigh down the page and pollute the meaning of the markup. In the later, a more semantic / structural approach is taken  Both these snippets were pulled from my attempts at the Google Web Developer Exercise.

Clean meaningful markup is the API that users and web crawlers consume - it’s important and easy to keep things clean, it just takes a little experience. Thank goodness for patterns like MVC that let us control our API (the markup).

I did the exercise yet again (the third time) because my last attempt needed some improvements:

• it suffered from chronic classitis and divitis (too many classes, ids, and divs were making me itchy)
• it wasn’t really using semantic / structural markup (all the extra divs etc… cluttered my markup, and some of my class names like container-borders are non-semantic altogether)
• it performed poorly and wasn’t accessible (everything was being rendered in the DOM, there was no immediate rendered markup which kind of violated the idea of unobtrusive JavaScript, nor was it screen reader friendly)
• it wasn’t making use of any JavaScript libraries to abstract browser inconsistencies out of the code
• it suffered from my software ethnocentrism (my variable and object naming like GoogleExercise was mirroring statically typed languages and not the native language they were being written in)

Here’s my latest Google Exercise (addressing all the above concerns):
View this post outside your RSS reader to see it in action or view it here.

This attempt makes use of jQuery and uses 57 lines of JavaScript (almost 200 lines less from my last one).

You can view the code for this attempt here: google.contact.widget.js, index.html, google-contact-widget.css.

You can view the old code here: GoogleExercise.js, index.html, GoogleExercise.css.

If you think I can improve on my code then let me know. Oh yeah, and if you’re a recruiter from Google then hire me! :)

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

After my first attempt, I concluded that:

1. My JavaScript knowledge was embarrassing
2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
5. Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick=”return false;” …, or <a href=”Javascript: do something;” … are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

• Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
• An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
• Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
• An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
• Node manipulation - creating, swapping, removing elements
• Knowledge of non-obtrusive JavaScript techniques
• Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
• An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
• JavaScript code conventions - naming conventions, statement conventions
• CSS naming conventions
• General DHTML / AJAX techniques - showing and hiding elements
• A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, index.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.