What’s wrong with Microsoft’s CSS Friendly Control Adapters?
Are they dead? A colleague recently pointed me to a blog post from October that makes this sensational claim. While I actually agree 100% with the author’s main conclusion, there are some issues that need to be addressed, as there seem to be a couple of important facts that the author seems to have either been unaware of, or conveniently overlooked. Let’s place the blame where it is deserved.
The CSS Friendly Control Adapters were never an official product.
That’s right, they were code samples that accompanied a white paper illustrating how to extend the System.Web.UI.Adapters.ControlAdapter class shipped in .NET 2.0. The fact that these were released as sample code is clearly noted in:
- The summary of the white paper (“This white paper discusses control adapters in general and a sample set of adapters in particular. The samples demonstrate how you can adapt controls so they are easier to style with CSS…“);
- On the main entry page (“These sample control adapters demonstrate…“); and
- On Scott Guthrie’s blog post announcing the toolkit (“This toolkit provides information about how the ASP.NET 2.0 Control Adapter Architecture works, as well as a set of 5 sample control adapters (with full source that you can optionally tweak/modify)…“).
I think it was very clear from the beginning that this was sample code to accompany documentation. As such, I’m not sure where the author’s expectations came from. Sample code is never intended to meet everyone’s needs, to be robust and full-featured, to be bug-free, or even to be maintained. It is written to illustrate a concept. Microsoft never “promised” anything with this code.
Microsoft never “withdrew support”.
Remember, this is sample code; it exists as part of official documentation to illustrate a concept. This piece of official documentation is still hosted and provided by Microsoft at www.asp.net/cssadapters, with a forum that is still visited by the original developer. The base classes originally released in .NET 2.0 are still there in .NET 3.5.
Quite the opposite of withdrawing support, Microsoft released the code under the MS-Permissive license to allow re-use and then went a step further — they listened and responded to the community that sprung up in the forums by turning over future direction and development to the community. You can read through the forums if you want to know more of the history. The community wanted to have control of this code, and expand upon what Microsoft had done since Microsoft had no intention of doing so itself. Microsoft listened, and gave the community what it asked for.
So what is wrong?
I’ve never been a Microsoft apologist, and I’ve been a frequent critic of their products, their marketing, and their business practices. But let’s give credit where credit is due. I applauded the decision to open source this code, and it turned out to be an early sign of a much more open and transparent way of doing business within this sector of the .NET division (cf., ASP.NET MVC). While the author blames Microsoft for the lack of maintenance, that is entirely the fault of the community. Let’s address a couple other common misconceptions within the Microsoft community.
- The rate of binary releases does not reflect the health of the project. The author seems to think that the project is dead because there haven’t been any further binary releases since the move to CodePlex. This seems to be a common view in the Microsoft ecosystem. In fact, the CodePlex site shows that there has been a regular (but not frequent) stream of code commits, including three commits so far in 2009. In open source software, changes to the source are the key indicator of a project’s health, though things like project maturity obviously play a part in determining rate of change.
- Open source software is not freeware. Freeware is simply software that you aren’t asked to pay for. Open source software is software that you have the ability to fix for yourself. At least since April 2007, only one person has committed any code. In the forum thread where Microsoft “handed over the keys”, the current maintainer posted, “If anyone wants to be added to the developer list, send me your CodePlex user name and I’ll set you up.” As of today, there are only four other developers listed in CodePlex and none of them seem to be actively contributing. That’s a failing of the community, not of Microsoft. The “you owe me” and “why don’t they fix it?” attitudes seems to be much more common in the Microsoft community than in the Java or Ruby communities. Rather than complaining, send in a patch, as others have done. Patches are almost always welcome, and they benefit everybody.
Ultimately, the technical problems noted by the author are the fault of the community, not Microsoft. The community has the power to fix the code, but few have stepped up to the challenge.
Microsoft is ultimately to blame for the situation.
Wait… what? At the top, I said I agreed 100% with the author’s main conclusion, and I do:
Microsoft needs to redesign their server controls to emit accessible, semantically meaningful, layout-table-free markup from the get-go. In my opinion, they really dropped the ball by not doing this in ASP.NET 3.5. If that had meant retaining some legacy 2.0 server control versions alongside their 3.5 counterparts, so be it. I can understand needing to maintain backward compatibility with 2.0 and not wanting to break existing sites. But that’s no reason to hobble designers who have long since abandoned layout tables.
Isn’t it about time Microsoft stopped kicking this can down the road? I mean come on, it’s 2008 for chrissake. Is lean, mean, and meaningful HTML from ASP.NET server controls too much to ask for at this point? If you ask me, it’s an idea whose time is long overdue.
That really is the bottom line. If Microsoft had built their controls to emit standards-compliant markup from the beginning, the entire ControlAdapter architecture would have never been necessary. It is an ugly hack, but sadly necessary if you want to use WebForms and accessible, semantically meaningful HTML without rewriting all your controls from scratch. And that is what’s wrong with the CSS Friendly Control Adapters — the simple fact that they are necessary.
In term of their implementation, the CSS Friendly Control Adapters are a good 90% solution, and the ones I’m using in my current project do everything I want. They aren’t perfect, but when I look back at the code I wrote last week, or last month, or last year, I can point to a lot of decisions I regret more than my decision to use these adapters. As long as I’m doing WebForms, I will continue to use them.
2 comments
Interesting.
Perhaps you should familiarize yourself with the controversy surrounding Oxite. The MIX team released it as a “code sample” only, and despite many repeated and breathless caveats that it wasn’t a “best-practices” example, they got taken to the woodshed over it — by those in other divisions of MS itself, no less. As well they should have.
I would assert that no one under the auspices of the Microsoft “umbrella” has the luxury of putting out sloppy, buggy, and imcomplete work and hiding that fact behind the “code sample” fig leaf. They have an obligation to try to understand how their “samples” will be perceived, embraced, and adopted by the community. If the community perceives it as a MS-endorsed offering, then that’s what it will be treated as — despite what MS themselves may say to the contrary. To most of us, if it looks like a duck, walks like a duck, and quacks like a duck, it’s a duck.
However, I enjoyed the post. It was thoughtful and well written. I have subscribed to your blog and hope you write more frequently in the future.
By the way, feel free to view my response:
http://leedumond.com/blog/blog-etiquette-the-art-of-the-duel/
Thanks for the feedback!
I’ll disagree with your assertion, though. Microsoft absolutely has the luxury to release sub-standard or incomplete work due to their numerous revenue streams and power in the industry. They should understand how their actions and output will be received, but they are not obliged to understand, and they frequently do not. Case in point: Oxite. Case in point: the architectural guidance on REST and DDD just released by Patterns & Practices. Case in point: their complete ignorance of web standards in browsers through IE6 and their developer platform and tooling.
If it’s a Microsoft-branded duck, I’m not going to make any assumptions about it. I’m going to verify that it doesn’t fart instead of quack. Oxite and the control adapter toolkit are very different. I am familiar with the controversy, and I see little relevance. Oxite is a farting duck. They are now trying to position Oxite as sample code, but when it was released the MIX site made a number of extraordinary claims, like:
The MIX site still leads off, “Oxite… can run anything from blogs to big web sites. We know this because it runs MIX Online.” Sure, it says sample, but they also claimed that it was production-ready (it wasn’t), battle tested on one of Microsoft’s showcase sites (okay), and yes — built with best practices (absolutely false). That’s why they got raked over the coals. They established expectations that they couldn’t deliver on. Now they’re engaging the community and the MVC team at Microsoft, but they’ve lost their credibility. The MIX team clearly did not understand how their product would be received. On the other hand, the control adapters were never marketed as anything other than sample code.
Your expectations are your own, and if the control adapters didn’t meet them that’s fair. They met my expectations, and quacked just like they claimed they would, and didn’t tear up the lawn or terrorize the kids. I accept the value they provide, and don’t try to make them do things they weren’t intended to do. I sometimes tweak the code from project to project, and if I really need them to do more, then I can roll up my sleeves and change them myself. That’s the beauty of open source software. Microsoft granted them to the community almost two years ago. It seems misguided to blame Microsoft for any perceived shortcomings since then.
Anyway, I’m done on this subject. Like I said above, there are other things I regret more than using these control adapters, and there are other areas I’d rather focus my attention in future posts.