About .NET controls. The problem is that virtually all controls that come with Sharepoint are built with a mixed frontend and backend. You can build any controls you want (except if you want webparts, you have to mix them then), but we’re not talking about just any system now, we’re talking about Sharepoint.

About codeplex: Sure, you can download stuff from there and use them instead, but wasn’t the reason you paid immense amounts of money for MOSS to not have to download stuff? The default Sharepoint stuff needs to be much more customizable.

I’ve working in a project where we’re pushed MOSS to the limits, making sure the customer are free to use everything that comes out of the box (all the things you mention). The problem is that the defaults are of such bad quality, that we often have to patch or hack them to make them usable. Or replace them fully by something from codeplex. That’s not a good way to build stuff.

1) No matter what size you have, it’s still half the RAM and processing power. No other CMS requires that. Period.

2) That it’s known and partly patched in a 3rd party addon does not make it OK. MOSS adds accessibility problems that most other tools does not have.

3) Yes, you can hack around the controls that are there to save you time.

4) Yes, I know all about hedkandi, it’s just as customized as the site I’m building. That you can add pretty images and custom CSS does not make it a good CMS (or other) tool. You can do that with any tool out there, anything else would be insane. MOSS requires you to hack more than any other one I’ve used.

5) Why do you need to download additional unsupported components to change things like blogs? Really, is that reasonable?

Not going to go through your points one by one, but a few things occured to me:

1) VPC size. I don’t know what you’ve been doing to your images, but my dev vpcs are all about 8GB in size. I’d look at optimising your vpc builds…

2) Accessibility. This is a known issue, which the Accessibility Kit for SharePoint is fixing in part. For public facing webs, you have more flexibility, but the editing functionality is always going to be a problem from an accessibility point of view (which is not limited to MOSS, btw).

3) Control adapters can help with OOTB controls such as the menu / nav controls. See the ASP.NET CSS Control Adapters for more info.

4) You can brand SP sites, see for example http://www.hedkandi.com for a more “design” focused example.

5) Branding blogs and application pages - see the “Community Kit for SharePoint” and “SuperBranding”, both on CodePlex.com for examples of how to do this easily.

Though, you can skin the admin interface with some branding elements and colors.

CSS Specificity works flawlessly provided one uses body id ="". Specificity also allows one to overwrite in-line styles (of which MOSS has an incredible amount) by using !important.

As to your comment about SharePoint lack of blogs with detailed help: you can find all sorts of programming help but nearly all of the articles are written by persons that do not seem to have heard about Web Standards. (Heather Solomon being the exception.) And, most of the fixes are ASP.NET 2 complicated.

From the amount of new articles on Web Standards sites (like yours), it seems that MOSS instead of IE6/7/8 has become the new poster child for Web Standards education.

If you decide to use MOSS, at least avoid forms! You will get a lot of problems with adapting them.

I would like to say that Intranets should also be accessible, not only public websites. There is of course people with accessibility problems using Intranets as there is people using public websites.

Browser support is also important, you never know when the IT department decides to switch and instead of using IE start using OP or FF. That happened on IBM when they tried to go from IE to FF. Because so many Intranet applications where built for IE they could not make a big shift.