Controls versus standard HTML

Question

I\'m getting into ASP.NET (C# - I know it doesn\'t matter for this particular question, but full disclosure and all that), and while I love that the asp:-style

Answer 1

The short answer is that you should never use an asp:... version of a standard HTML control unless you have a really good reason.

Junior developers often get suckered into using those controls because they're covered in most ASP.NET books, so it's assumed that they must be better. They're not. At this point, after 8 years of daily ASP.NET development, I can only think of 2 or 3 cases where it actually makes sense to use an asp:... INPUT control over a standard HTML one.

Answer 2

As Dave Ward has already mentioned, "it's ASP.NET's way of preventing ID collisions."

A very good example of this is if you're attempting to put a control inside of a custom control, then use that custom control in a repeater, so that custom control's HTML would be output multiple times for the page.

As others have mentioned, if you need to access the controls for javascript, use the ClientScript property which will give you access to a ClientScriptManager and register your scripts to the page this way. Be sure when writing your scripts to use the ClientID property on the control you're trying to reference instead of just typing in the control's ID.

Answer 3

If the ID's prefix added by ASP.NET is an issue for you to access them later using JS or something... you have the .ClientID property server side.

If the overhead added by ASP.NET you should consider ASP.NET MVC (still preview) where you have full control over the emitted html.

I'm moving to MVC because I don't like all that stuffs added too....

Answer 4

I think most of the answers here take a designer's point of view. On a small-to-medium project it might seem like an overhead to synchronize code and CSS/HTML and make them standards-compliant and clean. A designer's way to do that is to have full control over rendered HTML. But there's many ways to have that full control in ASP.NET. And for me, having the required HTML in the aspx/ascx file is the most non-scalable and dirty way to do it. If you want to style controls through CSS, you can always set a class server-side through the CssClass property. If you want to access them through JS, you can emit the JS with right IDs server-side again. The only disadvantage that this provides is that a dev and a designer have to work together closely. On any large project this is unavoidable anyway. But the advantages ASP.NET provides far outnumber these difficulties. Still, if you want standards-compliant HTML, skinning support and other goodies to control rendered markup, you can always use thrid-party controls.

Answer 5

Personally,

I think the standard ASP.NET controls are fine for inhouse stuff - quick and dirty is good in that scenario. But, I once worked with a web developer who was also a designer and he refused to use the ASP.NET controls and only code in HTML and add runat="server" tags when needed. This was more because he wanted to know exactly how his HTML was going to be rendered, and at the time anyway, some of the ASP.NET controls wouldn't render to standards compliance.

I sit somewhere in the middle - use HTML where appropriate and not when not. You can sort of best of both worlds with the CSS control Adapters

Answer 6

I'm actually quite relieved to see some opinions here agreeing with my own: ASP.NET as a template language is very poor.

I'd just like to rebut a couple of the pro points made here (flamesuit on!):

Dave Ward mentions ID collisions - this is true, but my how badly handled. I would have preferred to see nodes referenced by xpath or deep css selectors than by making the ID effectively useless except by deferring to ASP.NET internals like clientID - it just makes writing CSS and JS that much harder pointlessly.

Rob Cooper talks about how the controls are a replacement for HTML so it's all fine (paraphrasing, forgive me Rob) - well it's not fine, because they took an existing and well understood language and said "no, you have to do things our way now", and their way is very poorly implemented. e.g. asp:panel renders a table in one browser and a div in another! Without documentation or execution, the markup for a login control (and many others) isn't predictable. How are you going to get a designer to write CSS against that?

Espo writes about how controls give you the benefits of abstraction if the platform changes the html - well this is clearly circular (It's only changing because the platform is changing, and wouldn't need to if I just had my own HTML there instead) and actually creates a problem. If the control is going to change with updates again how is my CSS supposed to cope with that?

Apologists will say "yes but you can change this in the config" or talk about overriding controls and custom controls. Well why should I have to? The css friendly controls package meant to fix some of these problems is anything but with it's unsemantic markup and it doesn't address the ID issue.

It's impossible to implement MVC (the abstract concept, not the 3.5 implementation) out of the box with webform apps becuase these controls so tightly bind the view and control. There's a barrier of entry for the traditional web designer now because he has to get involved with server side code to implement what used to be the separate domains of CSS and JS. I sympathise with these people.

I do strongly agree with Kiwi's point that controls allow for some very rapid development for apps of a certain profile, and I accept that for whatever reason some programmers find HTML unpleasant, and further that the advantages the other parts of ASP.NET give you, which requires these controls, may be worth the price.

However, I resent the loss of control, I feel the model of dealing with things like classes, styles and scripting on the codebehind is a wrongheaded step backwards, and I further feel that there are better models for templating (implementation of microformats and xslt for this platform) although replacing controls with these is non-trivial.

I think ASP.NET could learn a lot from related tech in LAMP and rails world, until then I hope to work with 3.5 MVC where I can.

(sorry that was so long </rant>)