This is
the sixteenth in a series of blog posts I’m doing on
the upcoming VS 2010 and .NET 4 release. Today’s post is
the first of a few blog posts I’ll be doing that talk about some of
the important changes we’ve made to make Web Forms in ASP.NET 4 generate clean, standards-compliant, CSS-friendly markup. Today I’ll cover
the work we are doing to provide better control over
the “ID” attributes rendered by server controls to
the client. [In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu] Clean, Standards-Based, CSS-Friendly Markup One of
the common complaints developers have often had with ASP.NET Web Forms is that when using server controls they don’t have
the ability to easily generate clean, CSS-friendly output and markup. Some of
the specific complaints with previous ASP.NET releases include: Auto-generated ID attributes within HTML make it hard to write JavaScript and style with CSS Use of tables instead of semantic markup for certain controls (in particular
the asp:menu control) make styling ugly Some controls render inline style properties even if no style property on
the control has been set ViewState can often be bigger than ideal ASP.NET 4 provides better support for building standards-compliant pages out of
the box.
The built-in <asp:> server controls with ASP.NET 4 now generate cleaner markup and support CSS styling – and help address all of
the above issues. Markup Compatibility When Upgrading Existing ASP.NET Web Forms Applications A common question people often ask when hearing about
the cleaner markup coming with ASP.NET 4 is “Great - but what about my existing applications? Will these changes/improvements break things when I upgrade?” To help ensure that we don’t break assumptions around markup and styling with existing ASP.NET Web Forms applications, we’ve enabled a configuration flag – controlRenderingCompatbilityVersion – within web.config that let’s you decide if you want to use
the new cleaner markup approach that is
the default with new ASP.NET 4 applications, or for compatibility reasons render
the same markup that previous versions of ASP.NET used: When
the controlRenderingCompatbilityVersion flag is set to “3.5” your application and server controls will by default render output using
the same markup generation used with VS 2008 and .NET 3.5. When
the controlRenderingCompatbilityVersion flag is set to “4.0” your application and server controls will strictly adhere to
the XHTML 1.1 specification, have cleaner client IDs, render with semantic correctness in mind, and have extraneous inline styles removed. This flag defaults to 4.0 for all new ASP.NET Web Forms applications built using ASP.NET 4. Any previous application that is upgraded using VS 2010 will have
the controlRenderingCompatbilityVersion flag automatically set to 3.5 by
the upgrade wizard to ensure backwards compatibility. You can then optionally change it (either at
the application level, or scope it within
the web.config file to be on a per page or directory level) if you move your pages to use CSS and take advantage of
the new markup rendering. Today’s Cleaner Markup Topic: Client IDs
The ability to have clean, predictable, ID attributes on rendered HTML elements is something developers have long asked for with Web Forms (ID values like “ctl00_ContentPlaceholder1_ListView1_ctrl0_Label1” are not very popular). Having control over
the ID values rendered helps make it much easier to write client-side JavaScript against
the output, makes it easier to style elements using CSS, and on large pages can help reduce
the overall size of
the markup generated. New ClientIDMode Property on Controls ASP.NET 4 supports a new ClientIDMode property on
the Control base class.
The ClientIDMode property indicates how controls should generate client ID values when they render.
The ClientIDMode property supports four possible values: AutoID—Renders
the output as in .NET 3.5 (auto-generated IDs which will still render prefixes like ctrl00 for compatibility) Predictable (Default)— Trims any “ctl00” ID string and if a list/container control concatenates child ids (example: id=”ParentControl_ChildControl”) Static—Hands over full ID naming control to
the developer – whatever they set as
the ID of
the control is what is rendered (example: id=”JustMyId”) Inherit—Tells
the control to defer to
the naming behavior mode of
the parent container control
The ClientIDMode property can be set directly on individual controls (or within container controls – in which case
the controls within them will by default inherit
the setting): Or it can be specified at a page or usercontrol level (using
the <%@ Page %> or <%@ Control %> directives) – in which case controls within
the pages/usercontrols inherit
the setting (and can optionally override it): Or it can be set within
the web.config file of an application – in which case pages within
the application inherit
the setting (and can optionally override it): This gives you
the flexibility to customize/override
the naming behavior however you want. Example: Using
the ClientIDMode property to control
the IDs of Non-List Controls Let’s take a look at how we can use
the new ClientIDMode property to control
the rendering of “ID” elements within a page. To help illustrate this we can create a simple page called “SingleControlExample.aspx” that is based on a master-page called “Site.Master”, and which has a single <asp:label> control with an ID of “Message” that is contained with an <asp:content> container control called “MainContent”: Within our code-behind we’ll then add some simple code like below to dynamically populate
the Label’s Text property at runtime: If we were running this application using ASP.NET 3.5 (or had our ASP.NET 4 application configured to run using 3.5 rendering or ClientIDMode=AutoID), then
the generated markup sent down to
the client would look like below: This ID is unique (which is good) – but rather ugly because of
the “ct100” prefix (which is bad). Markup Rendering when using ASP.NET 4 and
the ClientIDMode is set to “Predictable” With ASP.NET 4, server controls by default now render their ID’s using ClientIDMode=”Predictable”. This helps ensure that ID values are still unique and don’t conflict on a page, but at
the same time it makes
the IDs less verbose and more predictable. This means that
the generated markup of our <asp:label> control above will by default now look like below with ASP.NET 4: Notice that
the “ct100” prefix is gone. Because
the “Message” control is embedded within a “MainContent” container control, by default it’s ID will be prefixed “MainContent_Message” to avoid potential collisions with other controls elsewhere within
the page. Markup Rendering when using ASP.NET 4 and
the ClientIDMode is set to “Static” Sometimes you don’t want your ID values to be nested hierarchically, though, and instead just want
the ID rendered to be whatever value you set it as. To enable this you can now use ClientIDMode=static, in which case
the ID rendered will be exactly
the same as what you set it on
the server-side on your control. This will cause
the below markup to be rendered with ASP.NET 4: This option now gives you
the ability to completely control
the client ID values sent down by controls. Example: Using
the ClientIDMode property to control
the IDs of Data-Bound List Controls Data-bound list/grid controls have historically been
the hardest to use/style when it comes to working with Web Form’s automatically generated IDs. Let’s now take a look at a scenario where we’ll customize
the ID’s rendered using a ListView control with ASP.NET 4.
The code snippet below is an example of a ListView control that displays
the contents of a data-bound collection — in this case, airports: We can then write code like below within our code-behind to dynamically databind a list of airports to
the ListView above: At runtime this will then by default generate a <ul> list of airports like below. Note that because
the <ul> and <li> elements in
the ListView’s template are not server controls, no IDs are rendered in our markup: Adding Client ID’s to Each Row Item Now, let’s say that we wanted to add client-ID’s to
the output so that we can programmatically access each <li> via JavaScript. We want these ID’s to be unique, predictable, and identifiable. A first approach would be to mark each <li> element within
the template as being a server control (by giving it a runat=server attribute) and by giving each one an id of “airport”: By default ASP.NET 4 will now render clean IDs like below (no ctl001-like ids are rendered): Using
the ClientIDRowSuffix Property Our template above now generates unique ID’s for each <li> element – but if we are going to access them programmatically on
the client using JavaScript we might want to instead have
the ID’s contain
the airport code within them to make them easier to reference.
The good news is that we can easily do this by taking advantage of
the new ClientIDRowSuffix property on databound controls in ASP.NET 4 to better control
the ID’s of our individual row elements. To do this, we’ll set
the ClientIDRowSuffix property to “Code” on our ListView control. This tells
the ListView to use
the databound “Code” property from our Airport class when generating
the ID: And now instead of having row suffixes like “1”, “2”, and “3”, we’ll instead have
the Airport.Code value embedded within
the IDs (e.g: _CLE, _CAK, _PDX, etc): You can use this ClientIDRowSuffix approach with other databound controls like
the GridView as well. It is useful anytime you want to program row elements on
the client – and use clean/identified IDs to easily reference them from JavaScript code. Summary ASP.NET 4 enables you to generate much cleaner HTML markup from server controls and from within your Web Forms applications. In today’s post I covered how you can now easily control
the client ID values that are rendered by server controls. In upcoming posts I’ll cover some of
the other markup improvements that are also coming with
the ASP.NET 4 release. Hope this helps, Scott
