Quote Google on the docked toolbar's corners
The condensed reference said a docked toolbar is never rounded and left 'it' ambiguous for the large-screen form; the guidelines page says straight corners, except that on web and large screens the docked toolbar can be rounded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qwx5USif3wFFmxtHg5U1g9
This commit is contained in:
co-authored by
Claude Opus 5
parent
f33fb8be64
commit
31ccd5440c
@@ -505,14 +505,14 @@ Bottom app bar (baseline, still documented under Toolbars) — see Bottom App Ba
|
||||
### Behaviour and guidelines
|
||||
- Docked toolbar and navigation bar occupy the same screen position — **never show both simultaneously**; show the nav bar on primary pages, toolbars on secondary pages with contextual actions.
|
||||
- Floating toolbars can double as local/secondary navigation tabs between related pages, but must not create redundant/confusing navigation combos with any bar already on screen.
|
||||
- Container: docked toolbar never gets rounded corners (implies false expandability) — square only; floating toolbar is fully rounded (CornerFull) by default.
|
||||
- Container: "Avoid applying rounded corners to the container. This can imply the container expands or changes upon interaction" — a docked toolbar uses straight corners, except on web and large screens (next rule); floating toolbar is fully rounded (CornerFull) by default.
|
||||
- Slot layout: minimum 16dp leading/trailing padding is mandatory; 32dp between-item padding is the default (adjustable). All controls need a minimum 48x48dp target.
|
||||
- Avoid overloading a toolbar with too many controls — the floating toolbar's container must stay fully visible on screen; overflow into a menu instead of letting the container clip the window edge.
|
||||
- Only one action should be visually emphasized at a time (filled/tonal icon button, custom color roles, wide icon button, or a paired FAB) — never emphasize more than one control simultaneously (e.g., a button AND a FAB together).
|
||||
- Never use square icon buttons inside a floating toolbar (visual conflict with its fully-rounded shape) — square buttons are fine in a docked toolbar.
|
||||
- Floating toolbar elevation is on by default; can be removed if the background already gives visual separation.
|
||||
- Vertical floating toolbars: not recommended in compact windows (can overwhelm simple/complex layouts alike); when paired with a navigation rail, place the toolbar on the opposite screen edge and use the rail's centered configuration.
|
||||
- Resizing: docked toolbar always spans 100% width; medium+ breakpoints allow centering all elements or centering one key action while pinning others to the edges. On web/large screens it can gain rounded corners and use dividers to organize many actions, or shrink height / use extra-small buttons only if vertical space is constrained.
|
||||
- Resizing: docked toolbar always spans 100% width; medium+ breakpoints allow centering all elements or centering one key action while pinning others to the edges. "On web and large screens, the docked toolbar can be rounded. Dividers can be used to organize large amounts of items. Only shrink the height and use extra small buttons if vertical space is limited." (The rounded large-screen form is the docked toolbar's; the floating toolbar is always fully rounded.)
|
||||
- RTL: mirror icons/text direction; if action order matters, reverse the action order too (e.g., "Next" stays on the trailing edge in both directions).
|
||||
- Scrolling: docked toolbars can stay fixed or animate off-screen; floating toolbars can stay fixed, animate off-screen, or (Jetpack Compose) collapse into a single high-emphasis action/FAB on scroll — never combine collapsing and scroll-transitioning at the same time.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user