The SharePoint JavaScript Environment

Chapter 2

David Mann

by David Mann on 12/21/2015

Share this:

Article Details

Date Revised:

Applies to:
javascript, JavaScript Object Model, Microsoft SharePoint, rest, SharePoint

SharePoint 2013 includes over 400,000 lines of JavaScript code.  That’s a LOT of JavaScript.  Before diving in and writing custom code, it’s worth getting an understanding of what some of this code provides us that we can reuse in our own applications.



In this chapter, we’re going to explore the SharePoint JavaScript environment.  While our goal is to learn how to use JavaScript to customize and extend SharePoint, it makes no sense to implement custom code if SharePoint already gives you that capability.  So first, we’ll explore the out of the box SharePoint JavaScript environment and review some of the functionality SharePoint gives us for free.  We’ll see how we can take advantage of what SharePoint gives us to make our customizations fit in better with the rest of the SharePoint application and any other customizations made before and hopefully after ours.

Working with the out-of-the-box JavaScript

At a high level, SharePoint is just an ASP.NET web application.  Like any other web application, it relies on client-side scripting via JavaScript to deliver a richer, more engaging user experience.  While you may not realize it, SharePoint has an extensive library of JavaScript used to deliver the experience you get out of the box. 

Looking just at the debug JavaScript files in the Layouts directory, there are over 170 files containing over 400,000 lines of code totaling up to over 16 MB of JavaScript.  That’s a LOT of JavaScript.  Some of it is very good, and incredibly useful to us as developers.  Some of it is quirky, old fashioned and not very useful to us when we’re looking to extend our SharePoint implementation.  In a general sense, this breakdown occurs as we progress through SharePoint versions.  Large portions of older JavaScript in files like core.js and init.js are not very useful to us as developers and hard to work with, but then there are parts of those files that are incredibly useful and easy to work with.  Those older files tend not to follow modern JavaScript programming guidelines but that is largely because they were written well before those guidelines were even thought about and have not been substantially updated since.  Newer JavaScript, say things written for 2010 or 2013, are much more modern in their approach – taking   advantage of many of the constructs we talked about in the first chapter.

The trick is figuring out what we can reuse as-is or extend for our own purposes without causing problems.  That’s a large part of what I want to get across in this chapter – how we can use and build upon the base that Microsoft has given us.  It’s important to note that we’re not yet talking about using the JavaScript Object Model introduced in SharePoint 2010 and extended in SharePoint 2013. That will be covered in the next chapter.  Similarly specific abilities to interact with the server or the client UI are covered later in the series.  The variables and functions shown in this chapter are more utilitarian and useful across a broad range of scenarios.

Some of the out of the box JavaScript files are used across many areas of SharePoint and can be considered more utilities than specific functionality.  While this is not entirely true, for example the entire ECB menu (Edit Control Block – the context-sensitive menu for each item shown in a SharePoint View) implementation is intermingled with the utility functions, it is a good place to start.  As Microsoft has progressed with their JavaScript implementation, they have definitely moved away from these larger, general-purpose files towards a model of smaller, more targeted JavaScript libraries.


Figure 1: By default, SharePoint loads five JS libraries

The default SharePoint master page loads five JavaScript libraries, as shown in Figure 1: Core, Menu, Callout, Sharing, and SuiteLinks.  These files are loaded via the ScriptLink control, which we’ll talk about in a later chapter, with its OnDemand property set to true.  This means that while the files will be registered with the page and the functionality in them available, the files themselves will not be downloaded to the client until they are actually needed.  This is important because these five files represent nearly a half a megabyte of content.  Downloading that on initial page load would significantly slow down people’s first experience with SharePoint.  Instead, these files and many others used by SharePoint are downloaded asynchronously, in the background, while the user is getting their first taste of SharePoint.  We’ll talk about this on-demand script downloading and how you can make use of it in your own code later in this series.

Other common JavaScript libraries used across SharePoint include:  init, more utility functions; SP– the main library for the JavaScript Object Model we’ll talk about in chapter 3; plus almost 200 additional files, all downloaded on an as-needed basis.  As you can see, there’s already a lot of JavaScript in SharePoint.

Many of the JavaScript files that ship with SharePoint come in two flavors – production and debug.  Production files have the names you would expect – core.js, menu.js, etc. and are minified to reduce their size.  This means that they have all extraneous white space and comments removed.  This often makes the files considerably smaller, which means that they download to the client faster.  The JavaScript parsers in the browsers do not need the whitespace and comments so there is no sense including them in these files.  We poor humans, though, do need all that stuff if we need to read the JavaScript files.  Therefore, Microsoft also includes an additional version of many of the files – the debug versions.  These have the same base name – core, menu, whatever, but then .debug.js instead of just .js.  So, core.debug.js, menu.debug.js, etc.  These are the files that you want to work with if you need to debug your JavaScript.  We’ll talk about how to make sure you load the correct versions later when we talk about loading libraries.  It’s important to note that not ALL files have a debug version and unfortunately this means that if you need to work with some files, you are going to have to read the production version, with all the whitespace removed.  It isn’t impossible, but it certainly is harder.

Out-of-the-Box Variables

That takes us through the basic stuff we need to know about the out of the box JavaScript environment in SharePoint and how to work with it.  We’ll cover more of it in later chapters as we move through additional details, but now let’s get started looking at some of the elements we get for free.

We’ll start with just two specific variables made available to us – one all the time and the other some, most, of the time.  Each of these variables represents an object that provides a lot of information about the current context in which our code is running.


The first of these object variables is simply ctx or contextFigure 3 shows a view of just some of the properties available on ctx.  It provides a wealth of information about many different aspects of the current page and current environment.  Specifically which members of the context object are populated with values and exactly what those values are depends largely on the page or area of our site which we are visiting. 


Figure 2: The out-of-the-box ctx variable provides a wealth of information

One important thing to know about this context object is that it is, unfortunately, not available everywhere.  I can’t say that I’ve tested it on every single SharePoint page and in every possible situation, but in general it is not available on:

  • form pages - new forms, edit forms, display forms
  • layouts pages - site settings, administration pages, etc.
  • apps - unless you’re inside a list. 

In my testing, it appears to be available everywhere else.

Another important piece of information about this variable is that it is effectively read-only.  You can change the property values, but doing so has no effect.  This makes sense if you think about the purpose of this object, which is just to give us information about our current context, not to allow us to update those values back on the server.  We have other ways to take care of that, which we’ll cover in later chapters.


Some of the more useful properties of the context object include ListData – another object, this time which gives us information about the items shown in the List View Web Part on the current page.  As you would expect, this data is available only when we’re viewing a list. 


Figure 3: Useful properties on ctx include ListData.Row and its children, among others

The useful information from the ListData object is generally available on the Row property, a zero-based collection of items shown in the current View.  For each item shown in the View, that information includes:

  • the value of each column, using the column’s internal name
  • the ContentTypeId
  • the object type (FSObjType of 0 is a list item, 1 is a folder)
  • information about the last person to edit the item
  • the ID of the item in SharePoint

There are a couple of other useful bits as well.  I recommend that you examine this variable the next time you’re exploring a SharePoint site.  I think this is going to be one of those things that we developers find ourselves referring to often. 

There’s a longer example of using ctx.ListData.Row in the source code for the book, but Snippet 1 shows a quick code sample showing how we could access the value from a List Item shown in the View.


Snippet 1: A brief example of using ctx.ListData.Row to access items shown in a View

The outcome of the code in Snippet 1 is shown in Figure 4.


Figure 4: The outcome of the code in Snippet 1

Other useful information about the current List available through the ctx context object includes:

  • Form URLs
  • Title
  • URL
  • GUID
  • List Schema details:
    • whether or not it’s a document library
    • information about the fields shown in the View
    • locale information
    • path to the current view page
  • the HttpRoot of the current web
  • the imagesPath

The last two pieces can be quite useful for constructing URLs to access various aspects of SharePoint.

Again, there are other useful pieces of information and it is highly recommended that you familiarize yourself with ctx.  Making use of the information available here can mean that you have less code to write, test and maintain.

One final thing to know about the ctx variable is that it is a little unpredictable if you have multiple List View Web Parts on a page.  Which one of the list views the list-specific data in ctx refers to depends on many factors – whether the web parts are in a Rich Content area or a web part zone, the order in which they were added to the page, the order they appear on the page, and the configuration of web part zones, for example.  My recommendation is to avoid using the list-specific elements of ctx unless you are sure that there is one and only one list view on the page.  If that is the case, it provides a lot of value, otherwise it is a bit hard to use reliably.

That wraps up the first of our contextual variables.  Remember this object is not available everywhere, and really provides the most value on List View pages. 


The last variable we’re going to take a look at is similar to the last one, even duplicating some information, with the one major difference being that this variable is available everywhere.  Again, I didn’t test every single page in SharePoint, but this one is available on apps, site pages, layouts pages, forms pages, etc. 

So this object, _spPageContextInfo, is available everywhere and provides access to a lot of useful information – information about the current user, site, lists, pages, etc. The full contents of _spPageContextInfo are shown in Figure 5 and include such useful pieces of information as:

  • currentCultureName
  • currentLanguage
  • layoutsUrl
  • serverRequestPath
  • siteAbsoluteUrl
  • siteServerRelativeUrl
  • webAbsoluteUrl
  • webServerRelativeUrl
  • webUIVersion

Figure 5: _spPageContextInfo includes many useful tidbits of information about the current page

Arguably, the most commonly used property is going to be webServerRelativeUrl.  We’ll see that in many of the examples throughout this series.

Utility Functions

Now we’re going to spend a little time talking about a handful of utility functions available in the out of the box SharePoint JavaScript libraries. A portion of the JavaScript deployed by SharePoint duplicates functionality that is available in other more common libraries such as JQuery. In cases where a conflict like this occurs, I typically give preference to the JQuery approach as it is going to be more familiar to traditional web developers.

As mentioned at the beginning of this chapter, there are a LOT of JavaScript libraries in SharePoint and a LOT of functions inside them, the ones I’m going to mention here are by no means the end of the list of useful functions available to us.  They’re ones that I’ve used, and found useful more than others.  You should spend a little time reviewing the out of the box JavaScript libraries to find others that you might find useful.  If you can see SharePoint doing something in the UI that is close to what you need, it is likely worth the time to track down the capability in the out of the box JavaScript to see if you can reuse it.

The other thing to note is that some of these functions have been around FOREVER, since SharePoint 2003 or earlier.  In some cases there are new pieces of functionality written in 2010 or 2013 that are just front-ends to these older functions.  Eventually, Microsoft may clean up their JavaScript and then these older functions may go away, to be replaced by their more modern cousins.  In general, when I can find a more modern replacement for an older function, I start using the newer function.

List View Functions

We’ll start with a couple of functions useful for working with list views.  These functions allow us to work with a list of items shown in a view – selecting items to take an action on them, deselecting items, getting information about an item in the UI, etc. 

The first two methods – SelectAllItems and DeselectAllItems are pretty straightforward – they give us the ability to mark or unmark items as selected in the UI.  This could be useful if we needed to perform an operation on all items and that operation was also an out of the box capability that acted on all items selected by the user in the UI.  We could select the items and then call that out of the box function to perform an operation on all items.  In reality, this is going to be just a convenience for the end users as there is UI support for selecting/deselecting all items already.  We’re just saving them that step.  An example of using DeselectAllItems is shown in Snippet 2.  The last parameter (the Boolean false shown in Snippet 2) controls whether or not the Ribbon is refreshed after the call is made.  Pass in true to refresh, or false to not refresh the Ribbon after clearing the selections.  An example of SelectAllItems is shown in Snippet 3.

function clearAll(){
	var clvp = ctx.clvp  //working with the ctx variable
	var tab =;
	DeselectAllItems(ctx, tab.rows, false);

Snippet 2: DeselectAllItems provides an easy way of clearing out selections in the user interface

function selectAll(){
	var clvp = ctx.clvp  //working with the ctx variable
	var tab =;
	SelectAllItems(ctx, tab.rows);

Snippet 3: SelectAllItems allows us to quickly mark each item shown in a list view as selected

The next function, CountSelectedItems, shown in Snippet 4, simply allows us to determine the number of items selected in the UI.  This could be useful if whatever operation we’re performing require that only one, more than one, or some other threshold of items be selected.  There are a few ways we could get this number, including some raw JQuery approaches to it, but this is arguably the simplest so in this case, I forego the JQuery approach and use what SharePoint gives me.  We simply pass in the context object and get back an integer.

var itemCount = CountSelectedItems(ctx);
alert("There are " + itemCount + " items selected. ");

Snippet 4: CountSelectedItems returns the number of items selected in a list view on a page

Next is the SelectRowByIndex function, which I view similar to the select/deselect all options.  This is useful if we need to select certain items and then perform an out of the box operation on them which works on selected items, or allow the user to then perform some action on the selected items.  If we’re programmatically determining which items we need to operate on and then doing some custom operations, there is likely little reason to select the items in the UI – we can just perform the operation directly.  This function takes three parameters:

  • ctx
  • The integer id of the row to select
  • A Boolean indicator to determine whether any previously selected items remain selected ( true to leave selected, false to clear any selected items first)

An example of using SelectRowByIndex is shown in Snippet 5.

function selectItems(){
    for (var i=0; i<ctx.listdata.row.length;i++){
    		if (parseInt(ctx.ListData.Row[i].ID) % 2 !== 0){

Snippet 5: Using SelectRowByIndex to select odd numbered rows

The last function I’ll highlight here is GetListItemByID.  This function allows us to get information about an item shown in a View.  The function itself just returns the whole Row object from the ctx.ListData.Row collection where the item’s ID matches the ID we’re looking for.  In this case, it is the actual ID property of the item, not its location in the Row collection.  Once we have the Row object for our item, we can access all of its properties – the ones we talked about earlier in this chapter when we covered the Row collection within ctx.ListData such as the value of each column shown in the View for the item.  One important thing to note is that you must pass the ID in as a string – the function does an equality check without type coercion, the three equals signs we talked about in chapter 1, and inside the Row object, the ID is stored as a string, so we need to make sure we pass in the same type.  If we do not, we won’t get a match no matter what we do.

URL Manipulation

The next group of utility functions make it easier for us to do URL manipulation – generating URLs or parsing URLs to extract values from the QueryString, for example.  Some of these are SharePoint-specific operations, some of them are not.  Some of them have equivalents in other libraries like JQuery but may require a plugin to do their work or are more complicated to work with.  These functions give us equivalent functionality simply and without an external library or plugin.

The first two we’ll cover are for working with querystring values- either getting a value or setting a value. The first of this pair is GetUrlKeyValue.  For this function, we pass in:

  • the name of the querystring key for which we need to retrieve the value
  • a Boolean indicator as to whether we want the value decoded before it is given to us
  • the URL which contains the querystring to parse
  • a Boolean parameter indicating whether the key name is case sensitive.

The return value from this function will be a string representation of the key value, or an empty string if the key doesn’t exist or doesn’t have a value.  Be aware, however, that this function will return an empty string for the value if the key you requested does not exist.  To my mind, this is the only place this function breaks down - if what you’re really checking is whether or not the key exists but don’t care about its value.  Passing in a keyName that doesn’t exist in the querystring will return an empty string, just the same as if the key exists but doesn’t have a value.  Personally, I try to avoid basing my logic just off the existence of a querystring key, instead always doing a value check so this isn’t a big deal for me.  Your approach may be different, in which case, this function may not work for you as-is.

Snippet 6 shows usage of GetUrlKeyValue.

// assume the current URL is: 
var url = document.location.href;
var myParam = GetUrlKeyValue("myParam", false, url, true);
var param2= GetUrlKeyValue("param2", false, url, true);

Snippet 6: Getting values from the querystring with GetUrlKeyValue

The next function is the opposite of the first – SetUrlKeyValue.  For this function you pass in:

the name of the key the value you want to give it a Boolean indicator as to whether or not you want the function to URL-encode the value before setting it the URL string to which you want the key-value pair appended.

Snippet 7 shows usage of SetUrlKeyValue.

// assume the current URL is: 
var url = document.location.href;
SetUrlKeyValue("myParam", “123”, false, url);
SetUrlKeyValue("param2", “abc”, false, url);
// The value of url is now: 

Snippet 7: Adding keys and values to a URL with SetQueryStringValue

The next two functions allow you to check the validity of URLs and filenames, which is especially important if some piece of the URL or filename was collected from the user in some way. IndexOfIllegalCharInUrlPath takes a string parameter and returns the index of the first illegal character, or -1 if no illegal characters were found.  One important thing to know about this function is that you need to strip certain things out of the parameter before using the function.  Specifically, do not pass in the http:// or https:// - the colon character would be considered illegal.  Technically the http:// or https:// is not a part of the path portion of the URL (it’s the scheme).  Since this function is specifically intended to check the path portion of the URL, this makes sense, but its a pretty fine distinction that most developers may not typically make.  Similarly, the querystring is also not part of the path portion so you should remove the querystring from the end of the URL - the hash (#), ampersand (&) or question mark (?) would be flagged as illegal characters.  Sample usage is shown in Snippet 8.

If IndexOfIllegalCharInUrlPath returns anything but -1, you’ll want to use the JavaScript encodeURI function to make a valid URL when a character in the path is illegal: var goodUrl = encodeURI(badUrl);

The next function, IndexOfIllegalCharInUrlLeafName, allows you check for illegal characters in a file name – LeafName in SharePoint terminology.  It operates the same as the previous function, returning the first index of an illegal character or -1 if no illegal characters are found.  To be thorough, when saving a file into SharePoint, you really need to use both of these functions – the first to check the path as a URL and the second to check just the filename.  The characters allowed in each are different.  Specifically, file (leaf) names cannot begin or end with a period and cannot contain a forward slash.  The syntax of this function is identical to IndexOfIllegalCharInUrlPath – just pass in the filename to check and get back a number.

var urlPath=""
var badChar = IndexOfIllegalCharInUrlPath(urlPath);
// badChar is 4 (:)  - we didn’t remove the scheme portion
var urlPath=""
var badChar = IndexOfIllegalCharInUrlPath(urlPath);
// badChar is 15 (?) – we didn’t remove the querystring
var urlPath ="/path/to/file.aspx"
var badChar = IndexOfIllegalCharInUrlPath(urlPath);
// badChar is -1 – no illegal characters found, and we include // just the path portion

Snippet 8: Using IndexOfIllegalCharInUrlPath to validate URL path information

The next function is one of my favorites for working with URLs in SharePoint, however geeky it may be to have a favorite function - ReplaceURLTokens allows you to replace all instances of one of 6 SharePoint specific tokens in a URL string.  The 6 tokens are:

  • {ItemId}
  • {ItemUrl}
  • {SiteUrl}
  • {ListId}
  • {Source}
  • {ListUrlDir}

These are each fairly self-explanatory, except perhaps the last two.  {Source} will be replaced with the value of the current Source URL parameter if it exists.  If it does not exist, the current URL will be used instead.  The last, {ListUrlDir} will be replaced with the site-relative URL for the current List or Library.  The one thing you need to know is that before doing a replacement, the function checks to see if it has a valid value to put in place of the token.  If it does not, it leaves the token in place, untouched.  You should always check to see if the token replacement happened before using the resulting URL – simply checking for the existence of an open curly brace in the URL would typically be sufficient.  Snippet 9 shows an example of using this function with some of the tokens.

var baseUrl=
var url = ReplaceUrlTokens(baseUrl, ctx);
if(url.indexOf(“{“) === -1){
    //Replacement done successfully.  OK to use url

Snippet 9: ReplaceUrlTokens can help build custom URLs

Next we have four recent additions into the SharePoint JavaScript libraries – obvious by the namespacing used in their full names.  The first, SP.Utilities.UrlBuilder.urlCombine, takes two string parameters and combines them without redundant slashes between them.  Unfortunately, there’s one problem.  It only works right if the second string does not begin with a slash.  If it does, the function won’t remove it and will still add the slash at the end of the first string, so we end up with two slashes.  There are various places on the internet that mention this function but neglect this important point.  While a URL with double slashes will work in most browsers, it could present a problem when trying to parse or manipulate the URL at some point so we want to try to avoid it.  Unfortunately, there is no easy way to do this natively in JavaScript for the browsers we care about in SharePoint – a trim function was only available in Internet Explorer starting in version 9.  An example of the urlCombine function is shown in Snippet 10

//current URL is
var url = SP.Utilities.UrlBuilder.urlCombine(_spPageContextInfo.webAbsoluteUrl, _spPageContextInfo.serverRequestPath);
// url is now:
// Note the double slash before SitePages.

Snippet 10: urlCombine - useful, but with a caveat

The second new function, removeQueryString, removes the specified key from the querystring of the specified url, as shown in Snippet 11.

var url=
url = SP.Utilities.UrlBuilder.removeQueryString(url, "myParam");
// url is now 

Snippet 11: Removing query string parameters with SP.Utilities.UrlBuilder.removeQueryString

Next is the GetLayoutsPageUrl function.  A simple little function that will return the proper server-relative URL for the specified layouts page for the current context.  Useful if you’re running in mixed 2010/2013 mode where some sites have been upgraded and some have not.  Usage is shown in Snippet 12.

var url = SP.Utilities.Utility.getLayoutsPageUrl("SiteSettings.aspx");
// url is now /_layouts/15/SiteSettings.aspx if you’re in 2013 UI // mode

Snippet 12: getLayoutsPageUrl helps us operate in a mixed-mode environment

The last new function I’m going to highlight is NavigateTo.  This one might seem a little simplistic – it just takes the browser to the specified URL.  But it does a little more than that which is incredibly useful in some scenarios.  If the page where this function is called is loaded into a SharePoint modal dialog, then the new page will remain inside the dialog as well.  Not useful all the time, but when used, it is a nice little addition.  Sample use is shown in Snippet 13.


Snippet 13: navigateTo - a dialog-aware redirection function

General Utilities

Before closing out this section, there are a few general-purpose functions that bear mentioning.  The first group of these are all located inside the SP.ScriptUtility namespace.  SP.ScriptUtility is a new addition to our arsenal, providing various general purpose functions for examining values.  To my mind, there are four useful functions in here:

    1. SP.ScriptUtility.isNullOrEmptyString - Gets a value that indicates whether the text passed as a parameter is null, an empty string, or undefined, returning true if so.  2. SP.ScriptUtility.isNullOrUndefined - Gets a value that indicates whether the object passed as a parameter is null or undefined.  It returns true if so.  3. SP.ScriptUtility.isUndefined – Returns true if the object passed as a parameter is undefined 4. SP.ScriptUtility.truncateToInt - Returns the largest integer value that is less than or equal to the number passed as a parameter if the parameter is greater than 0. Otherwise, gets the smallest integer value that is greater than or equal to the parameter.

    The next group are older functions, but ones that still provide some good value.

    The first two are a pair – STSHtmlEncode and STSHtmlDecode.  They allow us to HTML encode or decode a string - so either allow us to show it in HTML if we encode it, or read it, decode it and get the real string value if we’re decoding.  While encoding/decoding does more than just this, the basic change it makes to the string is to convert the less-than or greater than symbols < and > to &lt; and &gt; respectively.  This allows us to write HTML code into our HTML output without messing up the display of the page by having the code to be displayed interpreted as part of our markup.

    Next is a function that is falling out of favor as better approaches are coming into vogue, but still useful.  It supports browser identification via useragent string sniffing so we can take some different action depending on the browser in use.  Again, in modern web-development there are different, better approaches, but there are still situations in which you need to know which browser is in use.  The function that supports this is called simply BrowserIs

    BrowserIs doesn’t actually return a value.  What it does is set a series of variables that you can then reference to determine which browser is currently being used.  The function does this by parsing values out of the UserAgent string and using those values to determine the browser, version, operating system, etc.  The other variables set by this function include:

  • ie, iever, verieFull, ie4up, ie5up, ie55up, ie6up, ie7down, ie8down, ie7up, ie8standard, ie8standardup, ie9standardUp, ie10standardUp
  • ipad, webkit, safari, safari125up, safari3up, mac
  • firefox, firefox3up, firefox36up, firefox4up,firefoxVStr
  • chrome, chrome7up, chrome8up, chrome9up, chromeVerStr
  • major, windowsphone7,aol, winnt, win32, win64bit, win, w3c, win8AppHost
  • nav, nav6, nav6up, nav7up
  • msTouch, isTouch, armProcessor

I won’t go through all of them as they are pretty self-explanatory.  You can see, though, that it’s a pretty thorough list and one that has been kept up to date as evidenced by the references to IE 10 and the armProcessor variable among others.


That concludes our first chapter in which we’re working directly with JavaScript in a SharePoint environment.  As I mentioned, there is a LOT of JavaScript already included with SharePoint 2013.  The handful of items I showed here are by no means the only pieces that are useful to us.  They are just some samples I wanted to call out as you begin your journey into SharePoint JavaScript.  If, as you browse a site, you see SharePoint doing something interesting or useful in the UI without posting back to the server, chances are there is a chunk of JavaScript behind it that is likely worth looking into.  The Ribbon in particular is heavily JavaScript-driven and has a fair amount of interesting code.  Other areas are similar.  I’d strongly suggest you take time to investigate whether a function exists already that can help you out before you start writing custom code or adding other libraries to your project.


Topic: Article

Sign in with

Or register

  • Hi,

    As you said 5 JS defined in master page and there are almost 20 js files. From where these files gets loaded in sharepoint.


  • Hi