Each server-side Web control in an ASP.NET Web Forms application has an ID property that identifies the Web control and is name by which the Web control is
accessed in the code-behind class. When rendered into HTML, the Web control turns its server-side ID value into a client-side id attribute. Ideally,
there would be a one-to-one correspondence between the value of the server-side ID property and the generated client-side id, but in reality things aren't
so simple. By default, the rendered client-side id is formed by taking the Web control's ID property and prefixed it with the ID
properties of its naming containers. In short, a Web control with an ID of txtName can get rendered into an HTML element with a client-side id
like ctl00_MainContent_txtName.
This default translation from the server-side ID property value to the rendered client-side id attribute can introduce challenges when trying to
access an HTML element via JavaScript, which is typically done by id, as the page developer building the web page and writing the JavaScript does not know what
the id value of the rendered Web control will be at design time. (The client-side id value can be determined at runtime via the Web control's
ClientID property.)
ASP.NET 4.0 affords page developers much greater flexibility in how Web controls render their ID property into a client-side id. This article
starts with an explanation as to why and how ASP.NET translates the server-side ID value into the client-side id value and then shows how to take
control of this process using ASP.NET 4.0. Read on to learn more!
Read More >Did you know that DotNetSlackers also publishes .net articles written by top known .net Authors? We already have over 80 articles in several categories including Silverlight. Take a look: here.
