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.
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 one.app 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, one.app 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 one.app container, each of which automatically applies SLDS, and we will touch on them here.
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 one.app 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 one.app 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 one.app container, you can extend force:slds in the application definition to implement the SLDS style sheets and design tokens from Lightning Design System.
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.
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 one.app 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.
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: