SLDS adoption in LWC is one import line plus class references in the template. The system is designed to be invisible once configured.
- Open the LWC template
Edit the component''s .html file. Plan the markup structure (form, card, table) before writing classes.
- Reference the SLDS reference site
Find the blueprint matching your component (button, card, input). Copy the HTML structure and the SLDS classes.
- Apply SLDS classes in the template
Use slds-card, slds-button_brand, slds-input, slds-grid, slds-col. The classes are documented on lightningdesignsystem.com.
- Test in Lightning Experience
Deploy the LWC. Verify the styling matches the SLDS blueprint and adapts to the org''s theme.
- Verify accessibility
Check ARIA attributes, keyboard navigation, and color contrast. SLDS blueprints document the patterns; ensure your component matches.
- Avoid custom CSS where possible
Stick to SLDS classes; custom CSS that overrides SLDS produces components that break when SLDS updates.
The HTML file where SLDS classes apply.
The utility and component classes used in the markup.
ARIA roles and labels per the blueprint.
Component should adapt to Theme Builder customizations.
- Custom CSS overrides break on SLDS updates. Stick to documented SLDS classes; treat overrides as exceptions, not the default.
- SLDS classes are designed for Lightning Experience. Components rendering inside Salesforce Classic do not benefit from SLDS styling.
- SLDS 2 is opt-in for migration. New components should target SLDS 2; old components on SLDS 1 still work but won''t benefit from the refreshed visual language.
- Theme Builder customizations apply at the org level. Component-level styling overrides take precedence and bypass the theme.