This book is a work in progress. Please be patient while I whip it into shape. Also, please feel free to contribute to its development. If you found this book helpful in your quest for Eternal Sharepoint Dominance™, I'd be enthralled if you felt inclined to donate a few bucks.

The Nine Circles of Hell:

Front-End Development for Sharepoint

a quick-start guide
by J. Ky Marsh
jkymarsh.com

Copyright and Acknowledgments
The Nine Circles of Hell: Front-End Development for Sharepoint
a quick-start guide
by J. Ky Marsh, Copyright © 2012
jkymarsh.com
Special thanks to the following parties:
  • The Avanade crew: Platini, Huy, Joe, Jesse, Jeff, Hoang, Ashraf, and Fehmina, for tolerating my endless slew of obnoxious questions and unbridled fury throughout the development cycle
  • The Manifest Digital crew: Ryan, Peter, Clair, Jorin, Jeremy, Rob, and Chris, for the constant support and answers to my onslaught of questions
  • My generous, selfless technical editors: Justin Kobel, Michael Donovan, and Tom Sears

Personal thanks to Derek Wheelden and Neal Conrad for always being wonderful people to bounce ideas off when my brain is simply too exhausted to continue.


Disclaimers and Other Nonsense

This publication is intended as a useful quick-start guide for front-end developers delving into the realm of Sharepoint development. As such, a few assumptions will be made about you throughout the book:

  1. You’re a front-end developer (I know, I know) with a moderate to advanced level of understanding and experience with HTML, CSS, and JS, as well as common web toolkits/frameworks and technologies (text editors/IDEs, jQuery, AJAX, web servers; you get the drift)
  2. You’re at least somewhat familiar with the Microsoft stack, including Windows, IIS, .NET, and the Visual Studio IDE
  3. You have immediate access to a back-end .NET developer friend, acquaintance, or coworker who may be able to answer your myriad of stupid questions
  4. You have a formidable anger management problem
  5. You’re alright with the author of this book being rather foul-mouthed and temperamental

If any of these assumptions are falsy in nature with regards to your person, you may consider putting this book down and attempting to remedy them. “But how?” you ask. I don’t fucking know. I’m just the author, okay?

Otherwise, I hope you find this guide useful as it assists you along the path to Total Sharepoint Enlightenment™.

As one could reasonably assume, though the information contained herein should be largely accurate and trustworthy, it is by no means comprehensive, and various aspects of front-end development for Sharepoint could very well be omitted. If you do happen to stumble across any information in this book that you feel should be corrected post-haste, please don’t hesitate to email me:

I will thusly research the correction in question, and assuming it passes my rigorous, time-tested set of qualifications (read: “me lazily Googling for a few minutes”), I will amend this book and credit you somewhere in kind. Thanks in advance.


Table of Contents
  1. First Circle: Limbo
    1. Introduction
  2. Third Circle: Gluttony
    1. What is Sharepoint?
    2. Technical Details
    3. Glossary
    4. Front-end Structure
    5. Back-end Structure
  3. Fifth Circle: Anger
    1. Front-end Issues: Filesystem/Summation
    2. Front-end Issues: HTML
    3. Front-end Issues: CSS
    4. Front-end Issues: JS
  4. Sixth Circle: Heresy
    1. Front-end Tips & Tricks: Filesystem/Summation
    2. Front-end Tips & Tricks: HTML
    3. Front-end Tips & Tricks: CSS
    4. Front-end Tips & Tricks: JS
  5. Seventh Circle: Violence
  6. About the Author

First Circle

Limbo

back to top
Introduction

My condolences.

If you’re reading this book, it can logically be assumed that you’ve been tasked with completing a project that involves working with Sharepoint; in fact, it’s probably safe to make the assumption that you’re a front-end developer who stumbled upon this text after hysterically Googling “MICROSOFT SHAREPOINT SOME1 PLS HELP,” tears streaming down your pudgy cheeks, fat fists wildly bashing the keyboard of your MacBook Pro.

All is not lost, my friend. I found myself in exactly the same position some time ago; well, aside from the crying, anyway. What are you, some kind of wuss? Christ.

The fact of the matter is that up-to-date, clear-cut information on front-end development for Sharepoint is frighteningly difficult to find. Sharepoint itself is chock-full of bad practices and front-end code taboos that will leave you scratching your head (and potentially crying, since you’ve apparently shown a propensity for doing that, Nancy).

Furthermore, Sharepoint’s default front-end code (that is, the HTML, CSS, and JS that are used by default within a fresh install of Sharepoint) is so horrific that you’ll likely begin immediately assessing how to rewrite or overhaul the existing code in a desperate attempt to bring it in line with modern web development standards.

Don’t panic. I’m here to help.

This quick-start guide was written to assist you, the mid- to senior-level front-end developer, better understand how Sharepoint is constructed, what its weak points are, and how to develop for it more intelligently and more quickly. We’ll also walk through common vocabulary used during Sharepoint development. Hell, I’ll even be so kind as to give you a whole truckload of tips and tricks for developing in a more agile manner, and with considerably less mind-numbing agony.

I’m a really, really nice guy.

First things first, let’s have a short Q-and-A session to clear a few things up:

What version(s) of Sharepoint does this book cover?
Sharepoint 2010. Certain sections may also apply to previous versions, but this is merely coincidence; this book was written as a direct result of working on an extensive Sharepoint 2010 project.
Why Dante’s Inferno?
Because Sharepoint, and Sharepoint development, are the closest approximations to Hell that we’ve yet achieved as humans.
Why aren’t all nine circles of Hell represented?
I couldn’t be bothered to write that many chapters. Trust me, after a few dozen pages of my babbling, you’ll be thankful.
Why don’t you capitalize “SharePoint” or “JavaScript” properly?
I can just barely summon the willpower to use punctuation. As such, I limit myself to one capital letter per word. This does not include acronyms. Also, shut up.
Do the certain circles of hell correspond to particular aspects of Sharepoint development in some meaningful manner?
What are you, some sort of literary critic? Door’s that way, egghead.
Who did the artwork for this book?
TODO

Third Circle

Gluttony

back to top
What is Sharepoint?

This question stands alongside many of life’s most fundamental questions: what makes the sky blue? Where do babies come from? What is love? The answer to all of these questions is “Sharepoint.” Look, I’m not a scientist. I couldn’t possibly be, anyway; I’m here attempting to assist you, while those motherfuckers lyin’ and gettin’ you pissed.

Sharepoint is a web application platform developed by Microsoft.1 Though you’ll find a wide array of explanations as to what Sharepoint is, it could most accurately be described as “a terrifying, monolithic CMS on crack.” It’s most often used as an intranet site for businesses of all shapes and sizes, offering a range of features:

  • Document management and collaboration
  • Company- or group-wide wiki pages
  • Large content libraries
  • Sub-sites and communities within an organization
  • Extensive built-in search functionality
  • Individual personal profile pages and social networking capabilities

Microsoft’s tagline for Sharepoint is “Microsoft SharePoint 2010 makes it easier for people to work together.”2 Conversely, my personal tagline for Sharepoint is the soothing sound of me violently smashing my laptop with a cinder block while my head rotates three-hundred-and-sixty degrees and blood spouts from my eyes. I don’t think I’ll be getting hired by Microsoft’s marketing department any time soon, and I should probably see a doctor.

Though a Sharepoint site or application can be used as either an internet or intranet site, it’s most common for businesses to use it as an intranet portal, allowing employees to communicate with one another and collaborate on documents and wiki pages. It’s not as useful when used as an internet site, due to many of its features being geared towards document sharing and collaboration.

If you’re familiar with web development using any other CMS or collaborative web application platform, such as Wordpress, Drupal, Umbraco, DotNetNuke, Magento, and so on, you’ll be able to grasp Sharepoint conceptually without too much difficulty. However, given its sheer size and complexity, Sharepoint poses a rather interesting set of problems and barriers when it comes to both development and use.

  1. 1. http://en.wikipedia.org/wiki/Microsoft_SharePoint back to article ↑
  2. 2. http://sharepoint.microsoft.com/en-us/product/capabilities/Pages/default.aspx back to article ↑
Technical Details

As mentioned, Sharepoint is a web application platform developed by Microsoft. As one could reasonably presume, this means that Sharepoint runs on the Microsoft stack; that is, the tech stack comprised of the following components:

  • Microsoft Windows Server 2008 (64-bit)
  • ASP.NET (3.5, to be exact)
  • IIS (7.0 or greater)
  • Microsoft SQL Server 2008

Older versions of some parts of this stack may also be supported, as well as SQL Server Express, but the above list tends to be the most common configuration.

Additionally, browser support tends to be a little spotty. Corporations tend to be the most common adopters of Sharepoint, and as many of these organizations explicitly utilize Windows machines, it can be assumed that Internet Explorer will generally be the most common browser used to access the Sharepoint site. As far as browser support goes:3

  • Internet Explorer 7 and 8 are fully supported (sans caveats to be mentioned later)
  • Internet Explorer 6 is not supported
  • Internet Explorer 9 must be used in compatibility mode
  • Firefox, Chrome, and Safari are all currently supported

As a general rule, your site must look great and function perfectly in IE7/8. Companies often approve Sharepoint projects with the assumption that all of their employees will access the site using IE, and as such, modern browsers take a backseat to IE as far as prioritizing a finished, polished site goes. Given appropriate time, support for modern browsers should of course be a priority as well, but IE support should top the list. Additionally, should you require troubleshooting by Microsoft themselves for any reason (in particular, if you’re using Sharepoint Online), they’ll expect you to be using IE throughout the troubleshooting process. It’s a necessary evil.

Sharepoint is available in three separate versions: Sharepoint Foundation, Sharepoint Standard, and Sharepoint Enterprise. In true Microsoft fashion, each successive version provides more capability than the last, adding new features and additional integration with other Microsoft products. Sharepoint Foundation is free, while both Standard and Enterprise possess the ability to make your wallet shriek in terror.

A Sharepoint site or application is comprised of a handful of components:4

Lists,
which are collections of pieces of information. These could be lists of web links, news articles, users, or anything else you might logically find in a database or datastore
Libraries,
which are similar to lists in nature, but can also contain files that can be opened directly in Windows or Microsoft Office applications
Web parts,
which are UI widgets that can be added to and removed from pages
Pages,
which can take the form of wiki pages, publishing pages, or web part pages
Sites,
which are collections of pages, lists, and/or libraries
Search sites,
which are sites that allow access to Sharepoint’s search engine in order to find content or users

A typical Sharepoint application may contain many sites and/or search sites, which may in turn contain many sub-sites. It can all become quite a behemoth, as you can likely imagine. Add to this the fact that users of the Sharepoint application may be able to create their own sub-sites, and you begin to see just how enormous the sheer scope of a Sharepoint application could become, especially for a larger corporation with thousands of employees.

In general, a single Sharepoint site (of which there could be many within the whole application, remember) is composited in the following manner:

List/Library > Web Part > Page > Site/Sub-site

That is, a list/library full of data is fed into a web part, which displays that data on a page, which is a portion of an overall site or sub-site. Phew!

If you’ll recall, I mentioned that Sharepoint does bear some similarities to other CMSes you might be familiar with; for example, you’ve probably grasped that this flow of information is pretty similar to the way a CMS like Wordpress would display data via a widget that you’ve placed on the page. If it weren’t for Microsoft having some insatiable urge to give things convoluted names like “web part” and “list/library” instead of “widget” and “database/datastore,” you probably would have grasped that even more quickly. Thanks for nothing, Microsoft. Unfortunately, you’ll find that’s a recurring trend within Sharepoint; Microsoft loves to rename things that are already commonly-understood within the web development community. Don’t worry, there’s a glossary coming up to address just that.

Okay, okay, so they’re not ALWAYS totally in the wrong. Technically, lists and libraries don’t have the same capabilities as databases, despite their contents being stored via SQL Server. Their capabilities and differences are a bit outside the scope of this book, but if you’re interested, you can find more information here:

In an extremely general sense, that’s a brief overview of Sharepoint and how a Sharepoint application or intranet site would be constructed. We’ll expand more upon the organization of both the front- and back-ends shortly, but if you’re looking for an in-depth technical overview of how Sharepoint interfaces with IIS and/or SQL Server, you may want to do some outside research at this point.

  1. 3. http://en.wikipedia.org/wiki/Microsoft_SharePoint#Supported_web_browsers back to article ↑
  2. 4. http://en.wikipedia.org/wiki/Microsoft_SharePoint#Core_platform_functionality back to article ↑
Glossary

Deep in the bowels of hellfire and desperation that comprise Sharepoint, things are not always what they seem. Terminology that was once wholly familiar to you in an average web development environment may have a completely different meaning amongst the Microsoft stack. Even worse, there’s a smattering of new vocabulary that you’ve likely never heard before, especially if you’re coming from a background in another tech stack. Understanding the lingo of Sharepoint development is a huge part of being able to communicate with the back-end devs, so let’s take a look at a list of some of the terms you might come across.

It should be noted that this is only a partial list of Sharepoint terms; realistically, there are dozens, or even hundreds, of unfamiliar terms you might hear when working on a Sharepoint project. In my experience, these are some of the most common terms used on an everyday basis. For a more complete selection of Sharepoint terminology, I highly recommend scouring the following resources:

.NET
A software framework that runs on Windows. .NET applications utilize the Common Language Runtime virtual machine. A variety of programming languages may be used with the .NET framework, but C# tends to be the most common.
AJAX
In the context of Sharepoint, developers who refer to “AJAX” are likely referring to ASP.NET AJAX, a .NET library built to allow .NET developers to more easily integrate asynchronous calls into their web applications. Often, when you explain to .NET developers that “AJAX” simply describes a technique for building asynchronous web applications, they’ll look at you weird, only having been exposed to the .NET library. Resist your urge to punch them and call them mean names.
Application Pool
A grouping of one or more web applications served by an IIS worker process.
Build
The process of preparing an application for deployment. Unlike simply compiling, building will also copy necessary files, run unit tests (for Sharepoint? As if!), and other intermediary steps prior to deployment. TODO: PIC
CAF/MSOCAF
Microsoft Sharepoint Online Code Analysis Framework. As you could probably infer, this is a tool used to analyze your code and assess how hard it sucks. Code analysis via the CAF tool is required for all Sharepoint sites intended to be deployed to Sharepoint Online.
CAML
Collaborative Application Markup Language. CAML is an XML-based language used to query items stored within lists and libraries.
Central Administration
A website where all Sharepoint sites located on a server or farm can be administered. TODO: PIC
Deploy
The necessary set of steps required to install your Sharepoint application on a suitable Sharepoint host environment. This is typically the follow-up step after building your solution. TODO: PIC
Farm
A server farm; one or more Sharepoint server(s), combined with one or more SQL Server(s) coming together to serve one Sharepoint solution.
Features
A package or collection of Sharepoint services that can be activated or deactivated. The features possessed by your Sharepoint site will typically vary from project to project and team to team.
Ghosted/Ghostable
An item or document is said to be “ghosted” when its content is stored in a location other than a content database. The location of this item will typically be resolved by IIS at runtime.
Hive
As one of my former projectmates so eloquently put it, the “hive” is where Sharepoint “stores its stuff.” These are the physical files and directories required for Sharepoint to function properly. The location of the hive is deep within the Windows filesystem, and we’ll be exploring it ad nauseam in an upcoming chapter. TODO: PIC
IIS
Internet Information Services. IIS is the monolithic web server used for .NET applications.
Library
A location on a Sharepoint site where users can create and collaborate on files with other team members. There are a handful of types of different libraries, none of which are interesting enough to cover in-depth here. You get the concept.
List
A customizable container that stores list items comprised of one or more fields.
Master Page
Web page templates that other pages can inherit from. Same concept as a page that contains “includes” in PHP, or “partials” in Ruby. A master page will generally contain your site’s header, footer, navigation, and placeholders for individual page content.
Metadata
Data about data. The “Inception” of data. Whatever.
OOTB
“Out of the Box.” A term or acronym used to describe default, vanilla Sharepoint web parts or widgets. If a web part requires customization, it’s no longer an “out of the box” web part, but rather, a “custom web part.”
Office 365
A Microsoft-hosted, cloud-computing variant of the Microsoft Office suite of applications. Sharepoint applications often provide integration with Office 365 web applications for document creation and editing.
Page
Either a rendered page consisting of front-end code, or a single page within a Sharepoint application. You figure it out.
Page Layout
A dynamic web template. Page layouts are most commonly used in conjunction with master pages, to provide space on a page to place content, such as web parts or other widgets.
Provisioning
The act of creating and/or deploying a site, application, or feature.
Ribbon
A universal UI command interface, much like the “ribbon” interface showcased in modern versions of Microsoft Office software. The Sharepoint ribbon displays context-appropriate commands to the user, and can be heavily restyled to match the branding of a Sharepoint site. TODO: PIC
Sharepoint Designer
An HTML editor and visual tool used for creating and modifying Sharepoint pages and page layouts. It is awful. Imagine Dreamweaver for Sharepoint. Unfortunately, it does provide some useful tools for modifying Sharepoint files and directories, so you’ll likely be forced to use it on occasion. Otherwise, I recommend avoiding it.
Sharepoint Online
Microsoft-hosted Sharepoint offerings. Sharepoint can either be self-hosted independently, or hosted by Microsoft as part of Sharepoint Online. When deployed to Sharepoint Online, vigorous code analyses and performance tests are undergone to ensure your application meets certain Microsoft standards.
Site
This could refer to either a single sub-site within a Sharepoint solution, or a Sharepoint site; that is, a website you navigate to by typing in a specific URL.
Site Actions
A portion of the ribbon interface that exposes a variety of administrative functions to the user or administrator. TODO: PIC
Site Collection
A set of websites that are in the same content database, have the same owner, and share administrative settings. A Sharepoint application may contain many site collections.
Solution
A structure for organizing projects in Visual Studio, the IDE of choice for Sharepoint development. A solution maintains information about the state of a project.
Style Library
A document library where front-end assets (CSS, JS, images) are stored. The style library is only accessible via the top-level site collection site. The style library effectively acts as a database in which all of your front-end assets are stored.
TFS
Team Foundation Server, Microsoft’s source control system. TFS acts as a centralized version control system, rather than decentralized. TFS also offers project tracking and management capabilities, but we don’t care about those at all.
Taxonomy
Taxonomy defines how Sharepoint’s information is defined, searched, found, and reported.
Timer Job
A recurring background process that’s managed by Sharepoint. This would alternatively be known as a “cron job” to any normal human being. These are processes that are scheduled to run at predefined intervals.
Web Part
A reusable component that contains or generates any variety of code or data. Web parts are similar in nature and appearance to “widgets” in many other frameworks and CMSes.
Web Part Zone
A section of a Sharepoint page layout that may be used to contain one or more web parts by dropping them into the zone. The zone itself controls the organization of the web parts it contains.
Workflow
The automation of a process, such as moving items or documents through a sequence of actions or tasks.

Again, this is by no means a comprehensive list of all Sharepoint terminology you may encounter on any given project. Instead, this is a “crash course-”esque look at a slew of terms you may run into, due to their sheer pervasiveness across many different types of Sharepoint projects. Hopefully this list has cleared up some confusion for you, and will reduce the number of blank stares you give back-end developers when they toss around terms like “hive” and “provisioning.”

Front-end Structure

Structurally, Sharepoint is probably fairly similar to other CMSes you’ve used in the past: content is drawn from some sort of database and fed to the front-end, and may be displayed with widgets, page sections, or other page elements. In Sharepoint’s case, the content will be coming from a list or library, and will generally be presented via a web part.

User-facing pages may also consist of wiki pages or publishing pages, which may or may not contain web parts and web part zones. These pages could be used to display content such as news articles, user profiles, wiki articles (duh), and so on.

Additionally, all system and administrative pages will pass through your front-end as well. Sharepoint’s dizzying array of system pages can make use of your master page(s), meaning you’re able to brand the back-end of your Sharepoint site in addition to the user-facing front-end, if you’re some kind of masochist.

Sharepoint is based on the ASP.NET Web Forms programming model. This means that the pages that comprise the front-end of a Sharepoint site are created using an amalgamation of HTML, server controls, and server code. When users request a page, the server controls and code are compiled and executed, producing a page full of hideous rendered HTML.5 If you’re familiar with .NET web development, Sharepoint’s development model will be familiar to you, if you have any experience using the Web Forms model.

Unfortunately, the Web Forms programming model is considered outdated these days, and has been superceded by a programming model known as ASP.NET MVC. The Web Forms model was highly criticized for producing ugly spaghetti code, which was a result of server controls and code being directly intermingled with HTML on front-end pages. Think back into the distant past, when you wrote HTML forms by writing PHP directly in .php page files, tossing PHP code into HTML tag attributes without a care. Remember how horrible that was? Yeah, Sharepoint still uses that programming model.

As of the time of this book’s writing, Sharepoint still does not utilize an MVC programming model, and Microsoft has no imminent plans to convert it as such. There are workarounds to be able to use the wonderful Razor view engine in tandem with Sharepoint, as well as what’s referred to as an “MVP” (Model View Presenter) programming model, but you’re on your own with those things. Happy Googling.

What does Sharepoint’s old-school programming model and structure mean for you, my valiant front-end developer? Well, primarily that your HTML files are going to exhibit a few key traits:

  • They’ll be riddled with server code, such as:
    <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
  • They’ll be riddled with Sharepoint controls, such as:
    <SharePoint:CssRegistration Name="/Style Library/SomeSite/css/960.css" runat="server" After="corev4.css"/>
  • They’ll be riddled with ASP.NET controls, such as:
    <asp:ContentPlaceHolder id="PlaceHolderBodyAreaClass" runat="server" />
  • They may contain inline CSS
  • They may contain inline JS

Yeah, it’s not a particularly pretty situation. The fact that Sharepoint’s default master page, v4.master, is over 600 lines long is a pretty decent indicator that the code bloat’s attending this party in full force. Additionally, Sharepoint’s default CSS file, corev4.css, clocks in at a monolithic 7400 lines of code. It’s probably best that you not even look at these files yourself right now; save the trauma for later.

We’ll get into the good, bad, and ugly of Sharepoint’s front-end in upcoming chapters, but for now, that’s a pretty decent rundown of what you’ll be looking at on an average Sharepoint project. Lots of code. A whole shitload of code. Most of it terrifying.

  1. 5. http://www.asp.net/web-forms/what-is-web-forms back to article ↑
Back-end Structure

“Yeah, yeah, whatever!” you shout obnoxiously, rudely interrupting my poignant critique of Sharepoint’s front-end. “But what about the back-end?!” Well, you’re sort of out of luck there. Admittedly, I don’t know much about how Sharepoint’s back-end actually functions.

Luckily, Stack Overflow is here to help. After a concise search query, here are some of my personal favorite user-submitted results after asking “How does Sharepoint work?”

  • “Occasionally.”
  • “On Error Resume Next.”
  • “Sharepoint itself is written in a unique syntax, made entirely from ‘Unexpected Error’ exceptions.”
  • “Automagically.”

Jokes aside, the “Technical Details” portion of this chapter was probably the most elaborate rundown of Sharepoint’s back-end that you’ll find within this book. Assuming you have a knowledgeable .NET developer on your team, they likely have a more in-depth understanding of how Sharepoint actually operates. Probe them.

...Not literally, you deviant.


Fifth Circle

Anger

back to top

Ahh, finally, the meat. This is the moment you’ve been waiting for your entire life. It all comes down to this. Down to the wire. D-Day. You get the point.

In keeping with the theme of this book, you’ll notice this particular chapter is represented by the fifth circle of Hell: Anger. Oh, what an adequate circle it is, as you’ll find out.

This chapter will cover the breadth of infuriating inconsistencies, quirks, and plain-ol’ “dumb shit” that comprise Sharepoint’s front-end. I’ll be covering all of these particular things throughout this chapter, and some remedies to them will be provided in the next chapter. Some have asked, “why wouldn’t you give the problem-and-solution together in the same chapter?” Sure, that may have made more sense layout-wise, but come on, the “circles of Hell” imagery is just too good to pass up. You’ll get over it.

Front-end Issues: Filesystem/Summation
Windows Virtual Machines

This one may or may not apply to you, depending on your team and particular project. Oftentimes, Sharepoint (and .NET in general) developers will all develop using a virtual machine image, rather than local installs of Sharepoint on each developer’s machine. There are a few reasons this is done:

  • Ensure all developers are using identical installs of necessary software
  • Prevents against having to reinstall an entire Windows Server system if a dev’s computer bites the dust; just toss the VM image on a removable drive
  • Easier to troubleshoot a single machine image than numerous devs’ machines if something goes awry

Unfortunately, the downside to using a VM is the fact that the Windows Server install is incredibly resource-intensive: SQL Server will hog memory like a jerk, and Sharepoint’s a hefty beast as well. This means that unless your system is a veritable monster, your VM may CRAWL during development.

I’m defying my own “I’m not giving you any tips or tricks ‘til the next chapter!” rule for this, and only this: Make sure your development machine is up to snuff. At least a dual-core CPU and 8 gigs of RAM. The VM image will likely be at least 50 gigs in size, so a suitable hard drive should be obtained as well. In whatever software you use for virtualization (likely VMWare or Virtualbox), dedicate as many resources as humanly possible to the Windows Server VM. Your machine (and your blood pressure) will thank you.

The Hive

As mentioned way back in the glossary, the “Hive” is the location on a Windows filesystem where Sharepoint “keeps all its stuff.” In the case of Sharepoint 2010, this location is also known as the “14 Hive,” due to Microsoft changing the number associated with this directory for Sharepoint 2010. If you’re familiar with other Microsoft products, including the Office suite, you’re probably used to seeing these strange integers associated with the filesystem structure.

The thing about the Hive is that it’s monolithic. I’m on a fairly average Windows VM, housing a Sharepoint 2010 install running two or three separate Sharepoint sites, and my Hive directory currently contains over 11,000 files, and well over 1,000 subdirectories. Yikes.

The Hive directory can be located at: (TODO: PIC)

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14

As you can imagine, clicking through that tree to locate the Hive can become tiring pretty quickly. Set up a shortcut and toss it on your desktop or on the taskbar. You’ll thank me later.

For a nice rundown as far as what some of these directories and files within the Hive do, have a look at this resource:

As you could likely assume, most of these things aren’t of concern to us, as front-end developers. However, there’s one directory that is: the “template” directory. We’ll discuss why shortly. Otherwise, just browse around a bit and have a vague idea of what types of files the Hive contains. Despite that you’ll likely only use a handful of things within the Hive during a project, understanding what it contains can be invaluable knowledge.

Visual Studio

Once again, if you’re familiar with .NET development, you probably know that most .NET developers prefer Visual Studio as their IDE of choice. There are many fantastic benefits to using VS:

  • Badass code autocompletion
  • Built-in code version control via Team Foundation Server
  • Wide array of extensions and plugins
  • Numerous color schemes and themes to style as you see fit

By all accounts, VS is a pretty solid IDE, especially for .NET development. You’d be hard-pressed to find a more feature-complete piece of software for software development on the Microsoft stack.

Unfortunately, VS can be extremely slow. It’s very heavyweight, eclipsing even Java-based IDEs such as Eclipse in size and resource consumption. Granted, this can be due largely in part to developing on a system with subpar available resources, so this may harken back to the “acquire more CPU/RAM/HD” requirement mentioned moments ago.

Additionally, VS has fairly poor built-in support for front-end languages, especially Javascript. Without using extensions, a default VS install doesn’t even provide things like syntax highlighting or bracket matching for Javascript.

Team Foundation Server

Many Sharepoint projects will utilize TFS for version control. It’s a fairly common VCS for projects built on the Microsoft stack, due largely in part to it being directly integrated into Visual Studio. Like many centralized VCSes, it’s relatively straightforward to use, and if you’re coming from other centralized VCS options, such as Subversion, it will probably be quick to pick up. If you’re coming from a decentralized/distributed VCS, such as Git or Mercurial, even better.

However, given the size and complexity of Sharepoint projects, there will be instances where you run into strange issues when checking in and/or merging code, many of them nonsensical and frustrating. Your problems may be compounded when you pull down code updates and suddenly your solution will no longer build or deploy. Fuck. Don’t worry! All in good time.

Front-end Issues: HTML

This is where things start to get nasty. The code that makes up Sharepoint varies drastically in quality; some adheres to modern web development standards, but most is a veritable mess of decade-old practices, improper semantics, and overly verbose horrors.

The Web Forms Model is Garbage

According to some of my .NET/Microsoft stack-developing comrades, there are actually people out there who really enjoy the Web Forms model. This, to me, is absolutely horrifying.

So, here’s the concept: the .NET stack is, at its core, a framework intended for desktop software development. If you’re coming from a background in desktop software development, you’re used to having control over the ViewState of your application, as well as granular detail over any event that occurs within the application window: button clicks, for example. Originally, .NET did not possess a programming model for the web that paralleled the desktop software development model that already existed, and thus the Web Forms model was born.

In essence, the Web Forms model attempts to turn a web application in the browser-based equivalent of a Windows desktop application. It attempts to force your web application into acting like a stateful application, which is rather contradictory to the way the web naturally functions.

There’s some great elaboration into these concepts contained within this lengthy Stack Overflow thread:

For you, the front-end developer, what “Web Forms” means is a few things:

  1. Each page of the entire application (in this case, a Sharepoint site) will be wrapped in a <form> element
  2. There will be numerous hidden <input> elements with terrifying name and ID attributes, intended to be used for tracking the ViewState of the application
  3. Many DOM elements will contain randomly generated IDs for this same purpose

Take a brief pause here if you need to projectile vomit. I’ll understand.

ASP.NET Controls

As a front-end developer, you’ll largely be dealing with master pages and page layouts on an average Sharepoint project. This means that you’ll spend your time writing HTML, CSS, and JS, as well as fighting structures that already exist within Sharepoint’s included front-end files. Many of these structures will be ASP and Sharepoint controls.

ASP controls are special tags that you’ll find scattered throughout an HTML page. These controls look similar to standard HTML tags, but begin with an "asp:" prefix, and will always possess a "runat='server'" attribute. A fairly standard example would be:

<asp:control_name id="some_id" runat="server" />

These controls are used to render any variety of objects onto a page, from form fields, to calendar date pickers, to content placeholders.

ASP controls are a standard .NET construct, and as such, do not explicitly require a Sharepoint installation to function. However, there are a handful of ASP controls that are often used in conjunction with Sharepoint controls, which are ASP controls’ more problematic cousin.

A comprehensive list of all ASP.NET controls can be located at:

Sharepoint Controls

Much like ASP controls, Sharepoint controls appear as HTML tags and possess both an “id” and “runat” attribute. However, as one could logically assume, Sharepoint controls are used to generate structures used to interact with Sharepoint functionality in some way. As such, Sharepoint controls require a Sharepoint install to function properly, unlike ASP controls.

A comprehensive list of all Sharepoint controls can be located at:

Sharepoint controls get hairy for a variety of reasons:

  • They often come coupled with ASP controls, and it may be unclear what each control does
  • They often come bundled with/within other Sharepoint controls, making it difficult to tell what each control renders
  • Certain controls may or may not be required for Sharepoint to function without vomiting errors at you
  • It may be difficult to tell what the attributes on a Sharepoint control tag mean

They can be one of Sharepoint’s most frustrating things for front-end developers to deal with, particularly if you’re involved with a heavy rebranding/restyling of Sharepoint’s default appearance. We’ll cover them shortly.

1998 is Forever (Web Standards? Never Heard of ‘Em)

Microsoft has made it abundantly clear with Sharepoint 2010 that they give not a single fuck about web standards. Though the HTML, CSS, and JS all reek of outdated practices in a number of areas, the HTML that comprises Sharepoint’s master pages and page layouts is arguably the worst offender.

Allow me to give a brief, undoubtedly incomplete laundry list of some of the issues with Sharepoint’s HTML:

  • Inline Javascript all over the place
  • Unsemantic attribute values, IDs, and classes
  • Inline CSS, located both on individual HTML tags as well as within the heads of pages
  • Reliance on tables for layouts/presentation, especially for web parts and web part zones
  • Nested tables as far as the eye can see
  • Entire pages wrapped in form elements, thanks to the glory of the ASP.NET Web Forms model

As I’m sure you’re beginning to realize, it’s not a pretty sight. Assuming you’ve been practicing modern web development standards for some time now (or, if you’re unfamiliar, just envision the EXACT OPPOSITE of everything on this list), simply close your eyes and roll your memory back to the late nineties. Now you’re getting the picture.

Interface developer Emil Stenström has covered some of these missteps in greater detail on his blog, which I highly encourage you to check out:

Front-end Issues: CSS

The fun doesn’t end there. As you undoubtedly know, being a high-and-mighty front-end developer, HTML is only a portion of what comprises the front-end of any given web project. Unfortunately, though the HTML contained within Sharepoint is bad, the CSS may quite possibly be even worse.

Randomly-Generated IDs

One of the unfortunate side effects of Sharepoint being based on the Web Forms programming model is that IDs on DOM elements are more than simple CSS selectors; they’re used by .NET to render page components and register structures on the page as these components. This means you may have a DIV on your page with an ID, such as:

<div id="MSO_ContentDiv" runat="server">

Which will render dynamically during runtime, ultimately displaying:

<div id=”ctl00_MSO_ContentDiv”>

Again, if you’re familiar with the .NET Web Forms paradigm, you’re probably used to seeing this, so you’re thinking, “so what?” For the rest of you who find this type of nonsense appalling, trust me, you’re not alone.

Sharepoint’s Default CSS is More Lengthy than Atlas Shrugged

The default CSS file that Sharepoint applies to a site off-the-shelf is a file called corev4.css, and is well over 7,000 lines of code in a default Sharepoint 2010 install. Need I say more?

Oh, Yeah, and You HAVE to Use it

You’re probably thinking to yourself, “ha! Why even use corev4.css? I’ll just dump it and write all the CSS from scratch!” I applaud your tenacity, but this is a terrible idea.

Remember when I said Sharepoint was a behemoth? It contains so many UI elements, and the CSS is so convoluted and redundant that it would quite literally take weeks just to reproduce corev4.css in a consistent, reliable manner. As you’ll see when you have a working Sharepoint install up and running, there’s simply too much to reproduce. There are better ways to overcome its failures, which we’ll get at in due time.

On top of that, if you’re deploying to Sharepoint Online, oftentimes Microsoft will disallow you from removing and/or altering default components that come with Sharepoint, and this includes its CSS.

It’s Ugly

The default IDs and classes used in corev4.css are terrible, unsemantic, and convoluted. Here are a few examples:

  • th.ms-gridT1
  • .ms-vb-itmcbx
  • tr.ms-ppanerowalt
  • .ms-rteThemeForeColor-4-5
  • .ms-cui-glass-ff
  • .ms-cui-cg-i

Yup, those are all straight out of corev4.css. It gets worse, too: generally, the further down you scroll within the file, the more disgusted you’ll be.

Presumably the “ms-” prefix on EVERY SINGLE RULE is intended as some sort of namespacing for Sharepoint, though I’m unsure why Microsoft seemed to find that necessary. Personally, I’d much prefer semantic names that dropped the prefix, even at the cost of them being a little more lengthy. Clarity over forced terseness every time, I say.

It’s Redundant

On top of just being straight-up unappealing to look at, corev4.css is incredibly redundant. When inspecting elements in the DOM, you’ll often find that numerous rules are being overwritten on a single element. This is particularly true for links; it’s not uncommon to discover a link on the page or within navigation to which six, eight, or ten different CSS rules are applying, and all but one are consequently overwritten.

Furthermore, Microsoft inconsistently used unnecessary DOM element selectors in combination with CSS IDs and classes, resulting in selectors such as “span.ms-navitem” and “table.ms-toolbar.” Murder me.

Oh, and let’s not forget the age-old classic, the “!important” keyword. In a quick Ctrl+F over corev4.css, I discovered almost 200 uses of it. Be prepared to use it yourself.

Front-end Issues: JS

Of the three aspects of Sharepoint’s front-end, the Javascript is, thankfully, the least painful to deal with. This is largely because, unlike the HTML and CSS, the JS cannot be removed, replaced, or overwritten. This can be both a boon and a curse: from the onset, just know that you’ll have to work around Sharepoint’s internal JS, and that it can’t (easily) be edited. You’ll be better off knowing about this restriction from the very beginning.

It’s Untouchable

Sharepoint’s built-in JS handles a wide variety of client-side tasks, from showing and hiding UI elements, to sending/receiving AJAX-y data, to everything in between. If you attempt to edit or remove any of this code, you’ll be in for a world of hurt. This is particularly true, again, if you intend to deploy to Sharepoint Online; Microsoft will assume that all of Sharepoint’s front-end assets are included with your solution, and if they’re not, this could cause issues with the approval process.

It Clashes with Other JS Libraries

If, like me, you’re used to using a variety of JS libraries and toolkits on an average webdev project, know right now that many of them may clash with Sharepoint’s internal JS. I’ve had issues attempting to use Modernizr, Selectivizr, and a variety of jQuery plugins that wouldn’t otherwise be problematic.

What does this mean for you? Well, first and foremost, plan on not using your ol’ go-to libraries on a Sharepoint project. Secondly, plan on writing a lot of JS from scratch, especially to replace functionality for things that you’d normally incorporate via plugins. Keep in mind, also, that Sharepoint sites are typically intended for use via Internet Explorer, so any JS you write needs to work reliably in IE.

Luckily, Sharepoint is compatible with most of the major JS frameworks, including our old friend jQuery. While some of your usual libraries will toss errors or clash with existing JS within the project, at least we can rely on having access to jQuery.

For a directory of typical front-end extensions and JS libraries and frameworks that tend to be used in .NET projects, make sure to check out NuGet. While they may not all necessarily be compatible with your Sharepoint project, it’s a good place to start to be able to guess at whether or not the tool you’re looking to use is going to cause problems:


Sixth Circle

Heresy

back to top

I can picture you now: you’re sweating profusely, furiously gripping your keyboard, knuckles white from your iron grip. “Why is Microsoft doing this to me?!” you demand to know, spittle forming at the corners of your mouth, temples pounding from the impending migraine. I wish I knew, my friend. I wish I knew.

Alas, this is what we’re stuck with. High-and-mighty, neckbearded Microsoft fanboys all over Stack Overflow have insisted that Sharepoint 2013 will mitigate some of these issues, but let’s be honest: it’s Microsoft. They don’t exactly have a sparkling track record as far as overhauling their technologies in attempts to bring things in line with modern web standards. Here we are, in 2012, and Internet Explorer (9? 10? Both?) is still reamed on the daily for being a slacker in the realm of web browsers, for example. Don’t get me wrong, I’m a Windows fan myself, but one can’t deny this honest truth.

Relax. Take off your shoes, toss your spindly legs up onto your desktop, and pour yourself a refreshing (alcoholic) beverage. Let’s do us some Sharepoint learnin’ and figure out how to improve our working conditions on this project.

Front-end Tips & Tricks: Filesystem/Summation
Windows Virtual Machines

I already defied my own rule on this one, and I feel terrible about it - I gave you one of my wonderful, priceless secrets up front. I don’t know how I sleep at night.

The key here, as mentioned in the previous chapter, is simply to crank up your VM’s resources. More CPU cores, more RAM, more video memory, more more, more more more. More is gooder. Never forget it.

The Hive

This one’s important. Hopefully you took my advice in the previous chapter and set up a taskbar shortcut to the Hive; if not, definitely do that now. Seriously. I’ll fucking wait. In case you’ve forgotten (you fool!), the Hive is located at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14

Within this directory, you’ll find a bunch of subdirectories, but the most important one for you as a front-end developer is the “template” directory. Within this directory, you’ll find even more subdirectories, housing a whole bunch of important Sharepoint stuff, from global master page templates, to ASP and Sharepoint control templates, to static Sharepoint assets (such as images). Browse around a bit. Go wild.

The most important subdirectory within “template” is “layouts,” however. “Layouts” is typically where all Sharepoint sites’ front-ends are stored within the Hive for most projects. If you open “layouts” up, you’ll likely see a subdirectory named after the Sharepoint site you’re working on. If not, ask one of the back-end devs, and they’ll likely know. Additionally, there should be directories for default Sharepoint installs, likely named “1033” and ”1036.” These will contain a whole lot of fun static assets, including all of Sharepoint’s included CSS and JS.

Your particular project’s directory is the key here, though. You see, Sharepoint has two ways of referencing static assets: either via this “layouts” directory, or via the Style Library, which you should remember from way back in earlier chapters. On a deployed Sharepoint site, these assets will reside within the Style Library. However, the Style Library will piss you off instantaneously during development, as it effectively acts as a database for your assets. This is annoying as shit, because it means you have to redeploy your assets every single time you change them.

Yes, you read that correctly. Edit a master page’s HTML? Redeploy the solution. Change some of the project’s CSS? Redeploy. Make some changes to your JS? Redeploy.

Having to redeploy every time will quite possibly drive you to suicide.

The sheer number of man-hours you’ll waste waiting for your solution to build and redeploy will be staggering. Luckily, there’s an awesome, quick fix for this: in your project’s master pages, you’ll probably see references to assets as such:

<SharePoint:CssRegistration Name="/Style Library/[project name]/css/style.css" runat="server" After="corev4.css" />

During development, change these links as such:

<SharePoint:CssRegistration Name="/_layouts/[project name]/css/style.css" runat="server" After="corev4.css" />

By doing this, you’re effectively changing the working location for your assets from the Style Library to the “layouts” folder within the Hive. You can now place your images, CSS, and JS within your project’s directory in the “layouts” directory, and you’ll no longer have to redeploy your solution every time you make changes. Huzzah!

Of course, this is only for development. For deployment and/or testing, you’ll still have to make sure your files are updated and deployed from within the Style Library. It’s effectively the Sharepoint equivalent of developing locally versus developing remotely; locally is, of course, much faster, but you have to make sure your changes are propagated remotely when you’re done.

Now, that’s only good for images, CSS, and JS. When you’re working on master pages or page layouts, there’s no easily-accessible Hive equivalent, as your HTML pages will all likely be located solely within your solution in Visual Studio. This means you’d have to continue the horrific trend of redeploying every time you make changes to any HTML pages.

But wait! There’s a solution for that, too!

CKS, or Community Kit for Sharepoint, is a set of Visual Studio extensions for Sharepoint that make development considerably less painful. You may have to read a little about it to determine which of its features will most benefit you, but personally, it has one feature that I find to be a total lifesaver: “Copy to Sharepoint Root.” This right-click menu option will appear on all files within your solution after installing CKS, including your master pages and page layouts. Now, instead of redeploying after every edit to your HTML pages, simply use “Copy to Sharepoint Root,” and you’ll be able to see your changes instantly upon page refresh. No more “deploy” command needed!

Again, CKS has a variety of other useful features as well, so make sure to do some reading up on it. It’s a real lifesaver.

Visual Studio

All things considered, VS is actually an extremely capable IDE, both for .NET (C#/VB) development, as well as for front-end development. You may find that it’s missing features common to other IDEs and editors, however, such as syntax highlighting, autocompletion, zen coding, or any other number of extensions you might like to use.

It’s worth having a look through the extensions gallery for VS, just to see if there are any extensions that might be of use to you:

Additionally, if you’re using the Hive and/or CKS tweak(s) mentioned above, you can actually continue using your editor of choice, opening the project directory within the Hive in the editor, and doing all your coding outside of VS. However, keep in mind that you’ll have to manually move your code into VS eventually, both for deploying it into the Style Library, as well as for making sure it’s properly tracked in version control via Team Foundation Server.

Team Foundation Server

Being centralized version control, there’s not a whole lot of ambiguity to TFS. It’s fairly straightforward - you’ll do a lot of “Get Latest” and “Check In,” occasionally using “Get Specific Version” or “View History” for more fine-grained control. Make sure to check with your back-end team to make sure you’re aware of any project-specific guidelines for commit messages or code check-in standards.

Front-end Tips & Tricks: HTML
The Web Forms Model is Garbage

Understanding the Web Forms model is half the battle here. Unfortunately, since Sharepoint wasn’t built using MVC architecture, you really have no alternative here, so you best get used to it. Above all else, it’s imperative that you understand that the Web Forms model dictates that you’ll have a number of extra HTML elements in the DOM, and this cannot be helped. Do your best to ignore them. They can smell your fear.

ASP.NET Controls

The vast majority of .NET controls you’ll come across will be Sharepoint controls, which we’ll cover shortly, but ASP controls will crop up fairly frequently as well. One of the more common controls is the ContentPlaceHolder control, which will look as such:

<asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" />

As you could probably have assumed, these controls are used as placeholders where actual content will be dumped upon the page being rendered. While you may use most of these placeholders on an average master page, they’re often not required for the page to render without errors. However, if you do intend to deploy your Sharepoint site to Sharepoint Online, be aware that the code review process expects that ALL possible ContentPlaceHolder controls will reside within each master page, even if some are unused. As such, it’s typical to wrap all of the unused controls in a hidden ASP Panel control at the bottom of each master page:

<asp:Panel visible="false" runat="server"> <asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" /> </asp:Panel>

A list of all ContentPlaceHolder controls can be found here:

Sharepoint Controls

Sharepoint controls are a bit more frustrating, unfortunately.

They’ll be used to render any variety of Sharepoint-specific page elements, from the Ribbon element, to the web parts panel, to the site’s logo container, to the navigation... Yeah, they’re everywhere. After working with the controls themselves, you’ll begin to recognize which control renders which object, and consequently, you’ll be able to look at the design/branding of a Sharepoint site and determine which controls you can modify or eliminate to match the design whilst simultaneously eliminating unnecessary code.

As far as being able to tell which controls (or parts of controls) can be safely removed, sadly, that’s often a matter of trial-and-error. For example, the SPRibbonPeripheralContent control will often contain other controls, such as the SiteActions and FeatureMenuTemplate controls. Some can be removed without incident, while removing others will prevent your page from rendering, as well as throw a vague, frustrating error: (TODO: error screenshot)

The best tactic is simply to use your design as a reference, removing unnecessary controls and ensuring you’re not getting any errors on pageload.

Oh, and while we’re speaking of Sharepoint errors: you’ll often find that edits you’ve made to your front-end code (or even that back-end code changes you’ve pulled in via TFS) cause your Sharepoint site to throw errors for seemingly inexplicable reasons. I highly recommend downloading Sharepoint LogViewer:

It’ll help you clarify exactly where the issue is, so you can then scuttle over to a back-end dev and pathetically beg them to help you “fix it.”

1998 is Forever (Web Standards? Never Heard of ‘Em)

Some issues with Sharepoint’s HTML can be resolved or mitigated, and some, well, can’t. Web Forms code and HTML elements, ASP controls, and Sharepoint controls, of course, are all immutable. Likewise, web parts tend to be “chunks” of code that are not easy to change, unless your back-end devs have decided to create custom web parts.

However, everything else is fair game. As far as your actual master pages and page layouts go, as long as all the “necessary bits” are there, you’re free to go wild with the remaining HTML. Being a front-end developer means you’re probably champing at the bit to convert your Sharepoint pages to modern, standards-compliant HTML5, right? Well you’re in luck! A gentleman by the name of Kyle Schaeffer has created an HTML5-based responsive master page for Sharepoint 2010:

It’s a great first step for updating Sharepoint’s ancient HTML. You may or may not use all of it (I actually tend to forego the CSS and simply use a Sharepoint CSS reset and HTML5 Boilerplate’s CSS, which we’ll cover shortly), but as far as the HTML itself goes, it’s a nice foundation that will make your code much more tolerable, as well as give you the confidence that you’re not missing any essential Web Forms code or ASP/Sharepoint controls. I highly recommend it.

Once again, keep in mind that the majority (or all) of your users will be using IE to access your Sharepoint site, so utilize fallbacks and shims for HTML5 as needed.

Front-end Tips & Tricks: CSS
Randomly-Generated IDs

This is another “hands are tied” situation. IDs on HTML elements within a Sharepoint project are typically used for integration with the .NET back-end, not solely as CSS selectors for styling. Luckily, this does mean that you won’t often find these randomly-generated IDs used within Sharepoint’s corev4.css file, as Microsoft did a fairly decent job of separating the .NET structures from the front-end presentational code.

However, this does also imply something about the way you should be writing your CSS: DON’T rely on these randomly-generated IDs for styling. Just don’t do it. You have no guarantee that their values won’t change, causing all of your styling to disappear at a moment’s notice. A much safer practice is to utilize the “new-ish” CSS paradigm of exclusively using classes for styling, leaving IDs to .NET structures and interactive (JS-integrated) elements.

Sharepoint’s Default CSS is More Lengthy than Atlas Shrugged

You guessed it: can’t help this one either. Just remember that corev4.css is essential to your site functioning and displaying properly, and that you’ll have to either be writing new, unrelated code and styling that, or overwriting corev4.css in order to arrive at your desired end result. Once again: don’t try to remove corev4.css (or any other included CSS) from your solution.

Oh, Yeah, and You HAVE to Use it

Hey, we just covered this! Yeah, no shit, but it’s worth reiterating: don’t try to remove Sharepoint’s included front-end assets. Again, this is particularly prominent if you’re deploying to Sharepoint Online, as Microsoft will expect these assets to be present in their original, unaltered format.

It’s Ugly

You’ll find that the CSS utilized by all default Sharepoint structures tends to be fairly horrific to look at. It’s unsemantic, convoluted, redundant, and often uses outdated tactics, rules, and/or properties to achieve its goals. Clearfixes won’t be utilized. Margin will be used instead of padding. Measurement values will be set in pixels instead of ems or percentages. Woe is me.

Luckily, since you’ll likely be developing a site based on a snazzy, new-school design or branding, you’ll be producing a lot of the site from scratch, including the HTML and CSS. No, you won’t be able to rewrite corev4.css, but you can certainly overwrite its rules with your own.

Producing CSS for brand new page elements won’t be the issue, though; you’ll be able to write proper, standards-compliant, semantic CSS for those elements. The issue will be trying to restyle existing page elements, especially those produced dynamically via Sharepoint or ASP controls. Maybe you need to restyle the Ribbon, or particular web parts, or even system pages.

Some people like to take a precise, surgical approach, targeting individual DOM elements (often nested within others) and overwriting individual rules as necessary. While this will certainly result in less code and will be a bit cleaner, I can say with confidence that this approach will waste a boatload of your time and often frustrate you. Instead, I personally prefer a bit of a shotgun approach. For instance, say I want to reset the margins and padding on all nested elements within the parent Ribbon element:

body #s4-ribbonrow * { margin: 0; padding: 0; }

That’s right: it’s our old friend, the asterisk selector. “No!” you shout, interrupting my poignant and interesting explanation. “The asterisk selector is so slow!” Yes, you’re right, it is. I know that; you know that; we all know that. The thing is that it honestly just makes things a lot faster for you. You’ll frequently find elements buried numerous nodes deep, and will be completely at a loss as to why a rule is (or isn’t) helping you achieve a certain goal. Sometimes, it’s just better to start from a clean slate. Use the asterisk wisely and it can be an extremely helpful tool.

It’s Redundant

In addition to the last bullet point, the asterisk can help deal with some of the redundancy found within corev4.css’s rules. As long as you’re wiping out all of a parent element’s childrens’ properties, it should be easier to arrive at a clean slate, in order to ultimately build the rules back up again yourself.

One important thing to note is that you’ll have to ensure your CSS loads after corev4.css, so that your fresh new rules aren’t prematurely overwritten by corev4. In order to achieve this, make use of the CssRegistration Sharepoint control with one special attribute:

<SharePoint:CssRegistration Name="/Style Library/[project name]/css/style.css" runat="server" After="corev4.css"/>

The “After” attribute will ensure your CSS file gets loaded after corev4.css during page rendering, so it’s imperative that you use it.

Oh, and don’t forget about the “!important” declaration. It can be a lifesaver when you simply can’t seem to properly overwrite existing rules on an element. Use it sparingly, but always remember it’s there for your use.

One last thing: it’s interesting to note that Sharepoint uses a Sharepoint control (CssRegistration) to reference CSS files, but doesn’t use one to load JS files. You can use the standard <script> tag as you’re used to. Odd, eh?

Front-end Tips & Tricks: JS
It’s Untouchable

This is getting repetitive, isn’t it? Once again, just don’t touch it. Don’t try to edit it. Don’t try to remove it. LEAVE SHAREPOINT’S JS ALONE!!!

Even more so than Sharepoint’s CSS, its JS can neither be edited, removed, or overwritten. It’s necessary for the proper function of Sharepoint. If you find that your handwritten JS or any JS libraries you’re using end up causing Sharepoint to throw strange, archaic errors, you can safely assume that something you have included or written is the cause, and will have to be resolved for the site to function properly. Sharepoint’s JS is a black box - things go in, things come out, but you can’t touch it.

It Clashes with Other JS Libraries

As long as you have researched the libraries/toolkits you intend to use and are confident they won’t clash with Sharepoint’s JS, you should be in good shape. Obviously this will likely require some trial-and-error to ensure that, indeed, things aren’t tossing any errors. If they’re not, then the onus is on you to write your necessary JS using these libraries and ensure your code isn’t mucking things up.

If you’re like me, you’re a big fan of tools that allow you to edit your code, save it, and see your changes instantly reflected in the browser, even without a manual page refresh. Mac users will recognize this functionality from apps like Codekit, and LiveReload performs a similar function. Unfortunately, since we’re working in a Windows VM, Codekit isn’t an option, and LiveReload on Windows is shaky at best. However, there is another option that has worked well for me on Sharepoint projects:

Live.js will allow you to make changes to both your CSS and JS and see the changes instantly reflected in your browser. Unfortunately, it’s not as reliable for HTML, as much of our pages are comprised of Sharepoint or ASP controls that get rendered at runtime. Still, two out of three ain’t bad! In my experience, it also works well in conjunction with Sharepoint’s JS, so potential JS errors are a non-issue.

One caveat: remember to remove Live.js (or at least comment it out) before deployment or testing. It can cause funky things to happen with the browser, including non-stop page refreshes, which are obviously pretty undesirable for the end-user.

If Live.js doesn’t work out for you, text editors/IDEs often have extensions for instant reload, if you’ve taken the route of working out of the “layouts” folder and using an external editor aside from Visual Studio. I’m a Sublime Text user myself, and there’s an extension for LiveReload that bypasses the need to install the Windows version of LiveReload:

It’s worth a shot if you’re desperate.


Seventh Circle

Violence

back to top

I bet you feel empowered right now, don’t you? Where you were previously a weak, terrified little kitten, you’re now a strong, hulking behemoth chock-full of useful knowledge about Sharepoint. You’re ready to tackle the frightening task of front-end Sharepoint development with zeal and candor. Nothing will stop you! Nothing will stand in your way!

Ahem. More likely, you’re wrapping up this book in relative apathy, shrugging your shoulders and murmuring, “fuckin’ Microsoft.” I can’t blame you. I said the same thing myself not too long ago, realizing the breadth of the task that lie in front of me.

I sincerely hope this brief book has been able to shed some light on Sharepoint for you in a meaningful, understandable way. Hopefully you now have a solid grasp on what exactly Sharepoint is, as well as what some of its pitfalls are and how to mitigate them to make your task of front-end development on a Sharepoint site as painless as humanly possible.

I encourage you to send me feedback on this book, whether it be corrections or otherwise. I can be reached via email at the following address:

Furthermore, I wrote this book entirely in my free time and out of the good of my heart, so if you found it useful, I’d love if you could find it deep inside you to donate a few bucks, which will likely go towards a frosty lager. I’ll even pretend we’re drinking together, chatting like old pals about our trials and tribulations with front-end development! What fun!

To proceed with said donation or simply to find out more about me and some of my work, please take a gander at:

Thanks for reading, and godspeed.


About the Author

back to top

I’m a front-end developer currently living in windy Chicago, Illinois. I’m passionate about Javascript, web standards, and writing clean, maintainable, well-documented code. Though front-end development is my forte and area of expertise, I also have experience with .NET, PHP, Ruby, and Python.

I graduated from Northern Illinois University in 2009 with a Bachelor’s in Music (wat), with emphases on composition and audio engineering. My first forays into programming began in high school with Python and various web technologies, eventually evolving into C++, Fortran, and MaxMSP/Puredata in college. By the grace of god, I eventually stumbled into the realm of modern web development and it’s been smooth sailing ever since.

I’m also deeply in love with music (metalcore/hardcore, skramz, shoegaze, indie, idm), tattoo culture, video games, and horror books and movies. I consider myself to be an outspoken advocate of atheism and logic, and can often be found ranting about such things on Twitter.

Feel free to check out my website and Github account, as well as spark up a conversation via Twitter or email. I’m frequently looking for new projects and contracts, both local and remote, so you’re encouraged to drop me a line.