In the early days of ASP.NET most developers didn’t write client side code. They just used server side UI controls and any programmatic interface state changes were restricted to post-back processing.

Enter Ajax, RIA, Scriptable Services, Scriptaculous, YUI, jQuery, HTML5, etc.

Now ASP.NET developers, no matter what ASP.NET flavor you are using (YES, including WebForms) need to hold some of the party IN the browser.

To manipulate the Document Object Model (DOM) elements we need to know HOW to address them.

WebForms has a built in feature that pertains to the client identity of HTML elements.

ASP.NET used an algorithm to determine the client side naming of a server side control.

When we didn’t ever need to manipulate the DOM from client side code this was a service because it meant that no matter how our server side controls were nested or contained we would never have naming collision in the browser.

One less this to worry about right?

So if we used an ASP.NET server side textbox control in a container on our form (like a panel) here is what the resulting html textbox declaration would look like.


<input id='ctl00_ContentPlaceHolder1_TextBox1' 
   name='ctl00$ContentPlaceHolder1$TextBox1' 
   type='text' value='Text' />

Beginning with ASP.NET 4 we have the capability to define how we want ASP.NET to handle the relationship between ASP.NET server side controls and the resultant HTML element Ids.

Introducing the ClientId property.

Note that we are talking about the “ID” attribute which we will use to address the element from JavaScript and NOT the “Name” attribute.

“Name” is how the server will see that element when a form is posted to it. “ID” is how the browser sees the HTML element so that is how JavaScript addresses the element.
We now have three ways that we can instruct ASP.NET to handle client ids.

  • Static
  • Legacy
  • Predictable

And we can set this as the default at the Machine, Project, or Page level (and override it wherever we want.)

One might use legacy (the default) if they are not writing client side code. As you would expect, it works the same was it always has (described above.)

Here is how you set the default ClientId mode for the page to “Static”.


<!--Page Language='C#' AutoEventWireup='true'
      CodeFile='Default.aspx.cs' Inherits='_Default'
      ClientIdMode='Static'-->

I nearly always use static. I specify the ID of the HTML element and that is the one ASP.NET uses – period.

Of course, this means that I need to do my own ame management and make sure that the same name is never used for two controls that will appear in the DOM at any one time.

No problem.

There is one time though when “Predictable” mode is a big help.

Suppose you are using a data bound list that contains controls but since it’s data bound you don’t necessarily know how many items that container will ultimately render. “Predictable” IDs means we can “PREDICT” the Ids and therefore we can still program against the individual HTML elements that resides in the container.

So, why am I telling you this now ?

Well, over the past couple of years I have generated TONS of content on doing things with Microsoft Ajax and the Microsoft Ajax Control Toolkit. Since then we have really pitched our support to jQuery.

So, I’m now going to create new content to demonstrate how to do all those Ajax and Client UI techniques using jQuery and modern ASP.NET HTTP services.

Stay tuned and let me know which ones you want me to provide first !