Bottom Sheet

Approved — Ready for dev

A bottom sheet is used to overlay content on top of the user interface for the purpose of focusing the user’s attention on specific information or to accomplish a specific task. As a general rule, bottom sheets should provide contextually-relevant content to the parent view underneath. This component is designed only for the mobile experience. The wide-screen equivalent is the side sheet component. Anything that is considered “Mobile” will display a bottom sheet while “Tablet” and “Desktop” display the side sheet.

Bottom Sheet

Anatomy

The bottom sheet component is made up of a raised surface that contains content and affordances to close the bottom sheet. All other elements are optional. Bottom sheets come in two variants: full screen and partial

Full screen bottom sheet

Full screen bottom sheets are raised above the surface and completely cover the context underneath. 


  1. Bottom sheet surface
  2. Section heading (optional)
  3. Close affordance & backstack affordance — Quick action button component
  4. Menu button — Compact button (optional)
  5. Header container (if needed)
  6. Content area (just for reference)

Partial bottom sheet

Partial bottom sheets only come up as much as needed to display the content within the sheet (more on this in the behavior section).


  1. Raised surface
  2. Content heading (optional) (See content headings)
  3. Scrim (optional)
  4. Close affordance
  5. Header container (if needed)
  6. Content (just for reference)

Footer

Bottom sheets can contain optional footers to provide space for calls to action where the CTA can remain sticky and not scroll with the content.

  1. Footer container
  2. Content scrolled below footer (just for reference)
  3. Content within the footer (just for reference)

Stepped nav

Bottom sheets can contain an optional stepped navigation within the footer where the user can jump between steps and quickly understand progress through a wizard-like experience.

  1. Footer container
  2. Content scrolled below footer (just for reference)
  3. Steps — Quick action button 24

Heading alignment & truncation

Headings for full height bottom sheets should be left-aligned; however, when scrolled the content headings are always centered. Content headings for partial bottom sheets can either be left-aligned or centered, depending on what makes the most sense for the solution. In most cases, headings for partial bottom sheets should be left aligned, but when the rest of the content in the bottom sheet is centered, the heading should be centered as well.

Heading text should truncate when space is not available, and should never wrap to two lines

  1. Full screen bottom sheet (left-aligned heading only)
  2. Scrolled full screen bottom sheet (centered heading only)
  3. Partial bottom sheet (left-aligned heading)
  4. Scrolled partial bottom sheet (centered heading)

Specs


Color

Element Property Value
Raised surface Background color ∆surfacePlatformRaisedBackgroundColor
Heading Type color ∆colorPlatformGray900
Close affordance (partial variant) Handlebar color ∆colorPlatformGray200
Raised surface Shadow color ∆surfacePlatformRaisedShadowColor
Quick action button (Full screen variant) Container color ∆colorBrandedAffordance50
Quick action button (Full screen variant) Icon color ∆colorBrandedAffordanceAccessible

Elevation

Element Property Value
Raised surface Shadow Y-offset ∆surfacePlatformRaisedShadowY
Raised surface Shadow opacity ∆surfacePlatformRaisedShadowOpacity
Raised surface Shadow blur ∆surfacePlatformRaisedShadowBlurResting
Raised surface Shadow spread ∆surfacePlatformRaisedShadowSpread

Spacing

Bottom sheets have padding of ∆spacingPlatformBase (24px). All other content spacing is defined at the atom or component level. On partial bottom sheets, the handlebar should be placed 8px below the top edge of the surface.

Full screen (default)

Full screen (scrolled)

Partial (default)

Partial (scrolled)

Footer

Footer with stepped navigation

When all the steps can fit within view, each step takes up an equal amount of horizontal space. When there are too many steps to fit within view, steps are initially aligned to the left and can scroll horizontally.


States

Header

Content, at its default state does not impact the header elevation or treatment until scrolled. Once scrolled, the header then takes on an elevation with the content scrolling underneath while the header remains fixed at the top of the screen.

  1. Full screen — default
  2. Full screen — scrolled
  3. Partial — default
  4. Partial — scrolled

Footer

Content, at its default state may or may not impact the footer elevation. If there’s enough room for the content to appear within the bottom sheet without scrolling, the footer does not take on an elevation; however, if there’s too much content to display, then the content can overflow off the screen. In this case, the footer in the default state would take on an elevated state. 

  1. Footer — content in a default state (dotted line represents unscrolled content)
  2. Footer — content scrolled (notice dotted line representing scrolled content underneath the footer and beyond the visible bounds of the device), or content that is not visible due to limited screen size.

Theming

Color

Element Property Value
Close affordance (full screen variant) Quick action button background ∆colorBrandedAffordance50
Close affordance (full screen variant) Quick action button icon ∆colorBrandedAffordanceAccessible

Shape

Element Property Value Note
Container Large ∆shapeBranded Partial bottom sheet only; full-screen bottom sheets have no visible corners, and should ignore the theme entirely
Quick action button Small ∆shapeBranded Full-screen bottom sheet only

Type

Element Property Value
High emphasis section heading (small heading from the type scale) Font family ∆typeBrandedFontFamily
High emphasis section heading (small heading from the type scale) Font weight ∆typeBrandedFontWeight
High emphasis section heading (small heading from the type scale) Line height ∆typeBrandedLineHeight
High emphasis section heading (small heading from the type scale) Character spacing ∆typeBrandedCharacterSpacing

Placement

Bottom sheets should always be anchored to the bottom of the screen, and can be placed into one of two states: contextual or persistent.

Contextual placement

Bottom sheets are contextual by nature, and should only appear when the user needs some contextual UI, and be dismissed fully when no longer needed.

Persistent placement

Sometimes the content in a bottom sheet will be continually referenced throughout a user’s journey, and should be persistently pinned at the bottom of the screen until a flow is completed or the user navigates away from the context.


Usage do’s

Bottom sheets are useful for a wide variety of use-cases and can contain one or more atoms on their surface, and can appear as a result of user interaction or by system request. Some examples of bottom sheet usage: 

  • Providing quick access to contextual features.
  • Surfacing contextual interaction options.
  • Surfacing interstitial content with medium emphasis

Usage don'ts

Avoid using a bottom sheet when:

  • The content makes more sense existing within the parent context
  • The interaction is initiated by a card component (in which case the card should grow to fill the view instead of triggering a bottom sheet)
  • There is no contextually useful information or possibilities for interaction on the bottom sheet

Native versus responsive web

Use bottom sheets on viewports smaller than 560px. On 561px and over, the physicality of gestures is lost, and interaction is typically performed with a mouse. Because of this, bottom sheets should be replaced with Side Sheets or otherwise persistent content.

Anything that is considered “Mobile” will display a bottom sheet while “Tablet” and “Desktop” display the side sheet.



Behavior

Bottom sheets have a minimal number of interaction patterns, all of which support their contextual and interstitial nature. These interaction patterns are: entry, swipe to fill/shrink, and dismiss/resolve.

Entry

Bottom sheets enter from the bottom of the screen in 300ms using the Deceleration curve. If there is a scrim it should fade in over this time.

Swipe to fill view or shrink

Generally speaking, partial bottom sheets should come up just enough to display the content within; however there may be some instances where you want the bottom sheet to come up halfway — requiring the user to scroll to reveal more content. Partial bottom sheets may be swiped up to fill the view if there’s more content available to show; otherwise swiping up will not change the height of the bottom sheet. This interaction can be reversed by swiping down. This animation should be timed by — and track with — the user’s finger. Appropriate affordances fade in and out over 100ms halfway through the transition. If any snapping is required it should occur over 150ms using the Standard ease.

Dismiss or Resolve

Bottom screens are dismissed and resolved using the same animation, exiting the screen over 250ms using the Acceleration curve. If there is a scrim it should fade out over this time.

Header and footer behavior

When headers or footers are used, they should always remain within view and receive elevation only when content scrolls underneath.

The following graphic shows how the content scrolling under the header receiving elevation. Note: this is a graphic showing the side sheet behavior, but the way the header receives elevation is the same for the bottom sheet.

Interaction Steps Duration Easing Notes Haptics
Header/Footer receiving elevation as content scrolls 1. Surface becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The header/footer surface becomes visible with an elevated surface treatment prior to content scrolling underneath. None
1.5 Header title becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The header title becomes visible at the same time as the header surface. None
1.5 Footer title becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The footer content becomes visible at the same time as the footer surface. None


Developer Docs

Vue Developer Docs

Component documentation coming soon!