Sharepoint 2007 – insanely bad HTML

Sharepoint 2007 continues to amaze me with its terrible interface code. This is code you stumble over all over the place, both in places where you can hack your way around them, and in places where you just have to live with them. Some things are very hard to live with, let me show you:

ASP.NET developers made a decision once to include some hidden form fields, called viewstate, on all aspx pages. When deciding how to include those fields they chose an input with the type set to hidden. When the Sharepoint developers wanted to do something similar they decided on another route:

So we have a visible textbox, hidden with CSS, that has a size of 1 character. No wait, we have two textboxes and they both have very descriptive names (NOT). What the heck were they thinking? Why not type=”hidden”, and remove size? Or, I know, don’t add them at all, they are only dummy right? Note that they are empty.

Another strange interface decision is the one to include a skiplink in the page. Skip links are links that help screen readers (and others) to navigate to important areas quickly. There’s many different ways to implement them, here’s the Sharepoint way:

The .ms-skip class positions it far off screen to the left, and the javascript… wait, javascript on a skip link? Why on earth did they not add #mainContent to the href attribute directly? Only they know…

Next in this post is a more philosophical piece of HTML. Look at this:


I’ve heard about setting text direction to rtl (right to left), and ltr (left to right, for some eastern languages), but never to none. Where do text go that has no direction? Inwards? And what about having a table inside a span element?

ASP.NET also have user controls, a way to abstract out important pieces of code, to make reuse easy. Sharepoint of course uses this convenient tool regularly, and comes with a couple of useful ones:


In the documentation for SPRememberScroll you can learn… absolutely nothing about it. It seems to strangely interact with a TreeView somehow, and even worse, it has a width and height! I guess it’s good that it’s separate from the TreeView itself, so we can remove it from there if we want to forget where we’ve scrolled to. What?

Sharepoint 2007, note the year there, also both have the classical spacer gif and a new one; the spacer span:

Spacer gif:

Spacer span:

Starting with the spacer gif: Luckily they have their width set twice, both on the image and the cell. Note the “4px” there, you can’t use CSS units when you’re writing HTML, HTML only knows about pixels. You’re glad you wrote the width twice now, right? The spacer span is a fairly new thing I guess, the strange thing here is that you can’t set a width and height on inline elements. It just doesn’t work, sorry.

If you’ve built your user controls really bad, you might need a way to let people customize its HTML to make sense. Sharepoint has a couple of different ways to do this, one that they use themselves like this:

If you manage to read that, you can see that they are injecting a table row somewhere inside their control (which of course generates a table). Is it just me that feels the urge to add an ending table tag to SuffixHtml just to see what happens?

Another truly interesting interface construct is the datepicker. It’s one of these ordinary little calendar icons that opens in a little box and lets you pick a date. How did the Sharepoint guys (or girls) implement that?

Select a date from the calendar.


Ok, lots of code to analyse here, and I’ve still only cut out the middle of a couple of nested tables. A link with an onclick that opens the datepicker is fairly standard, all parameters needed are encoded into a long url sent to that method. There’s an image to click, with a strange img ending tag, but that could have been a mistake. The strange thing here is the iframe that points to a blank image. It’s inserted into a table right between two cells (yes, you read that right). That’s just insane. If you for some sensational reason have to use an iframe to display some HTML, output it javascript instead of just setting the src with js. Seriously people. Nice accessibility feature though, to have the alt text both on the image and on the iframe. Twice as accessible!

Another not-so-fine interface implementation is the following: They want to show a heading and a list of links. Personally, I would have used a heading tag, and an ul with links in. Sharepoint does it like this:

Black heading, list items with yellow dot before



They break their own scheme of prefixing all their classes with “ms-” (something that severely messed up my header), they repeat ids, they use only divs and spans, and inline styles.

Do I need to say more? Want to spread the word? Vote on reddit.

17 responses to “Sharepoint 2007 – insanely bad HTML

  1. Ok, if you posted this on April 1, I never would have believed any of it. It’s just… not …believable. But since it’s June, I’m laughing so hard right now that I think I might pee my pants.

  2. Now I’m really looking forward to the upcoming Sharepoint project that I have in the pipeline, NOT!

  3. Reminds me of the html that frontage would spew out. A page with one word would be 6k…

  4. Absolutely unbelievable!?! I couldn’t even read this whole post. I can’t even see the humour in it because it is just so bad.

    I can’t even comprehend how this corporation succeeds. I’d be interested in hearing their defense and justification for such sloppy workmanship. SHAMEFUL!

  5. Well our company bought sharepoint, we get to deal with this and hundreds more frustrations every day.
    If you think the HTML is bad, wait until you actually work with the rest of it…

  6. I sure would like to see an official m$ response on this.

    tip of the day; “don’t buy moss” (or any other m$ product)

  7. Pingback: Twan van Elk » Blog Archive » Linklog
  8. Dude, you just got EVERY web developer that stumbles this page to go “OH SHIT, what if my site’s next??” – but after reading it i can tell that this is way worse than anything you could find in my app. Anyway shitty tools output shitty code – this would never have happened in Rails.

  9. @sikanrong: I’m not sure what you mean but I think this is bigger than a Microsoft vs. Open source argument (anything Microsoft did vs. Rails). Microsoft do good things and bad things, this is the worst thing they have ever produced!

    In other words, I agree :)

  10. I sure agree that the code in WSS and MOSS is terrible, if not [ insert your WORST NIGHTMARE]. But I still believe that the idea behind all this is great!

    We are going to use Sharepoint really soon as it integrates nicely into our new AD/Exchange-Network. I just got a decent helpdesk up and running in a bout 30minutes. The technology is good, the implementation (code) is bad. That’s M$ technology. We have to live with it [DAMN]…

    What really annoys me about this, is the fact that they just released MOSS 2007 a couple months ago…

  11. Developing “custom” code for MOSS is a painful experience too. There’s no way to use the SharePoint.dll remotely, all interaction development that requires it’s use means that you have to have Visual Studio installed on that server to even begin to think about it.

    Also if you don’t want to go that route… they have web services… unfortunately those have a fairly steep learning curve when you have to use CAML to create/update/delete lists. Consider the following as well: for a system that seems to want to be the a central document storage system for team collaboration… they might want to have a web service that would allow for programmatically doing bulk file uploads to a document library… but they don’t.

Comments are closed.