For ease of use and extensibility Microsoft included WebControls in .NET. These controls are located in the System.Web.UI.WebControl library. Anyone who’s ever worked on a .NET web project has used a WebControl and they’re so easy that you probably haven’t even given them any thought.
The purpose of .NET WebControls are to provide a layer to keep the programmer from the lower levels of HTML, CSS, and Javascript and WebControls have done just that. In fact, developers can create entire websites without knowing any HTML. It’s a convenience and it allows for unsurpassed speed in development, however, there are certainly drawbacks to not knowing what HTML is rendered by each WebControl.
A Common Example
Before giving the reasons for learning lower level HTML, I’m going to show a common example of misused ASP.NET WebControls.
<table>
<tr>
<td>First Name:</td>
<td>Nate</td>
</tr>
<asp:Panel Id="pnlLastName" Runat="Server">
<tr>
<td>Last Name:</td>
<td>Yolles</td>
</tr>
</asp:Panel>
</table>
When the developer tests the webpage, it works. The table cell is either hidden or shown based on his C#/VB code. However, if you look behind the scenes at what HTML is generated and served to the browser, you will immediately see the problem.
<table>
<tr>
<td>First Name:</td>
<td>Nate </td>
</tr>
<div Id="pnlLastName">
<tr>
<td>Last Name:</td>
<td>Yolles</td>
</tr>
</div>
</table>
The HTML is malformed. An ASP.NET Panel WebControl outputs a DIV HTML element to the page. While the ASP page looks good to the developer and Visual Studio doesn’t give any warnings, the example is obviously an example of something not to do. Any HTML element within a TABLE needs to be within a table cell.
The correct way to accomplish the developer’s task is to simply make the table cell a server control and manipulate the cell’s visibility directly as shown below.
<table>
<tr>
<td>First Name:</td>
<td>Nate</td>
</tr>
<tr id="rowLastName" Runat="Server">
<td>Last Name:</td>
<td>Yolles</td>
</tr>
</table>
Why Does This Matter?
Because of the layer of protection that .NET provides, ignorant developers aren’t even aware that they’re not using best practices and in fact are harming their website. The biggest advantages to being cognizant of the rendered HTML are:
- Valid HTML & XHTML
- Optimization – page size and speed
- It’s a must for client-side scripting and AJAX
Valid HTML & XHTML
Today’s web browsers are fairly forgiving of malformed markup. While the uninformed may feel this is a benefit, it’s actually harming your website.
First of all, with malformed HTML, there’s no guarantee that your site looks like it should across all platforms and browsers. Furthermore, while it may look fine today, future browsers may handle the incorrect markup differently making the page unusable.
Most importantly though, is that malformed HTML has a direct effect on your search engine rankings. You could be wasting tens of thousands of dollars on Search Engine Optimization (SEO) if Google sees your website as “broken” or “invalid”. While Google’s ranking algorithms are highly confidential and constantly changing, it is known that sites with valid HTML are rewarded while sites with invalid HTML are seen as lower quality and are subsequently punished in their rankings. It would be a shame to see your site never make the front page because of some bad HTML.
Optimization – Page Size and Speed
In the example above, even if the markup were valid, the page size is increased bay adding more markup, and the page is complicated by adding more elements to the Document Object Model (DOM). Every time the markup is increased, page size increases, and the page takes longer to download. Every time the DOM is increased, the page slows down in both loading and client-size scripting. It obviously takes long for a script to search the DOM as the DOM’s size increases.
Client-Side Scripting and AJAX
If the developer doesn’t know what HTML is rendered from the .NET WebControl, it will be impossible to interact with the control via client-side Javascript.
Imagine you have form that you want to validate or submit through an AJAX call and you’re using the common jQuery practice of finding the form elements to submit by their CSS class names.
<asp:TextBox Id="textbox1" Runat="Server" CssClass="ElementToSubmit" />
<asp:CheckBox Id="CheckBox1" Runat="Server" CssClass="ElementToSubmit" Text="CheckBox" />
<asp:RadioButton Id="RadioButton1" Runat="Server" CssClass="ElementToSubmit" Text="RadioButton" />
var $ElementsToSubmit = $(".ElementsToSubmit");
I’ve seen people confused because they don’t realize what HTML is rendered by each WebControl. The problem with this example is that once you assign the CssClass attribute of the CheckBox and RadioButton WebControls, the HTML output is changed. The CSS class is not assigned to the HTML INPUT element, but rather a SPAN tag that surrounds the HTML INPUT elements. The Javascript above won’t find the radio and checkbox elements.
Call To Action
There are so few WebControls that it’s not a difficult task to learn the HTML output of each. I would strongly recommend all .NET web developers to take a few moments and learn which WebControls map directly to HTML elements and which WebControls create more complicated custom markup. Learn which elements create DIVs, SPANs or TABLEs; learn which elements HTML output actually changes depending on what attributes are used; learn proper HTML – it’s actually really easy and yet so surprising how many .NET web developers don’t actually know it.
Was this post helpful? Share it:
A common mistake in CSS is to assign the cursor property to hand. This is a holdover from Internet Explorer 5.0 and 5.5 which were released in the years 1999 and 2000 respectively – quite out of date. The proper value according to the W3C standards is pointer as shown below.
