Here’s what I use. Feel free to copy it and do whatever you want, it’s GPL v2 licensed. (zip file)

• The Html5 Shiv (conditionally for IE, of course.)
• The CSS is Richard Clark’s HTML5 Reset Stylesheet, plus some stub styles like image / text replacement for the h1.
• Whatever jQuery UI 1.8 theme (if applicable.. most of my sites use jQuery UI, so I added it to my template.)
• Conditionally, an IE stylesheet. I go ahead and lump IE 6+ into one bucket. This could be broken out into several stylesheets (per IE version), but I’ve found that using the reset sheet generally limits the amount of IE fixes I have to do, so there’s not much wasted download time at all for IE users. If your stylesheet gets too heavy, break it out at your discretion.
• Several IE conditional statements to build IE wrapper divs to make styling easier. If you’re including styles by version, you probably don’t need this. Also has the added benefit of fast browser version checks with jQuery.
• Header with heading, subheading. The h1 is a link sometimes, using css image/text replacement. I went back and forth on whether the page title or the site title should be an h1- and chose an h1 based on arguments on this blog post.
• Seperate nav. I almost put it with header- but I like keeping the header more pure for the logo/title and subheading.
• A div to wrap all of the content, and then a “maincontent” div. I haven’t found better names yet, so here you go. They’re not section elements, like most of the content is in- the structure is there strictly for styling reasons.
• An example section. I like giving it an id with the page title, so I can add in page-specific styles as needed.
  • The section’s header, and content, as is reccomended
• An aside, styled as a right-hand column with subsections
• A footer, with links (probably the same as the main links), and copyright information. I’ve used an address element to wrap the webmaster’s email. Semantics!
• Finally, jQuery 1.4.2 and jQuery UI 1.8 pulled from offsite sources (parallelize downloads, plus it’s likely cached from another site)

So, the idea was to get about an hour or two’s work done by simply opening up a file. I think I’ve accomplished this- anything extra I can remove, I can switch the left and right columns pretty easily (or add a third, or fourth), and I have some very basic styles down (just change those grays to something a little more colorful.) Be free, my template!

http://code.jquery.com/jquery-1.4.2.js

http://code.jquery.com/jquery-1.4.2.min.js (not really “minified” as much as “closure compiled”… can we get a verb for that?) The changelog isn’t up yet, but that’s generally the last thing to go (and hey, we snuck in the back door to grab the update anyway, right?) I imagine it’ll eventually find it’s way to their API page for 1.4.2.  I ran a quick diff; here’s some changes that I found notable from jQuery 1.4.1 to 1.4.2:

• Optimizations for the body selector
• A few changes to how arrays of elements selected are built, I’ll go with my gut and say that they’re optimizations too
• Trimming whitespace from JSON data responses, for good ol’ IE
• A more few various bugfixy-looking things, mostly targeting IE
• It looks like there was a lot done to the event-adding code; I think mostly internal changes. Probably more optimizations? I’ll leave it to Resig or someone to explain whenever the changelog comes out. A few (generally pretty deep) methods had some parameters changed, or were renamed (things like “jQuery.event.special.submit.remove” becoming “jQuery.event.special.submit.teardown”)
• A smattering of changes within “live” and “die” mostly centering around the usage of namespaces
• Blackberry browser bugfix concerning converting NodeLists to arrays
• jQuery.getText changed to jQuery.text
• Changes to caching fragments to help out WebKit and IE 6

I haven’t really dug too deeply in the jQuery core before, so I’m not totally qualified to give a whole lot more detail than that. I used SourceGear Diffmerge between 1.4.1 and 1.4.2 to find out what I found out.

Also, in related (and perhaps more official news),  the jQuery UI team released jQuery UI 1.8rc2 – which includes bugfixes in the already pretty stable 1.8rc1 (changelog). You can grab it:

http://jquery-ui.googlecode.com/files/jquery-ui-1.8rc2.zip (development bundle)

http://labs.crimsondeviations.com/jquery-ui-1.8rc2-min.js (I threw it into a closure compiler, it seems the dev package doesn’t include a “minified” version.)

As of right now, I’m testing it in our application at MeM. Let’s see how things go!

I did some research, and there are some very, very compelling reasons. Here’s what I wrote to our team:

We may want to look at updating, or at least putting it in and testing, soon.

Benefits of upgrading:

• Performance updates
• IE fixes, including some fixes to IE event bubbling
• Includes extra API calls and additions to existing functions
• Maintaining possibility to use new plugins as they are created for the latest version of jQuery
• Better handling for events (outside of just IE)- we can (should) refactor and reduce a lot of our jQuery code using events
• Better support for multiple simultaneous animations
• More granular “does my browser support X” checks

The downside is that we’re going to have to do pretty thorough testing in all browsers to make sure that the update hasn’t broken anything. The main areas to hit will be places that plugins are used:

• Autocomplete for country/state
• Loading screen in DE / Admin
• Media plugin that sets up flash for Audio Guest Book in display
• Simple Uploader
• Help boxes in DE

We’ll need to spot-check around other areas of the site for javascript errors as well. jQuery still supports the same browsers- FF 2+, IE 6+, Safari 3+, Opera 9+, Chrome 1+ (http://docs.jquery.com/Browser_Compatibility) so we shouldn’t expect any new weirdness in archaic browsers like IE6.

More information about the update can be found at:

• http://css.dzone.com/articles/jquery-14-improves-code-and
• http://api.jquery.com/category/version/1.4/
• http://docs.jquery.com/JQuery_1.4_Roadmap
• http://jquery14.com/day-01/jquery-14 (the best link, in my opinion)

Also: “15 new features you must know”: http://net.tutsplus.com/tutorials/javascript-ajax/jquery-1-4-released-the-15-new-features-you-must-know/

(Lower is better):

(skip down a little further if you don’t need an introduction to Google Analytics.)

I love Google Analytics. In fact, I’m a big fan of Google as a whole, and I do the majority of my work using Google Docs, Calendar, and Gmail (online collaboration! oh, and free) and Google Analytics is a beautiful tool for businesses, whether their website‘s primary focus is online sales or just a small info-about-my-business site. If you don’t have some kind of tracking, you’re missing out on very important information; GA is a good place to start. Anybody can put GA into their website, and everybody should put something in.

The way GA works is by dropping a snippet of Javascript into your page; this javascript runs a series of tests against the visitor’s browser, checking screen resolution, flash capabilities, seeing if the user is unique, watching the user’s path through the website, checking the user’s location, and much, much more (all collected anonymously). This is all put into an interface where you can see the data collected and organized. However, AJAX applications don’t function as normal websites- you don’t get a new page hit every time you fire off an UpdatePanel, because it’s not a full page refresh. So, we need to do a little trickery to get things to work the way we want them to.

(you can start reading again if you skipped earlier.)

If you have the Google Analytics in the host page (whether the aspx page, or more likely, the master page), then you have to register a client script block that calls the trackpageview method. If you use jQuery, it’ll look something like:

ScriptManager.RegisterClientScriptBlock(UpdatePanelID, typeof(UpdatePanel), "uniqueIdentifierString", "$(document).ready(function(){ pageTracker._trackPageview('/pagename'); });", true);

If you’re not using jQuery, you’ll have to do a little more work to attach to the window’s onload event, but it’s pretty similar.
What you’re doing is registering a script block to execute when the UpdatePanel updates (because it won’t execute JS returned in the text), and using the pageTracker object (that the GA code you copied when you first set up GA on your site created) to force a pageview for a page you define. For my applications, I generally use something like “/dataentry/guestbook/edit” or “/dataentry/guestbook/delete” so that I can easily track guestbook views, as well as edits / deletes. It’s both a way to track controls you load via AJAX, and a cheap shot at logging (not perfect data, though, so you’re still best off doing all of your own logging on events, of course.)

The official Google help doc on the subject is also here: http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55519

I wish I could call IE6 dead.

I’ve spent hundreds of man-hours doing CSS fixes for it, and every day, I check Google Analytics to see how close we are to its death… and every day, I’m disappointed.

Technically, it is dead. Most standards say the latest 2 versions (of course, that got really big when IE8 came out, excellent excuse to drop it), and it’s 6 years old by now, well past the average lifespan of any technology. But, the problem is, for all of my idealism and complaints and loss of efficiency, we still have over 30% of our users on the ancient mind-breaker. So, unfortunately, for all of my complaints, for all of my IE6 specific cde and CSS fixes.. it’s not dead. It’s not defined by age, but by users. So until the time comes when IE updates become mandatory, or our users finally move on… it’s still very alive, in my nightmares and in my everyday coding experiences.