Design System Visitor Center

When you see an unexpected UI discrepancy, use the Inspector to evaluate:

1. Look for SLDS classes (all SLDS classes start with the SLDS prefix. ie: .slds-foo)
2. Check for CSS overrides (This is any class without the SLDS prefix)
3. If there are overrides, turn them off one by one to see if the UI of the component changes
   • Fix 1: This may solve your problem, If so, ask your team to remove the overrides.
4. If there are no overrides, your issue may come from using a UI namespace component.
   • For example, there are cases where an .slds-button--default class is added to a .ui-button. Then a flavor of .ui-button (.ui-button--brand) was used to create the blue button (instead of using the properly maintained .slds-button_brand class).
   • Fix 2: The UI namespace will be deprecated in the future. If possible, use this opportunity to move to the Lightning namespace (Base Components) where the components are built directly from SLDS blueprints.
5. If you don’t find the problem is with SLDS (the developers built something bespoke), be sure they’re using the right tokens. You can look on the SLDS token page, inspect the values on the SLDS blueprint and see if it matches their value, and if you can’t discern what token should be used, send them to SLDS office hours (or post on our Slack channel) and we’re happy to help.

The more you can align your component with SLDS, the less work you’ll do on it over time. If none of the above solve your problem, please file a bug on SLDS (using the SLDS product tag) including all the information from your bug triage above.

Blueprints updated and in core:

• Button
• Button Groups
• Input
• Menus
• Combobox (Picklist, Lookups)
• Checkboxes
• Radio Groups
• Pills
• Forms Element (on-going but mainly done since this is an aggregation of most of the above)
• File Selector
• Progress Indicator
• Modal
• Map
• Rich Text Editor
• Slider
• Stacked variant (checkbox, radios)