The Cloudscape visual style is flat, modern, and robust. Shadows are used to provide visual hierarchy through elevation to help to mimic the behavior of layering elements on the page. In Cloudscape, typically large elements that encompass smaller elements have a shadow, while the smaller elements that are used inside larger elements don't have a shadow. In some cases, when a more subtle sense of depth is needed inside an element which already has a shadow, we apply a lighter shadow called inner shadow.

Consider the following example. A table is meant to live directly in the app layout, so it has an outer shadow applied by default. However, when you enforce a sticky header on the table, a lighter shadow is applied in the header to mimic the scrolling layer. On the other hand, an input does not have any shadow because it is typically used inside other elements which have shadow, such as form sections.

Shadow

Large elements that contain other elements have a shadow.

Container

• Flash

Other examples not shown: table, cards, form section, and modal.

Inner shadow

A light shadow is applied to elements that are used inside other elements that already have a shadow.

No shadow

Small elements that are used inside other elements don't have a shadow.

Button

Alert

Other examples not shown: autosuggest, button dropdown, checkbox, multiselect, select, textarea, and tiles.

Additional details

Display	Role	Examples
	Shadow for containers and cards.	Outer shadow for container, cards, and board items.
	Shadow for elements of interactive nature, to better differentiate between the selectable components.	Outer shadow for modal, popover and dropdowns.
	Shadow for navigation elements and side panels.	Outer shadow for app layout navigation and tools panels.
	Shadow of app layout panel triggers and drag states.	Outer shadow for app layout navigation, tools, split panels triggers, and board item drag state.

Borders are another mechanism used to visually group elements or separate them from one another. The border color varies depending on the component and context, but the width stays constant at 2px. Elements have varied border radius based on their purpose and placement amongst other elements in the interface. Dividers are used sparingly throughout the system so that they don't lose their meaning. A divider used effectively will enhance readability in a large group. 2px dividers are the default and most commonly used type in the system. Meanwhile, 1px dividers are used for repeated dividers, such as the ones found in lists for as tables and dropdowns.

Consider the following example. An input and select have a border radius of 8px to indicate that the two elements are peers, while the container they live in has a border radius of 16px, indicating that it is a component of a different type and purpose. A horizontal divider is used in a table to separate each row from one another and a vertical divider is used to separate table column headers.

The system uses both outlines and fills to communicate messages to users. A solid fill paired with white text creates the greatest contrast between other elements so it is used to call attention to elements of the utmost importance. Elements that don't require as much attention but are important, use a lighter fill background by default or on hover. Most elements though, don't have a background fill at all and just use an outline.

Consider the following example. A primary button uses a solid orange-600 background color to call attention to the next suggested action. An alert uses a background fill of blue-100 to call attention to the element but with less emphasis. Most icons don't have any fill and just use an outline.

States communicate the status of user interface elements to the user. States should be applied consistently across components in order to increase usability. As a reminder, we don't recommend overriding styles in Cloudscape components.