The Ultimate Vendor Lock-in

17 February 2005
12:40

I've recently had the privilege of working with a deployment of Microsoft SharePoint. While approaching the project with the appropriate skepticism, seeing SharePoint in action was still rather disillusioning.

What is it?

For those who don't know it, SharePoint is a web-based application that provides a kind of “one size fits all” intranet. It does management of documents and images, contacts and appointments, projects and discussions. Everything but the kitchen sink. It does none of it very well, mind you, but it does do a whole lot of stuff. It also provides a basic portal infrastructure, which allows the administrator to put together a portal from a fairly large set of “web parts” (a whidbey-ism?) And of course you can extend the whole system with your own custom parts.

SharePoint is also an environment that is tightly integrated with Microsoft Office and of course Windows. This and the price point is supposed to make it interesting for both medium and large businesses. And apparently, SharePoint has been pretty successful for Microsoft.

Web Standards. What Standards?

SharePoint only really works on Internet Explorer, and only on Windows. To be fair, I'll have to mention that it does provide a fallback UI for so-called “downlevel” browsers for some of the more trivial parts of the application. Simply viewing pages sort of works with browsers such as Firefox or Safari. Anything even slightly interactive is a major pain in those browsers though, and a significant part of the UI is completely blocked for user agents that don't identify as IE/Win.

The incompatibilities aren't about the Javascript code using document.all instead of document.getElementById() (it doesn't, mostly). It's about using the proprietary IE/Win event model instead of DOM Events, without even checking first. It's about using VML just for displaying a branding logo. It's about using ActiveX controls without checking whether the browser supports the proprietary ActiveXObject object, and without providing usable alternatives for other user agents. It's about using weird <IE:MENUITEM> tags to define context menus, and using a HTC behavior to implement those menus with Javascript. And it's about actually using VBScript as client-side scripting language for some functionality.

By the way, if there was too much scripting in that list for your taste, SharePoint completely blocks browsers that don't support Javascript (or where it has been disabled by the user). Enough said.

Don't even think about letting SharePoint come somewhere near the HTML validator. There's no DOCTYPE declaration, so the whole app runs in quirks mode. XML namespaces are being used in HTML (i.e. non-XML) documents, which is completely unsupported by any browser other than IE/Win. Made-up attributes and even elements are being added that are then somehow used by the 400kB Javascript library, for example to support drag and drop of web parts.

Rolling out, Locking in

And now imagine you're tasked with a deployment of SharePoint. You're supposed to adapt the design to the existing intranet. Your weapon for this is CSS, because anything that would change the ASP.NET “templates” promises to become a maintenance nightmare. Good luck with mostly invalid markup that runs in quirks mode. You can make it work in IE/Win by relying on its specific error handling, and by explicitly making use of the bugs in its CSS support.

But then some parts of the SharePoint deployment are to be made accessible to external customers and suppliers. The team demands compatibility with “Netscape” – a requirement that you usually translate to compatibility with Gecko-based browsers, and possibly Safari as well as Opera. Now, making a standards-compliant site work well in all modern browsers is relatively easy. But making a major hack of a site – like a CSS-customized SharePoint – work and look good in more than one browser is pretty much impossible.

But that just adds another layer of incompatibility and inaccessibility on top of the already prevalent cruft. At the end of the day, anyone who wants to seriously use SharePoint needs to be fully equipped with Microsoft software. The operating system, the web browser, the email client, the office suite. Don't think you'll be able to move away from Microsoft anytime soon with such infrastructure in place.

Interoperability by design? I don't think so.