Posts tagged ‘SLDS’

What is Salesforce Lightning Design System (SLDS)?

A design system is a collection of design principles, style guides, and elements that enable developers to focus on how components and applications work, while designers can focus on how the application looks and feels.

The Salesforce Lightning Design System (SLDS) is a trusted, living, platform-agnostic design system that was built from the ground up to provide developers with everything needed to implement the look-and-feel of Lightning Experience and the Salesforce1 mobile application.

SLDS ensures consistency across all components and applications, whether they are written by Salesforce developers, ISV partners, or even Salesforce itself when designing and implementing product features.

Salesforce developed SLDS with four key design principles in mind:

  • Clarity
  • Efficiency
  • Consistency
  • Beauty

These principles are applied to colors, typography, layout, icons and more throughout the accompanying CSS framework.

Developers can implement the design system by including SLDS Cascading Style Sheets (CSS) and icon libraries in components and applications and applying the appropriate CSS classes to component markup.

SLDS also includes CSS style sheets for applying the design system to Visualforce components, Heroku and native iOS applications.

When SLDS was first introduced, adding the style sheets or icon libraries to a Salesforce org required installing an unmanaged package or uploading files as Static Resources and manually upgrading to new versions of the design system as they were released.

As of the Winter ’17 release of Salesforce, SLDS is included out-of-the-box with all Salesforce orgs and no longer requires an explicit reference to the Static Resources from Lightning Components or Applications. You simply reference the appropriate SLDS class names in your component markup and it will be applied automatically, or you can use BaseLightning Components, which apply SLDS implicitly without additional markup.

Overview: Applying Salesforce Lightning Design System (SLDS) to Lightning Components and Applications

If you want to recreate the look-and-feel of Lightning Experience or the Salesforce1 mobile application, you will need to apply the Salesforce Lightning Design System (SLDS) external style sheet to your Lightning Components and Applications.

There are a number of ways in which to apply SLDS styling, with some being automatic based on context, and others requiring a reference to the SLDS style sheet in markup.

Although not a technical deep dive, this overview will help you understand the different strategies for applying SLDS to your Components and Applications.

Implementing SLDS

Prior to the Winter ’17 release, the only ways to implement SLDS were to either download the design system as a ZIP file that contained the CSS style sheets and icon library and upload the ZIP as a Static Resource, or download an unmanaged package to your org.

In either case, the burden of keeping the SLDS resources up to date fell on developers and admins, who had to monitor for updates to SLDS and upload new versions to the Static Resource as they became available.

In some cases with early adopters of Lightning, there were multiple versions of SLDS floating around as Static Resources within a Salesforce org, further complicating the maintenance requirements.

With the Winter ’17 release, SLDS is included in all Salesforce orgs and will be updated on a schedule that is more aligned with the three-time per year Salesforce release schedule.

Lightning Experience and Salesforce1

As of Winter ’17, any Lightning Components that are exposed in Lightning Experience or Salesforce1 will automatically have SLDS included in the app.css external style sheet that gets generated at the time the Lightning Component Framework bootstraps.

When you work in Lightning Experience or Salesforce1, the user interface is composed by a special top-level application that we refer to as the container. If you look at the address bar of your browser when you are using Lightning Experience, you will notice the URL looks something like this:

Just like we can create our own custom .app applications and expose them by URL, is a Lightning Application that contains all of the markup, styling and events needed to run the Lightning Experience and Salesforce1 user interfaces.

There are a number of options for exposing your custom Lightning Components through the container, each of which automatically applies SLDS, and we will touch on them here.

Lightning Pages

Lightning Pages are created using the Lightning App Builder, which is a drag-and-drop interface that allows you to declaratively create new user interfaces from any standard, custom, or third-party Lightning Components that implement a special interface.

Lightning Pages enable developers and admins to create new App Pages, Home Pages, and Record Pages by simply by assembling reusable components on a canvas and assigning component attribute values where required.

When you implement the appropriate interface and expose your custom Lightning Components as Lightning Pages, they will automatically have SLDS available to them.

Lightning Component Tabs

If you simply want to expose your Lightning Component as a custom tab in Lightning Experience, you can create a new Lightning Component Tab and add it to Apps in the App Launcher. By implementing the interface to expose your Lightning Component in a tab, the component will have SLDS available to it when it is rendered in the container.

Lightning Quick Actions

With the Winter ’17 release, Salesforce introduced the concept of exposing Lightning Components as Quick Actions. Now you have the option to expose your Lightning Component in a much more granular fashion than exposing it on a Lightning Page or in a Lightning Component Tab, and any Lightning Component that implements the appropriate interface can be exposed as a Quick Action.

Again, since the component is being rendered in the container, SLDS will be available to your component automatically.


If you implement the necessary interface for exposing a Lightning Component to the Community Builder, the component will be given access to SLDS CSS classes when exposed in a Community Page.

Lightning Out and Lightning Components for Visualforce

Whether using Lightning Out to expose Lightning Components to an external website or a Visualforce page, SLDS CSS classes will automatically be included in the app.css stylesheet so you won’t have to worry about manually loading the SLDS stylesheet or other assets.


To apply the look and feel of Lightning Experience and Salesforce1 in custom Lightning Applications (.app resources) that are not rendered in the container, you can extend force:slds in the application definition to implement the SLDS style sheets and design tokens from Lightning Design System.

For example:

<aura:application extends="force:slds">

    <c:MyCustomComponent />


Note: force:slds can only be extended by Lightning Applications. If you attempt to extend force:slds in the definition of a Lightning Component, the compiler will throw an error.

Static Resource

In some cases you may have a requirement to use a specific version of the Lightning Design System. If you do not want to take advantage of automatic upgrades to SLDS provided by the container or by extending force:slds, you can upload the CSS stylesheets for SLDS as Static Resources and create a dependency on them in your components by using ltng:require.

If you do choose to use a Static Resource to apply SLDS, or if you have components that were developed prior to Winter ’17, keep in mind that you will be responsible for maintaining the stylesheets in your Salesforce org.

Unmanaged package

In earlier releases of SLDS, the design system was available as an unmanaged package that could be downloaded directly into your Salesforce org. This is no longer an option as the unmanaged package has been deprecated.

To find more detailed technical articles related to styling Lightning Components and Applications, check out the curated library of Lightning content here: