Managing Client IDs

Considerable time has gone by since the ASP.NET platform was first conceived in the late 1990s. ASP.NET came about when the successful Visual Basic form-based model was brought to the web. In doing so, ASP.NET designers came up with a component model similar to the one available to desktop developers. The overall idea was to give developers, say, a TextBox component where a text input field was expected in the UI. Such a TextBox component would have a number of properties and fire a number of events, so that developers could work with it through an abstract programming interface.

In the desktop world, the output of Windows Forms controls refers to the underlying native windows infrastructure with associated painting and messaging subsystems. Basic Windows Forms controls are the transposition of low-level windows; more sophisticated controls result from the composition of multiple low-level windows. Such windows, though, never pop their head into the public API and remain buried in the folds of the Windows Forms framework. The ID assigned to the Windows Forms control is the only ID that developers are required to know.

The Web Forms framework is built around a similar model, but with some key differences. In this article, I'll discuss how IDs for child elements are generated in Web Forms, which problems are to be faced and possibly resolved, and how ASP.NET 4.0 is coming to the rescue.

Control IDs in Web Forms

In Web Forms, the output of web server controls refers to HTML elements and the document object model that the client browser builds on top of the source HTML. Basic server controls are the transposition of a single HTML element; for example, the TextBox control is equivalent to an HTML element. Richer server controls result from the composition of multiple HTML elements. For example, the CheckBox control includes an element and a

The huge difference that exists between Windows Forms and Web Forms is that any HTML elements forming the output of a web control are visible to any piece of code running within the client browser. This means that any client-side code (i.e., JavaScript code) can script individual pieces of HTML produced by one or more server controls. Because you can program the same control from both the server and client, and because the HTML transposition of a server control may originate multiple elements, you need two distinct sets of IDs to exercise full control over the interface.

The unique ID that identifies the server control may be insufficient on the client if the HTML output of that control produces multiple elements. In addition, in Web Forms you can use data-bound template-based controls. Such controls work by repeating an HTML template once for each bound data item. The IDs of the elements in the repeatable template must be created in a way that makes each ID unique and predictable in order to be scripted.

Auto-Generated IDs

When you place a server control within a Web Form, you must give it a unique ID. If you don't do that explicitly in the markup, an auto-generated ID will be used as the page markup is processed into a page class. In this case, the auto-generated ID takes the form of ctlXX where XX is a progressive number. If you add controls through the Visual Studio 2008 designer, a slightly more readable ID is generated that mirrors the name of the control and adds a trailing index, such as TextBox1.

In a nutshell, any ASP.NET server control needs to have a unique value assigned to its ID property. The value of the ID property is then used to set both the ID and name the HTML attributes in the resulting client page markup. In HTML, the ID attribute is primarily used to script the control via JavaScript. When you use document.getElementById to get a reference to a DOM element, you must indicate the value of the ID property. The name attribute, instead, is only valid within an HTML form and is used to identify form elements such as ,


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.