CSS in Salesforce is most useful when it composes with SLDS and respects component scoping. Bespoke CSS is the exception, not the rule.
- Start with SLDS classes
Compose Lightning Web Components from SLDS utility classes (slds-grid, slds-text-heading_medium). Custom CSS only fills the gaps SLDS does not cover.
- Scope CSS to the component
Write CSS in the component's own stylesheet file. Avoid global selectors; LWS scoping enforces component boundaries.
- Use design tokens for theme values
Reference SLDS design tokens (var(--lwc-colorBrand)) rather than hard-coded colours. Tokens propagate theme changes automatically.
- For Experience Cloud, use Branding Sets first
Configure Branding Sets in Experience Builder. Add Site CSS only when Branding Sets cannot cover the design need.
- Test across surfaces
LWC, Aura, Visualforce, Email Templates, Experience Cloud each render CSS differently. Test the styling in every surface it ships to before launch.
- Custom CSS overriding SLDS produces accessibility regressions and breaks on Salesforce releases. Compose with SLDS, do not fight it.
- LWC enforces shadow DOM scoping. Selectors that reach across components fail; communicate through CSS custom properties or slots.
- Email Template CSS needs to be inlined for cross-client compatibility. Internal style elements do not render reliably in Outlook.
- Experience Cloud Site CSS overrides Branding Sets. Mixing both creates inconsistent theming; pick one as the primary source.