By definition, if a browser can’t support the type of an input, it automatically falls back to a text input.  This is great for backwards compatibility, but it gave me a bit of a problem.  If I set type=”number” in my HTML, testing the type of the element in Javascript returns “text” when the number element isn’t supported.  Useful for determining if support is available, not so useful for determining what the original value is in the HTML.

In most browsers, you can find the original value using the attributes collection.  However, this doesn’t work in IE7 and earlier.  And, as everyone knows, we still have to support IE 6 & 7 for most web sites.  I found an alternative for IE, which is to test the outerHTML of the element using a regular expression.  IE will return this with the original attributes intact.

I’ve written a jQuery filter extension that allows you to test any element for the original input type:

// add HTML5 input type expression (still detects HTML5 input types on browsers that don't support them)
$.extend($.expr[':'], {
	inputtype: function(elem, i, type) {
		function getRawAttr() {
			// IE will return the original value in the outerHTML
			var match = /<input.*?\s+type=(\w+)(\s+|>).*?/i.exec(elem.outerHTML);

			if (match && match.length >= 2 && match[1] !== "text") {
				return match[1];
			}

			// for other browsers, test attributes collection (doesn't work in IE<7)
			var attrs = elem.attributes,
				i;

			for (i=0; i<attrs.length; i++) {
				if (attrs[i].nodeName === "type") {
					return attrs[i].nodeValue;
				}
			}

		}

		if (elem.tagName != "INPUT") return false;
		if (elem.type === "text") {
			// could be unsupported type fallback, so do further testing
			return getRawAttr() === type[3];
		} else {
			return elem.type === type[3];
		}
	}
});

To use this extension, just use the :inputtype(type) filter in your jQuery expression.  For example:

$('input:inputtype(number)).width(100);

if ($(elem).is(':inputtype(number)')) {
...
}

Update: Changed to only run the check if the tag is an input tag, in case you run the filter against non-input elements.

Read more about this new tool or download it at http://btburnett.com/netcompressor.

The original design concept was for a web store framework I was working on.  I wanted each store be able to easily change their javascript based themes without making changes to the javascript files for the basic theme.  This made for a much easier file based deployment of new versions to each store.  The obvious downside is that you’re downloading lots of extra javascript, particularly if you’re turning features back off that were in the basic theme.  This type of functionality is only useful in certain cases, and is never the most efficient system possible with regards to performance and bandwidth, just maintainability.

This new release still maintains that basic functionality, but now I address a more common concern as well, applying themes to AJAX updates.  In order to support this, I’ve added several new features.

• $.themescript.exec now accepts a context parameter.  This can be a jQuery object or an HTML DOM element, just like the context to jQuery’s jQuery(selector, [context]) selector function.  All registered functions will receive this context as a parameter, and it will be automatically used as the context to selector-based theming to restrict the elements returned.

• themescript is a new function added to jQuery objects which allows you to execute the themescripts against a specific jQuery object.  $(‘#selector’).themescript() is equivalent to $.themescript.exec( $(‘#selector’) )

• themescript( url, [data], [callback] ) works just like the jQuery load method, except that it will automatically run themescripts against the updated HTML if the request is successful.

You can also easily add support for jQuery.themescript to ASP.Net AJAX partial page updates (a.k.a. UpdatePanels).  Just add this script code to your files and the themescripts will be automatically executed against any UpdatePanels which are changed during an asynchronous postback.

var prm = Sys.WebForms.PageRequestManager.getInstance();
prm.add_pageLoaded(function(sender, args) {
    var</span> updated = args.get_panelsUpdated();
    if</span> (updated && updated.length) {
        $.themescript.exec($(updated));
    }
});

Here are the links where you can access the GitHub repository or download the files:

GitHub
Download

• LabScriptCombine allows you to make use of the automated runtime script combining features of ASP.Net 3.5 in combination with LABjs script chaining.  To get the optimum script load time, combine scripts between each wait() call into a single HTTP request, so long as you are consistently using that combination of scripts across your pages.
• Added some useful constructors to several of the LABjs.Net classes.  These constructors make it easier to build a LABjs chain in your code rather than in your .aspx files.
• Made a slight change to the LabWait constructor that accepts an inlineScript parameter.  It will now default DetectScriptTags to False if you use this constructor, since you shouldn’t be including the script tags if you are building your chain in code.  You can still set this Property back to True if needed.
• Added AlternateRef property to LabScriptReference.  If you’re using the experimental CDN failover extension to LABjs, it allows you to specify a full set of options for the alternate script.  The AlternateRef property allows you to make use of those options if you want to, by providing a full LabScriptReference class to use.  This is optionally used instead of the simpler Alternate property that just provides a URL.

Binaries
GitHub

All of this is great for the client side. But how do you define which scripts to include in the LABjs chain on the server side?

Since for work I primarily operate in ASP.Net, I’ve created an ASP.Net solution to the problem, LABjs.Net. This library provides two key controls, LabScriptManager and LabScriptManagerProxy. These controls loosely follow the behavior of the AJAX ScriptManager and ScriptManagerProxy controls, at least their script loading aspects.

Key supported features include:

1. Refer to script files using application relative paths (i.e. ~/js/jquery.min.js)
2. Load script files from assembly resources
3. Specify if debug or release scripts should be used, or use the debug setting from the web.config file
4. Ability to set any of the options provided by LABjs
5. Include wait() calls in the chain, and provide inline functions to be executed after the wait
6. Use LabScriptManagerProxy to add scripts and waits to the chain in content pages and user controls
7. Use LabActionGroup inside LabScriptManagerProxy to add script() calls at a specific point in the primary chain
8. LABjs debug and release versions are embedded in the DLL and automatically referenced, but you can opti0nally override this with your own URL
9. Experimental support for the cdnLABjs library I am working on, which provides automatic failover to a local file if a file fails to load from a CDN (for information about why, see Using CDN Hosted jQuery with a Local Fall-back Copy)

Below you will find links to the current release candidate, 1.0rc1.  Please review it and give me any feedback you might have.

Download Binaries
Readme File
Git Repository

Update 2/8/2010: Updated to version 1.0rc4

jquery.ui.spinner Git Repository
jQuery UI Spinner Widget Example

As it turns out, the jQuery UI team already had a spinner widget sitting in their files that hadn’t been worked on in a while, so I’m working with Ca-Phun Ung to see if we can finish getting it up-to-date, polished, and with some of the new features from my widget incorporated into it. Stay tuned for more info.

Microsoft does provide a utility, makecert, which can create a self-signed certificate. However, it isn’t distributed with Windows, is command line only, and definately NOT end user friendly. I wanted a method for creating a certificate just by clicking a button, without using a shell calls and distributing a copy of makecert with my applications.

To this end, I created a VB.Net class that calls out to the CryptoAPI and creates a self signed certificate with a 2048-bit RSA key. The certificate and private key are stored in the Local Machine store. In the Local Machine store it can be accessed by system processes and services. I’ve attached an example of the class to this post, feel free to use it as you see fit.

jquery.ui.spinbuttons Git Repository

The only downside of using jQuery with ASP.Net is the lack of integration.  They now include a vsdoc file which helps with Intellisense, but there’s a long way to go.  For simplicity, I’m still using Microsoft’s AJAX code for their page methods and UpdatePanels, and primarily using jQuery for the client side controls and animations.

I’ve written a library to help with the creation of ASP.Net server controls that utilize jQuery.  I’m calling it, very creatively, jQuery.Net.  You can access the code and binaries for the library on github, the link’s below.

jQuery.Net Git Repository