Hey Microsoft, Get Your BLEEPING Markup Out Of My SharePoint

By now. we all are familiar with the justifications for the new SharePoint App Model. Chris Johnson recently wrote a nice piece on the history of the Sandbox Solution model, and why he sees the App Model as the better way to isolate code moving forward. Talk to anyone in the product group or any of the SharePoint field engineers or support professionals in Microsoft, and they’ll tell you that custom code in SharePoint has been the number one cause of upgrade problems, support incidents, and performance issues. Speaking to the general disdain for shoddy SharePoint consultants and their poorly tested customizations, I’ve even heard on more than one occasion from people at Microsoft the off-the-cuff remark:

Get your BLEEPING code out of my SharePoint.

I get the feelings here. It’s a quality issue. Microsoft can’t guarantee the quality of their platform as long as other people can introduce arbitrary code into their system.

Regarding quality though, if I delivered a custom-built web application to a customer and the markup looked like some of the things I find in SharePoint, I’d get called to the carpet.

After some recent updates to SharePoint Online that have wreaked havoc on our SharePoint branding customizations, I’m going to have to call a duck a duck. No, I’m not talking about Peyton Manning’s wobbling throws (#GoHawks!), I’m talking about the quality (or lack thereof) of the html, markup, and front-end code of SharePoint. If Microsoft so badly wants to get my code out of their platform, I’m going to say that I equally would like them to get their UI out of my SharePoint. Just give me the data, and I’ll make the UI, thank-you-very-much. Complete separation of church and state, and presentation and data is what I want.

In this post I’ll take a look at some of the eggs laid and why I feel Microsoft should get out of the business of writing markup, and focus on the data instead.

Motivation for Writing This

After working on the branding for our intranet, a recent unannounced change to Office365 SharePoint Online markup caused us to scramble to fix our branding efforts. Here is the older markup from one of our development tenants, for the “Sites” link in the SuiteBar:

As is typically done in SharePoint branding projects, we had CSS targeting these various class names to style them. Then one day, the markup changed to this:

As you can see, the whole structure of the markup changed, including the class names and prefixes. This is on the heels of Microsoft changing the title attribute for list required fields, that many developers have been leveraging for some time.

It’s clear by these changes that Microsoft does not want us in their markup, enhancing or building upon their UI. They want us to write client app parts or full screen experiences, and leave the SharePoint UI alone. But if that’s the case, let’s take a look at some examples of a Microsoft-generated UI, and I think you’ll agree that the SharePoint development community could do a lot better.

Standards and Semantics, Anyone?

While most of the web development world has been working for years to deliver high-quality, standards-compliant and semantic markup, a look through the SharePoint product shows this wasn’t a priority for them. You’ll find numerous instances of non-standard html tags or attributes. Yes, looking at you <ie:menu>:

Semantic and clean javascript menus based on list items or definitions (<li>, <dd>) have been around for almost a decade, and we are still seeing these examples in the product.

How about standard HTML attributes? Knockout.js has been around since 2010, and a prime example of using the HTML5 data- attributes as extensibility points. But we still see Microsoft using its own ad-hoc attributes:

Reinventing the Wheel / Working in a Vacuum

Modular javascript loading patterns have been discussed since CommonJS started in 2009. However we still have a roll-your-own implementation of async loading:

Yuck.

Ever tried to use a library like Require.js with SharePoint to take advantage of modular loading, CDNs, and local fallbacks? Good luck getting that to play with SharePoint scripts and avoiding race conditions. Chain your jquery(document.ready) to your SP.SOD.ExecuteFunc() to your CSOM executeQueryAsync callback with your shim config, and your head will explode.

How about font icons? Pretty standard way to make icons that can be styled exclusively via CSS. Perfect for use in a theming mechanism. In SharePoint? Another roll-your-own implementation that dynamically creates images on the server side:

It hurts to think about the development effort spent to create a mechanism to generate dynamic images based on colors specified in a SharePoint theme, while major pieces like responsive design have gone completely untouched in the product.

How about the abomination that is the Minimal Download Strategy? This is the first thing I turn off when developing a SharePoint branding solution. Problems with caching, urls, browser location history, and OOB functionality. The MDS just does not play well with other commonly used frameworks and implementations. Haven’t other examples of writing Single Page Applications been around to model after?

While we’ve all been working with jQuery as a defacto standard library for years, we still can’t use the $ prefix for jQuery code in our SharePoint solutions. How about leveraging the typical DOM ready approach ($( document ).ready(function() {});)? Nope, SharePoint has this thing called _spBodyOnLoadFunctionNames instead:

Quality Code

Plenty of examples exist where just plain poor development practices are used. Polluting the global javascript namespace, overriding native javascript object prototypes, code bloat. Take this markup for the Focus on Content button:

A number of things stand out with this. Inline CSS styles, inline javascript event handlers. If I delivered javascript code to a client that looked like this.firstChild.firstChild.firstChild.style.top, I’d get skewered during a code review. Besides the code quality issues here there are the larger UX implications of even having this button on the suite bar to begin with. Has anyone actually used the Focus On Content button? I would love to know how much effort went into building that piece, as it has presented very little value to any of our customers. And is there any easy way to turn it off? Of course not.

Summary

When I look at great platforms like WordPress, with a thriving ecosystem of Themes and Plugins that can completely change the look and feel, and with developer hooks for virtually every piece of functionality, I wonder when, if ever, SharePoint will get to a similar level of maturity in its separation of presentation and data. And you certainly don’t hear WordPress telling it’s developers to “get your PHP out of our platform”. Quite the contrary.

10 comments on “Hey Microsoft, Get Your BLEEPING Markup Out Of My SharePoint
  1. This is exactly why we all moaned (and some groaned) when Microsoft effectively killed SharePoint Designer as a design tool and said “you can use any design program to make SharePoint do what you want.” Unbelievable.

  2. Daniel,

    One of the things that has been the most painful for me with the loss of design view in SPD is the ability to easily add and adjust web parts. I have run into this issue several times in the past few months, and it can be very painful working without this ability. Additionally, it was the only design tool that understood how to work with Web Parts!

    This doesn’t include the loss of easy design capabilities with the DVWP/LVWP. I am thankful that I took time to really learn XSLT, but I’m now finding that I’m turning to JavaScript more for this capability — but it simply isn’t as productive.

    Power Users now have no ability to make these modifications now — we’re back to depending on the developers — seems like a step backwards from what has made SharePoint so popular.

  3. Adam, I think you’ve summed up several conversations that I’ve had over the years concerning the markup in SharePoint. Thank you for taking the time to write this.

  4. This is a good roundup of some of the difficulties front end developers are having with SharePoint. However, comparing SharePoint to WordPress or knockout is like comparing a plane to a car or a bike. You have to realize that it works at a different scale and is of course more difficult to maneuver.

    As for making jQuery a de facto standard, this was your mistake 🙂 , don’t blame Microsoft fot that.

    • Hi Christophe,

      Understood that SharePoint is a different animal from those platforms, but I feel that the SharePoint product team is typically 2-3 years behind the general web development community, and it feels like it is unnecessarily so. The comparisons I feel are still valid.

      JavaScript templating engines have been around for several years, yet you don’t see SharePoint taking advantage of the most common ones that we all use, and instead curiously write their own framework for it instead. Wouldn’t you rather write a display template for search results using handlebar or knockout style templates instead of the strange syntax we’ve been given?

      <!–#_
      if(!linkURL.isEmpty)
      {
      _#–>
      <a class=”cbs-pictureImgLink” href=”_#= linkURL =#_” title=”_#= $htmlEncode(line1.defaultValueRenderer(line1)) =#_” id=”_#= pictureLinkId =#_”>
      <!–#_
      }
      _#–>

      It seems other groups within Microsoft have adopted jQuery as a standard library. It’s a default library in MVC and WebForms project templates now. It’s also by default included in new templates for SharePoint-hosted apps. It makes no sense to me that Microsoft didn’t take a stand, decide to use jQuery as a foundational piece throughout 2013, and eliminate their other usage of the $ symbol in the Calendaring functionality (it’s been a known incompatibility with jQuery since 2010).

      Instead of Microsoft forcing me to use their rendering of the Suite Bar, I’d rather them give me the links for the Suite Bar in a JSON object (how about _spPageContextInfo.suiteBarLinks?), that I could then bind to my own knockout HTML template and choose to render that top bar in my own way.

      The comparison to WordPress highlights a philosophical difference between the two platforms. Are developers given the hooks they need to create their own renderings of the platform? Or are custom renderings frowned upon?

      I’m afraid with SharePoint Online, it’s going the way of the Yammer model, controlling the UI completely, putting click-tracking and analytics on everything, and pushing UI changes based on data analysis. And based on the track record we’ve seen, that UI will be 2-3 years behind the times.

  5. Pingback: Regex Selector for jQuery by James Padolsey FTW | Marc D Anderson's Blog

  6. Pingback: SharePoint, Office365 & Yammer Nuggets of week 6 - Ragnar Heil: SharePoint Nuggets - Site Home - MSDN Blogs

  7. Do you think it may be beneficial to have consistent ways to implement common customizations? It would be in the greater SharePoint communities interest to handle “changes/fixes” to some of the common changes.

    For example, what is the best way to replace the Office 365 logo? Javascript? CSS? Having a consistent implementation methodology may make it easier to reduce introducing further quality challenges.

    Just a thought…

Comments are closed.