Simple jQuery Autosubmit Plugin

One issue that I have with ASP.NET is how often it injects inline styles and scripts into your pages. One example is the “AutoPostBack” attribute that you can add to your DropDownList and RadioButtonList server controls. When this attribute is added, an inline “onchange” event handler will be added to your markup along with some other scripts. Ideally, this functionality should be handled in an external JS file, and it’s really not that hard to do.

Here’s a quick jQuery plugin that will accomplish that without having to rely on .NET’s “AutoPostBack” feature.

/// <summary>
/// The parent form of the provided element(s) will be submitted when its/their value changes.
/// </summary>
/// <param name="options.ignore">An ignore option is available (array) to prevent the form from submitting when certain values are chosen. By default, options with an empty string value are ignored.</param>
/// <param name="options.trigger">If trigger is omitted, the parent form will be submitted. Otherwise, a click event will be triggered on the provided jQuery object.</param>
(function(factory) {
	if (typeof define === 'function' && define.amd) {
		// Register as an anonymous module
		define(['jquery'], factory);
	} else {
		// Browser globals
		factory(jQuery);
	}
}(function ($) {
	$.fn.autosubmit = function (options) {
		var settings = $.extend({
			'ignore': ['']
		}, options);

		this.change(function () {
			var $this = $(this);

			if ($.inArray($this.val(), settings.ignore) === -1) {
				if (typeof settings.trigger !== 'undefined') {
					settings.trigger.click();
				} else {
					$this.closest('form').submit();
				}
			}
		})

		return this;
	}
}));

Using the plugin is very easy. Create your DropDownList as usual, but give it a CssClass attribute so you can reference it easily:

<asp:DropDownList ID="myDropDownList" CssClass="auto-drop-down" runat="server">…</asp:DropDownList>

Include jQuery and the plugin file in your page, then write some JS similar to the following:

$('.auto-drop-down').autosubmit();

The plugin also allows you to specify certain values that will not autosubmit when chosen. For example, you may have a drop-down with a “Select an option” choice, in which case, you wouldn’t want to submit the form unless a different choice was made. Here’s how to ignore certain values:

$('.auto-drop-down').autosubmit({'ignore': ['', 'n/a', 'empty']});

One more thing to point out — be sure to include a submit button even if the autosubmit feature makes it unnecessary. If someone isn’t using JavaScript, they should still be able to use the drop-down on your page. Another line of JS for hiding the submit button is trivial:

$('#my-button').hide();

Tabs vs. Spaces: Why is there a Debate?

Whether to use tabs or spaces when indenting code has been a source of contention among developers for some time. However, in none of these debates have I found a legitimate reason for spaces instead of tabs — at least not when both sides have a firm understanding of how tabs are to be used (i.e. indentation, not alignment).

Advantages of Tabs Over Spaces

So, why do I prefer tabs over spaces? It’s quite simple: there are a huge number of advantages and very, very few reasons to use spaces — namely to work with teams that are stuck in their ways.

1. Fewer Key Strokes

This one should be obvious. Pressing the tab key on the keyboard is only one keystroke. Unless you indent with only one space (which is bad for other reasons), you’re spending more time typing. Now, I hear you saying that almost all modern code software can automatically replace a tab with a certain number of spaces. Let me say that this isn’t a solution; it exacerbates the problem and makes it nearly impossible to insert an actual tab character. It’s just a patch to a problem and misleads people into thinking that white space isn’t important — until they work with someone else’s code, who didn’t use the same number of space characters as the “auto-space” feature in their editor.

2. Easier Keyboard Navigation

Even if your editor does replace tabs with spaces, it usually doesn’t change how the arrow keys navigate through those characters. With tabs, I can use the left/right arrow keys to move back or forward one level of indentation with each key press. This doesn’t work with spaces, and if you’ve only ever used spaces, you probably don’t even realize how inefficient it is.

Many hard-core coders will point out that there are editors such as Vim with very efficient keyboard navigation that doesn’t rely on the arrow keys or that you can use keyboard shortcuts (like ctrl+left arrow) to move through white space, but not everyone uses those editors (or is proficient with them), and shortcuts are often still more complex. Even so, the ability to move from one level of indentation to another is not addressed.

If you’ve worked with spaces your entire career, then you probably think that being able to navigate quickly through levels of indentation is a minor boon. You’ve probably learned to naturally compensate by using your mouse and clicking to place the cursor where you want or some other keyboard combination. However, tab users immediately recognize how painful it is to move through code with spaces. It’s like switching from a two-button mouse to one with only one button — why would anyone do that?

3. Smaller File Sizes

Both space and tab characters take up one byte of space. If you use two spaces to indent, you’re doubling the file size of your documents, and you’re more likely quadrupling the size since many editors default to four spaces per tab.

Most space apologists will claim that code can be minified or compressed in some way, but let’s be realistic. Take a look at the source code of just about any website’s HTML that relies on spaces for indentation, and you’ll find that the vast majority are not compressed. Even when they are, the original source exists somewhere and is taking up disk space. Storage may be cheap, but that’s not a good reason to fill it up.

4. Configurable Indentation Preferences

Suppose I like four spaces per level of indentation, but my colleagues prefer three. We’re eventually going to have to negotiate on one or the other, and if I’ve been using four spaces, then it’s going to be hard to break that habit. This leads to inconsistent, sloppy code. Even if I eventually adopt my team’s standard, what happens when I move to another team or inherit a project from other developers? It also means that any new team member will also have to adopt our version of the acceptable number of spaces.

If you were to use tabs, you wouldn’t have this problem. Each developer can configure their environment to use a specific tab width; whether it be two, four, or even eight spaces. This makes everyone happy. Imagine if you forced everyone to use a specific font size or syntax highlighting. Obviously, these things don’t impact the quality of the code, so why not let everyone customize them to their own personal preference? Why are you being a white space Nazi?

5. Readability

Quick question: How many levels of indentation are there in the line with the //Case 1 comment?

····for (a = 0; a < b; a++) {
········switch (c) {
············case 1:
················// Case 1 (WHAT'S MY INDENTION LEVEL?)
············case 2:
················// Case 2
················break;
············default:
················break;
·········}
····}

Did you get four? If so, it’s because you had to read the surrounding code to figure it out. Now, let’s try it again with tabs.

--->for (a = 0; a < b; a++) {
--->--->switch (c) {
--->--->--->case 1:
--->--->--->--->// Case 1 (WHAT'S MY INDENTION LEVEL?)
--->--->--->case 2:
--->--->--->--->// Case 2
--->--->--->--->break;
--->--->--->default:
--->--->--->--->break;
--->--->}
--->}

See how much easier that was? Each tab is one level of indentation. With spaces, we’re at the mercy of the developer and whether he/she was consistent with the number of spaces. Finding errors with improperly nested code is much easier when tabs are used. You can’t accidentally forget a part of a tab, but you can easily enter three spaces instead of four.

By the way, I purposefully made a mistake in the number of spaces for one of the lines in the first example. Did you catch it? Would you have missed it if I had used tabs?

Why Spaces are Problematic

1. No Consensus on Amount of Identation

We touched on this in briefly in the points above, but it’s important enough to get its own section. No one agrees on how many spaces make up one level of indentation. Standards are important when it comes to code. Just because your team has come to a decision on a set number of spaces per indentation, doesn’t mean that they’re all happy with it, that they’ll all honor it, or that the decision will work on anything other than new, start-from-scratch projects.

With tabs, there’s only one decision to be made: tabs or spaces. With spaces, there’s tabs or spaces, and how many spaces. Given the advantages of tabs outlined above, I don’t see why this should be a hard choice.

2. Not Portable

What do I mean by “not portable?” I mean that if you share your space-indented code with anyone else (e.g. all those online tutorials where you can copy/paste the code), the recipient is going to have to reformat it for his/her environment. People that use spaces instead of tabs think that this is just par for the course, but tab users have a big advantage here — they can use the code as-is. Worst case, they may need to change the indentation level, but they’ll certainly never have to go through each line adding and removing spaces. And don’t say, “editor X handles this fine.” Wait until you have to work in a client’s environment where only Notepad is available.

3. They’re Hard to See

Spaces are a poor fit for indentation simply on the fact that you can’t easily see an individual space character among groups of spaces. How often have you been typing an Office document where you had to do a double-take to see if you had typed two spaces instead of one? Granted, this isn’t as much of a problem with fixed-width fonts, but it’s still a problem.

I absolutely hate it when developers use only one or two spaces for indentation, and it’s not because of bad eye sight. If your HTML or XML is so complex that you need tens of levels of indentation and it’s interfering with the available horizontal space in your editor, then you’re doing something wrong. If you must use spaces, use at least three or four.

Hopefully, you code with visible white space markers. If not, then maybe that’s why you don’t see the problem with spaces. In Visual Studio, use ctrl+r ctrl+w to show white space. In Sublime Text 2, add the “draw_white_space” setting to your user preferences and set it to “all”. If you’re a serious coder, then you should have a consistent use of tabs and spaces, where tabs (usually denoted by arrows) represent the level of indentation and spaces (usually denoted by dots) represent alignment characters. Here’s an example:

--->var myObject = { color: 'red',
--->·················size: 'small',
--->·················shape: 'circle'};

This seems to confuse a lot of people in the space camp. It should be easily noticeable that the code above has one level of indentation and that spaces have been used to align the “size” and “shape” properties so they line up nicely. For some reason, the space people claim this as something that can’t be done with tabs, and then they try to demonstrate their point by incorrectly using multiple tabs to align the properties. They don’t seem to understand that tabs are only for indentation. Spaces are for alignment.

So Why are Spaces Used so Often?

With all these advantages, why are there so many advocates for spaces? Here are a few possible reasons.

1. Misunderstanding of Difference Between Indentation and Alignment

Some people have a hard time knowing when to use spaces and when to use tabs, so for them it’s easier just to use spaces all the time. This is a cop-out, and if it’s your excuse for using spaces, then you need to learn the difference.

2. Code Editors that Replace Tabs with Spaces

Many code editors, Visual Studio included, default to replacing tabs with spaces and not showing white space characters. This leads to ignorance as to what is actually happening behind the scenes, and novice coders never learn to use tabs as they’re meant to be used. It also leads to a mixture of tabs and spaces that only looks good when viewed in the original editor.

3. Copy and Paste Programmers

Many developers learned how to write code by pasting it from other sources. Unfortunately, Web browsers aren’t the best at displaying code, and Web authors weren’t sure how to insert tab characters into their tutorials. This means that a large majority of the code that is shared online uses spaces instead of tabs.

4. Sloppy, Indifferent, and Poorly Organized Coders

Many programmers don’t care about what their code looks like. “As long as it works” is their mantra. These people are usually disorganized and write code that is difficult to maintain. They are entrenched in a specific code editor and are highly resistant to change or anything that jeopardizes their current method of writing code.


I hope you don’t fall into that last group and that you care about how your code looks. Well written code should be quick to create, easy to maintain, and it should look beautiful. Maybe that last bit isn’t important to you, but maybe you’re not passionate about what you do either. Use tabs for indentation. Spread the word.

What’s Up with the Ban on CSS ID Selectors?

I’ve seen an idea that appears to be gaining momentum: banning the usage of ID selectors in CSS. When I first saw this, I assumed it was the ramblings of a single individual that was venting over an inherited project where ID selectors were being abused, but I’m seeing it pop up more often, and it has me a little concerned. Fortunately, there are some people that are stepping up to show the problems with this idea, and I thought I’d join in. Here are a few quotes I’ve found that I’ve decided to address.

IDs are almost always against the DRY (don’t repeat yourself) principle. For styling, you can always used classes which make your code much more reusable. I personally have stopped using IDs and I believe using IDs is a lazy bad practice, but yea still “valid”.

Yes, IDs are not meant to be repeated! It seems that this is the biggest complaint against ID usage, and what’s funny is that it’s the way the CSS language is meant to work. An ID is a “one-off”. You use it when you are certain you’ll never need it again.

As for being a “lazy bad practice,” I’m a bit confused. If you’re using IDs out of laziness, you may as well use the !important keyword or inline styles. Good CSS coders don’t use IDs because they’re lazy; they use them because the situation calls for it.

I’m totally on the “never use ID’s” thing. If you are having a specifity problem, using a selector that infinitely more powerful than a class is a sledgehammer approach when you need a knife…

…and a class selector is infinitely more powerful than a tag selector. What’s your point? That’s the nature of CSS. You don’t see people trying to advocate a ban on classes for that reason. A knife is great for things that require a knife, but a blanket ban on IDs, is just like a blanket ban on sledgehammers. What happens when you need to tear down a wall? It’s going to take quite some time with that little knife.

The point is that you use the right tool for the job. IDs have their place in CSS and so do classes. Not knowing when to use them is not an excuse for removing them entirely. There will always be developers that use the language inappropriately, and telling them to ignore (or even ban) specific aspects of the language is a detriment to their learning experience. It doesn’t make them better coders, and it contributes to the number of “professionals” that know very little about their field.

I firmly believe that crafting CSS should always focus on re-usability, it should be about creating patterns instead of one-offs. IDs are unique by nature and so work inherently against this. No matter how much you think you’ll only ever use a pattern once, somewhere down the line you’ll find yourself needing it again.

Again with re-usability. CSS that is specific to one website should not be reusable. That’s what CSS frameworks/boilerplates are for. If you find yourself writing the same CSS for every site, then you should probably move it to your framework CSS. If you follow this design pattern, then the unique nature of IDs is perfectly plausible and very helpful. Otherwise, you run into design nightmares trying to override the specificity of your framework CSS with multiple class declarations. CSS such as the following is confusing and a pain to maintain:

.home-page .row .span-6 header nav .link { ... }

Especially when an ID selector does the job, while being more concise and clear:

#home-menu a { ... }

If you find that somewhere later down the line you needed a class instead of an ID, then you didn’t properly plan the structure of your website. Now, I understand that no one is perfect, and in the real world things change, but, that should be the exception and not the rule. Let’s be clear: ID selectors should only be used for areas of a web page that will never appear on the page more than once. If you aren’t sure, use a class — but don’t blame ID selectors for your poor planning.

I have a blanket-ban on IDs in CSS. There is literally no point in them, and they only ever cause harm.

Wow. I can think of multiple reasons to use ID selectors, and it’s very rare that they cause me harm. I really can’t believe that an experienced web designer would even try to validate such a claim, considering that the vast majority of websites make use of ID selectors regularly and have been doing so for many years. “No point?” Clearly, you’re in the minority, as most web experts are finding a purpose for them.

As for causing harm, the only reason that makes sense is if you aren’t using them correctly. This reminds me of the sledgehammer example; use the right tool for the job. Consider this: I have a div with an @id of “logo”. This div will appear once on each page. Using an ID selector is perfectly acceptable. Now, for the sake of argument, suppose I had used a class of “logo” instead. A year from now, this website is inherited by another developer. He needs to make some changes to the logo, but he sees that it uses a “logo” class. Hmmm… should he go ahead and reuse the “logo” class? Who knows? To his knowledge that may be a class that’s used on some other obscure page he doesn’t know about, and making an update would be a risk that bites him later. After all, that’s how classes are supposed to be used. So, what does he do? He either adds another redundant class or writes some weird specificity rule to make sure that he’s only targeting the logo he wants. Using an ID would have made this quite simple — it’s an ID, it’s unique, and it has a clear purpose.


What bothers me the most is that supposed experts in the field of CSS are putting their seal of approval on this idea. Requiring members of your web team to avoid the use of a popular language construct because they may use it incorrectly means that you freely admit your team members are not experts and you never expect them to be. What’s the reasoning behind this? Some programmers have a hard time with C# delegates. Let’s ban them! Some designers don’t know when to use the <address> tag. Let’s ban it! Some coders don’t know when to use single/double quotes in PHP. Let’s require double quotes for everything! Ignorance is not an excuse for limiting your toolset. IDs are a part of CSS for a reason. If you have a hard time with them, then either learn when to use them or let someone else do it. But please don’t push your nonsense on everyone that does use them effectively.

If anyone has a valid use-case for banning ID selectors, let me know. I’ve yet to hear of one, but I’m certainly open to discussion.