I like HtmlControls because there is no HTML magic going on... the asp source looks similar to what the client sees.
I can\'t argue with the utility of GridView, Re
In my experience, there's very little difference. As Darren said, if you don't need server-side functionality, HTML controls are probably lower-impact.
And don't forget, you can bolt server-side functionality onto almost any HTML control just by adding a runat="server" directive and an ID to it.
well... i wouldn't use an html control if you don't need to do anything on it on the server. i would do
<input id='btnCancel' type='button' value='Cancel' />
fin.
It might be useful to think of HTML controls as an option when you want more control over the mark up that ends up getting emitted by your page. More control in the sense that you want EVERY browser to see exactly the same markup.
If you create System.Web.UI.HtmlControls like:
<input id='btnCancel' runat='server' type='button' value='Cancel' />
Then you know what kind of code is going to be emitted. Even though most of the time:
<asp:Button id='btnCancel' runat='server' Text='Cancel' />
will end up being the same markup. The same markup is not always emitted for all WebControls. Many WebControls have built in adaptive rendering that will render different HTML based on the browser user agent. As an example a DataGrid will look quite different in a mobile browser than it will in a desktop browser.
Using WebControls as opposed to HtmlControls also lets you take advantage of ASP.NET v2.0 ControlAdapters which I believe only works with WebControls, this will allow you programatic config driven control over the markup that gets emitted.
This might seem more valuable when you consider that certain mobile browsers or WebTVs are going to want WML or completely different sets of markups.
By adding runat="server" you can get access to any HTML controls in server side.. and I believe HTML controls are less weight compared to ASP.NET server controls..