Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews - I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process - writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways - I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow...

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, David Heinemeier Hansson would have never created Rails had he been an exclusive ASP.NET developer, and Scott Guthrie would never have developed ASP.NET 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, GoogleExercise.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.

JavaScript is probably the world's most popular and misunderstood programming languages and for good reason - most developers will claim they know JavaScript even when they don't - I know I have!

When a developer claims to know JavaScript this generally equates to one or all of the following:

• "I know what JavaScript is, I can learn JavaScript in 30 minutes"
• "JavaScript is for kids, it's a toy language, it's easy"
• "I just copy and paste my JavaScript snippets / scripts from the internet"
• "JavaScript is just another programming language like C++, C#, VB.NET, or Java"

If thoughts similar to these have crossed your mind when sizing up your JavaScript knowledge, then you probably don't know JavaScript.

I would argue that if you've never programmed in a functional programming language (like: Lisp, Scheme, F#), never read a GOOD book on JavaScript, or never watched a video on JavaScript, then you probably don't understand JavaScript at all. JavaScript is starkly different than any other mainstream programming language.

When it comes to JavaScript, if you don't understand the fundamentals then you're only punishing yourself.

Here are some things every JavaScript developer should probably understand:

• JavaScript, Mocha, LiveScript, JScript, and ECMAScript are all essentially the same.
• JavaScript is a prototypically inherited (prototype-based programming) language which is very different than the classically inherited (class-based programming) languages like C++, Java, and most of the .NET languages - you know the difference between a prototype-based programming and class-based programming language.
• JavaScript is a loosely typed language - you know the difference between strongly-typed programming languages and weak-typed or loosely typed languages.
• JavaScript is a functional lambda language - you understand lambdas and that functions in JavaScript can be lambdas.
• JavaScript functions can be defined inside functions, inside functions, inside functions, and so on - you can demonstrate this.
• JavaScript uses function scope, has no curly brace '{}' block scope - you understand that this is common attribute of most functional programming languages.
• JavaScript has no private, public, protected assessors, no classes, no enums, no structs - you understand that all these language features can be achieved through objects and function closures.
• JavaScript is classless, but instead it uses objects as general containers.
• JavaScript makes use of garbage collection.
• JavaScript uses truthy and falsy values - you understand which values are truth and falsy.
• JavaScript makes use of the 'nan' (not a number) and 'undefined' values - you understand the difference between these values.
• JavaScript has pretty good debuggers - you understand how to debug JavaScript from both IE (link) and Firefox (link).
• You appreciate recursion, and understand that recursion is a useful technique in JavaScript.
  
• You understand that JavaScript Namespaces should be used - you understand the importance of namespaces, and know how to create one (Namespacing Your JavaScript).
• You know how to avoid the JavaScript pseudo-protocol (<a href="Javascript:alert('hello');"), and appreciate avoiding it.
• You know how to avoid embedding DOM Level 0 JavaScript events (<a onclick=''alert('hello');") in your mark-up / document structure, and appreciate this technique.
• You know that JavaScript can make use of two different event models (event capturing and bubbling), but we should only ever make use of bubbling.
• You understand what JSON is and how it's used.
• You know how to keep you JavaScript, CSS, document structure separate, and appreciate non obtrusive JavaScript.

If any of these points seem foreign, then it may be time to learn JavaScript. With all the hype and buzz around Web 2.0 and AJAX it could be a great way to augment your career while broadening your programming language vocabulary.

Great resources for learning more about JavaScript:

Videos:

• The JavaScript Programming Language: Part 1, Part 2, Part 3, Part 4
• An Inconvenient API: The Theory of the DOM: Part 1, Part 2, Part 3
• Advanced JavaScript: Part 1, Part 2, Part 3
• JavaScript: The Good Stuff: Link
• All these videos are available on the YUI Theater - all the videos are great, watch them all!

Books:

• JavaScript: The Definitive Guide (Paperback) by David Flanagan

Links:

• MDC: A re-introduction to JavaScript
  
• Code Conventions for the JavaScript Programming Language
• JavaScript: The World's Most Misunderstood Programming Language
• What ASP.NET Developers Should Know About JavaScript
• Best Practices: Implementing JavaScript for rich internet applications
• The seven rules of Unobtrusive JavaScript
  

Greasemonkey is an add-on for Firefox. Through JavaScript it allows anyone the ability to dynamically modify a page as, or after it's being rendered in the browser. This lets anyone trim the DOM, remove ads, and modify page in anyway they see fit (it also opens up some serious privacy concerns with XSS). Anyhow, I spend a fair time on the ASP.NET forums, but the advertisements have always made for a somewhat negative, but tolerable user experience.

Today I finally broke down and wrote my own Greasemonkey script - now formally known as "The ASP.NET Forums Beautifier" for lack of a better name.

The Script Before and After:

Before - usually the ASP.NET Forums look like this:

After - with my script running in Greasemonkey we get this:

note: the greasemonkey icon, and complete lack of fluff / advertisements on the second screenshot.

Creating this script was simpler than I expected. It was a matter of skimming through an article on How to write Greasemonkey scripts, using Firebug's JavaScript Console and Firefox's Error Console to test my code (after all, Firefox is the new IDE, Firefox as an IDE), and an hour later, Viola! No more ads.

The YUI blog and Douglas Crockford in particular, have inspired my JavaScript renaissance. JavaScript is really interesting, it's a functional, loosely typed programming language that uses prototype-base inheritance. Developing in JavaScript is a real treat from some of the more statically typed languages.

Download Greasemonkey and "The ASP.NET Forums Beautifier" for yourself. :)

Visitors using Internet Explorer (6 & 7) were unable to post comments on this site (my site runs dasBlog) ever since I added a JavaScript snippet from Technorati.

The Problem in More Details: For visitors using IE (Internet Explorer 6 & 7) dasBlog's "Save Comment" button wouldn't fire, hence the web form wouldn't submit, and the comment wouldn't be posted. When dasBlog's Captcha feature was enabled the Captcha validation wouldn't fire, and again the form would not submit. When JavaScript was disabled in Internet Explorer, dasBlog / ASP.NET would revert to server side validation, the web form would submit, and the comment would be saved. Everything worked fine in Firefox and Opera.

A wild goose chase: I'm using a ASP.NET 1.x version of dasBlog converted to ASP.NET 2.0, and customized to run on a medium trust environment. I initially assumed that something had been corrupted during the ASP.NET 1.x to 2.0 conversion - I thought that some of the ASP.NET client side scripts had been corrupted, or that somehow this ASP.NET 2.0 application was referencing some older ASP.NET 1.x scripts. This assumption proved to be fruitless. I then started looking at Jeff Atwood's Captcha control as the source of the problem, but after disabling the Captcha my "Save Comment" button still didn't work. It had to be something else, I thought that it was a bug with dasBlog, but upon downloading the latest release of dasBlog 2.0 (kudos to the dasBlog team!), I noticed that I could post comments to my site when using any theme other than my own. I started looking at my theme, I disabled my JavaScript links and discovered...

The Solution: a JavaScript linked from Technorati was preventing my comments from being saved. I removed the conflicting script - Goodbye Technorati, Hello Comments from IE.

I wish I would have figured this out sooner, hopefully this article will help anyone else with a similar problem (dasBlog's "Save Comment" button doesn't work). I'll be looking closer at the Technorati script and post another entry here with my findings. In the meantime look through the conflicting script yourself at: http://embed.technorati.com/embed/93ja2gejnr.js

Update: The second line of Technorati's JavaScript causes ASP.NET's postback to fail - ASP.NET can only have one form tag declaration.

The rough JavaScript:

document.write('<form id="te_s" method="post" ... 

I'm using ThinkJot (DasBlog coverted into an ASP.NET medium trust level app) and apparently users can NOT comment from Internet Explorer. I apologize and hope to have this fixed soon, if anyone has a resolution then please contact me or post a comment using an alternative browser like Firefox.

UPDATE AND FIXED: view dasBlog.aspx#aac7e44ac-2ab1-4c5c-ab1d-92c8414dbea8">this post for more details.

I've been using Style Elements within the HTML Body tag to work around some of the design flaws presented in ASP.NET 2.0 Themes - see the second solution in this post for more details. I've been leary of using this method because it's not a best practice, since it compromises the validity of the HTML / XHTML document. I decided to do a little more research on this subject and made the following discoveries.

Discoveries:

1. Some of the more complex web sites (Amazon and Yahoo!) make use of Style Elements within the Body Element - see the source snippets below.
2. Gecko (Firefox, Flock, Mozilla, etc…) based browsers automatically move Style Elements found within the Body Element into the Head Element and render the page as expected - see the rendered Document Object Model (DOM) image below.
3. Internet Explorer doesn't move the Style Element into the Head Element, but renders the page as expected.
4. Opera… well I wish I knew what Opera did, but the page renders as expected.

Source snippet from Amazon:

</table>
    </td>
  </tr>
</table>

<style type="text/css">
.lol-hr-center { margin: 5px; border-top-width: 1px;
/* and so on... */
}
</style>

<div id="listoflists_data" style="display:none">
Note how the Style element is located between the <table> and <div> tags.

Source snippet from Yahoo!:

<h4>
<a id="paweather" class="details" href="r/wb/*-http://weather.yahoo.com/forecast/USKS0448_f.html"><span class="icon">Weather <b><strong>51&deg;</strong>F</b></span></a>

<style type="text/css">#patabs #weather .icon{background:url(http://us.i1.yimg.com/us.yimg.com/i/us/we/31/b/26.gif) 3px 2pxno-repeat;}</style>

</h4>
Note how the Style element is located within the <h4> tag.

A snapshot of the Document Object Model (DOM) as seen through Firebug:

Note the highlighted area references the Yahoo! source snippet from above.

Conclusion: Although the Style Element within the Body Element compromises the validity of a document, some of the leaders in web design and accessibility use this approach, so it may not be as big a work around or hack.

The World Wide Web Consortium (W3C) Cascading Style Sheets (CSS) 2 specifications introduced the underscore (_) as a valid CSS naming character, this allows CSS selectors like class selectors and ID selectors to be named like:

• ._menu_item_1
• #_menu_item_2
• .menu_item_3
• #menu_item_4

However; rendering inconsistencies remain among most popular browsers when Styles, Classes, or IDs are preceded by the underscore character.

Inconsistencies:

CSS Classes and IDs with an underscore immediately after their respective delimiter ('.' Or '#') are rendered by both Firefox and Opera, but NOT by Internet Explorer.

This CSS example will NOT work in Internet Explorer, but WILL work in Firefox and Opera:

        ._idTest1{
            background-color: red;
        }
        #_id_Test2{
            background-color: red;

Style entries preceded by an underscore are rendered by Internet Explorer (IE 6 & 7), but NOT by Mozilla / Gecko (Firefox) or Opera.

This CSS example will only work in Internet Explorer:

        *{
            _color: green;
        }

This is a documented quirk and bug, see The Underscore Hack and IE Underscore Bug Test for more information.The Results of our Underscored CSS in Internet Explorer:

The Results of our Underscored CSS in FireFox (rendered the same in Opera):

This CSS quirk came up in an ASP.NET forum, where a poster was having cross browser issues with his menu controls. We discovered that <xhtmlConformance mode="Legacy" /> was defined in his web.config file which caused the ASP.NET Master Page control (ctl00) to be preceded by an underscore (_ctl00) which was preventing the CSS from being rendered in IE.

Related links:

The IE Underscore Bug Test
The original forum thread: menu control in master page does not get styles in ie 6.0.
ScottGu's Blog: Gotcha: Don't use <xhtmlConformance mode="Legacy"/> with ASP.NET AJAX
View the complete source code for my Underscore Test or try it on your favorite browser here.

I noticed that a couple visitors were using the Opera web browser, so I decided to check my site with this highly W3C CSS compliant browser - see the "Acid2 Test".

To my horror, I found my CSS wasn't working properly.

My blog in Opera (the CSS rendering issue):

I began debugging my site by starting up Firefox with the Firebug extension. Upon inspecting my Document Object Model (DOM) and my rendered CSS I found a syntax error (a bug).

Using the Firebug extension for Firefox to view the DOM and related errors:

My error; I had erroneously entered */ instead of /* for my CSS comment. After making the changes everything rendered as expected in Opera.

Conclusion; My site now works with Opera 9. As a rule of thumb, I generally do my CSS design in a more W3C CSS compliant browser like Firefox, Opera, etc... and then make the respective changes for proper display in IE. Firebug is amazing, the best web development tool I have seen in a long time. Firebug really makes debugging a breeze.

Other useful Firefox extensions:

• Colorzilla - Advanced Eyedropper, ColorPicker, Page Zoomer and other colorful goodies.
• del.icio.us - Keep, share and discover all your favorite things.
• FasterFox - Performance and network tweaks for Firefox.
• FireBug - Edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.
• Greasemonkey - Customize the way webpages look and function (hide search engine advertisements, tweak Gmail).
• Mouse Gestures - Allows you to execute common commands (like page forward/backward, close tab, new tab) by mouse gestures drawn over the current webpage, without reaching for the toolbar or the keyboard.
  

Other useful Internet Explorer extensions / toolbars:

• Internet Explorer Developer Toolbar Beta 3 - Tools for quickly creating, understanding, and troubleshooting Web pages

While Themes and Skins are new to ASP.NET 2.0, the underlying concepts have been around for a long time. For those unfamiliar with Themes and Skins, skins give web designers greater flexibility to manipulating ASP.NET server side controls (calendars, datagrids, etc…) through Styles / Cascading Style Sheets (CSS). Themes logically group the design tier of an application into a common folder or directory (a Theme folder(s)), giving developers the ability to programmatically change (swap), or expose these Themes to the user.

Learn more: ASP.NET Themes and Skins Overview.
See a live example here: ASP.NET 2.0 Colorful Web Site Starter Kit.

The concept of interchanging layout and changing design styles (Themes) has been around for quite some time. The W3C Recommendation for Style Sheets in HTML documents outlines the “alternate stylesheet” that should be interchanged through the browsers menu; unfortunately Internet Explorer (IE) fails to support this method.

An example: changing style sheets with a Mozilla based browser (Firefox).

See the live example (if you’re not using IE) at: www.damowmow.com.

Other methods for changing design layouts (Themes) range from Client Side Scripts (JavaScript) to Server Side Scripts (ASP, PHP, ASP.NET, and so on).

Learn more about style interchanging scripts and more here: Style Switching - css-discuss.

Themes and Skins are a welcome addition to ASP.NET 2.0, they offer a simple solution for grouping design specific files, and a nice way to programmatically change these Themes. However; this simplistic approach significantly hampers the power of Cascading Style Sheets – I’ll discuss my difficulties / problems in subsequent posts.