Default HTML in Sharepoint 2007

Sharepoint 2007 has been “updated” to support masterpages, a concept from .NET 2.0. Sharepoint’s implementation of masterpages has several problems, but none of them even come close to the biggest problem of them all: default.master.

Default.master is the page that ships with Sharepoint and is used everywhere by default. A quick glimpse at it would make any seasoned web developer feel sick, and I quickly replaced it with something homemade. If you keep reading you will see why. Let’s get going with the first line:

Things start out really bad, without a doctype on the first line. This mean that all default pages will render in quirks mode, making rendering unreliable across browsers. Next they set an XML namespace, which after some googling points to very thorough documentation (pun intended). So they mean that it’s an XHTML document? No, because XHTML has lowercase tags, and here they use uppercase. The attribute __expr-val-dir just doesn’t exist.

A hardcoded link to the 4000 line “core.css” (filled with classnames you have to override by hand), and five external hardcoded javascripts then follow. Then 30 lines of inline CSS and javascript. Then comes the next real beauty, the body tag:

SCROLL, which is only recognized by MSIE, indicates if there be scroll bars on the page. The default value is YES, so the only reason to use SCROLL is to set it to NO. SCROLL serves little purpose except to confuse and annoy readers by removing scroll bars which are there for a good reason.

I couldn’t have said it better myself. There’s no reason, whatsoever, to use the scroll attribute. Ever. Especially with “yes” set. Pause for deep breaths. Then we have the inline javascript. Did you know that you could put javascript: inside of onload? Despite all odds, it seems to work. _spBodyOnLoadWrapper() is by the way Sharepoint’s way of letting you add javascript to pages. You first do a _spBodyOnLoadFunctionNames.push("YourFunctionName");, and then that code will get run. Insane.

Then we have the typical ASP.NET form, encapsulating the whole page, followed by 18 hidden HTML fields (including the infamous viewstate). Directly afterwards, we have a 60 line mix of inline and external javascript, contained in 7 different code blocks (two that’s missing the type and language attribute).

The next discovery can be found three nested tables later:

<spanid="TurnOnAccessibility"style="display: none"><aonclick="SetIsAccessibilityFeatureEnabled(true); UpdateAccessibilityUI();return false;"href="#"class="ms-skip">Turn on more accessible mode</a></span><aonclick="javascript:this.href='#mainContent';"href="javascript:;">
class="ms-skip" AccessKey="J">Skip to main content</a>

I’ll wait until you regain consciousness. Hi, welcome back. Yes, they are using display:none and javascript calls to enable “accessibility mode”. I mean seriously, screen readers ignore things with display: none set, and we can certainly not always trust that javascript is enabled. I also love the skiplink, and how it sets its own href attibute to an internal link. Note how this code is (mostly) lowercase.

And this is where it starts to get ugly. Every Sharepoint page has a Personal menu and a Site menu on it, containing things you want to do with your account or the current site. Fair enough. This is the (rather lengthy) code for the Personal menu:

There’s several things worth a note here (in a bad way). The menu tag Sharepoint uses is in fact a real HTML tag, deprecated in HTML 4.01. Inside of that we have a tag called ie:menuitem that I really can’t understand. What on earth is ie:menuitem? Did they intentionally not make it work in other browsers? Everything is wrapped inside a display: none; As you see, tags are also cluttered with event handlers, both real and made up ones. The contextmenu is blocked twice, and a spacer gif is used to add alternate text to the link. The menu icon is hardcoded into everything.

It goes on in the same manner, with tables with the “TOPLEVEL” attribute (and no value), divs with a WebPartId set, PlaceHolder tags rendered directly out in the HTML (instead of parsed by ASP.NET), to end with 200 lines of mixed inline javascript and css. Everything embedded in several layers of nested tables.

In conclusion

Default.master contains the worst code I’ve ever seen, and it’s really disappointing to see that from a product with “2007” in it. Microsoft have failed in every possible way when it comes to the interface code, and I believe the only way out is to rebuild Sharepoint from scratch (not likely to happen). Having to work with Sharepoint is a real pain, and I honestly don’t recommend it to anyone. Put your curiosity to use into something more interesting, like the ASP.NET MVC Framework instead. Thanks for listening.

Wow. I believed Gartner when it said that SP was gaining a lot of points in this last version (magic quadrant for wcm). But for any client looking for a platform like this, the customization is essential. How can we explain in lame terms these huge issues? Stakeholders usually fall for the lazy coders arguments (pro M$) and the small visual gadgets… How do I explain this to a 8 year old kind of audience?
Anyway, excellent article. Thanks for the great input.

Thank you for your contribution to the community on Sharepoint 2007, Emil.

Thanks to your blogposts about that Microsoft product, I will really try to avoid the product if we’re to ship any custom design Sharepoint installation to a customer.

Code like this basically comes down to one thing – a back-end developer writes front-end code without really having a clue. A common misunderstanding at many, many companies today is any web programmer can write all the code necessary to fulfill the task.

Thanks for sharing this. This really shows that Sharepoint 2007 cannot be used in the public sector (in Sweden) without big investments (time or $). I wonder if MS have thought about this? This must have an big impact on MS. What government or municipality wants to pay extra money just to make the system accessible and support standards?

Thanks for your clarifying and explanatory articles on MOSS/Sharepoint, they’re an invaluable resource!

I can’t fathom that a hack such as this even gets released. Where’s their Quality Assurance, where’s the performance, cross-browser and platform concerns, where is the accessibility (because what you show us is quite the opposite)?

I’m laughing so hard. This is THE funniest thing I’ve seen or heard in a long time. It tops this Forehead Shavecut thing I found a few days ago. If you’d posted this on April 1, I certainly wouldn’t have believed any of this. It just doesn’t make sense why anyone would purposely create a program that goes out of it’s way to make bad code… which means the makers of the program had to do extra work to make the users of the program do extra work. Huh?

It truly is remarkable isn’t it? I keep telling myself, “this isn’t THAT bad, is it?” and then I find some new horrible aspect of it. Yesterday I used a lowercase ASP.NET tag (ASP is case insensitive, so you should be able to do that), but found that MOSS added a new html element at the end, totally breaking everything. It’s bad.

I agree on all points, Emil, and our article really emphasize why Cameron Moll’s skinning is so impressive (at least by the looks of it).

But in this context it is important to point out that there are some community efforts trying to work around these issues, to some degree. I am thinking of Accessibility Kit for SharePoint (AKS) version 1.0, released in December last year. It claims to be a toolbox for creating web sites that conforms to WCAG 1.0 AA. It’s a set of master pages, new controls and webparts along with technical documentation. No silver bullet, for sure.

This first version 1,0 is aimed only at WCM sites. Next version will take care of team sites (don’t know about collaboration portals, though), they say. Hopefully, they be succeed – HTML compliance along with poor developer experience is SharePoint’s weakest points, imho.

@Johan Dewe: Good catch. What MOSS really needs is lots of projects like that. They not only help the developers working (struggling) with MOSS right now, but also send a powerful message to MS: “We need good interface code”.

@Jens Wedin: MOSS has a much wider audience than sweden and the 24webb guidelines, so I don’t think they affect MOSS that much. I might be wrong, but I’m not sure accessibility is that important in all countries…

There is a great improvements of quality of the markup in SharePoint 2010. Although SharePoint 2010 doesn’t solve all web standards and accessibility related issues, it makes delivering accessible solutions easier than it was in MOSS 2007.

SharePoint 2010 has in fact made some progress in this direction but it is far from pretty. It has also introduced some new ‘curiosities’ such as the span tags that seem to have gotten lost. See my blog about that one. I can’t wait for SharePoint to run on the MVC engine, hopefully vNext.