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 controls save me a lot of tedious HTML-crafting, I am often frustrated with certain behaviors. I encountered one last night when working with Master Pages: my <asp:BulletedList ID="nav">, when converted into HTML, became <ul id="ct100_nav">.

There are other issues--I noticed that when you auto-populate a DataGrid, it adds attributes to the resulting table that I don't necessarily want there.

I know that there is a certain amount of "convention over configuration" that you have to accept when you rely on a framework to take over some of your tedious duties, but the "conventions" in these cases aren't so much any established conventions, but rather unnecessary extras. I know why the ID adds the prefix, but I should be able to tweak and turn things like this off, especially since, as a bit of a web standards evangelist, I don't duplicated HTML id's in a single page anyway.

So the question here is for those ASP.NET devs more seasoned than I: in your experiences in developing and deploying apps, how do you leverage these controls? Do you find yourself resorting back to hard-coded HTML? Do you use a blend? I don't want to design my HTML around idiosyncratic quirks in these controls, but, if possible, I'd like to leverage them when possible.

What's a boy to do?

Answer 1

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 2

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>)

Answer 3

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.