Skip to content

Commit 2f534fa

Browse files
majedelassKristinLBradleydidoodchyunjorytindall
authored andcommitted
HDS Docs - Breakpoints (#2855)
Co-authored-by: Kristin Bradley <[email protected]> Co-authored-by: Cristiano Rastelli <[email protected]> Co-authored-by: Dylan Hyun <[email protected]> Co-authored-by: Cristiano Rastelli <[email protected]> Co-authored-by: Jory Tindall <[email protected]> Co-authored-by: Melanie Sumner <[email protected]>
1 parent da538ef commit 2f534fa

File tree

9 files changed

+187
-3
lines changed

9 files changed

+187
-3
lines changed

website/docs/components/app-header/partials/code/component-api.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
A named block where the utility actions will be rendered. Typically, `Dropdown` or `Button` components should be added here, such as a help menu, user menu, or search button.
1414
</C.Property>
1515
<C.Property @name="breakpoint" @type="string" @default="1088px">
16-
Set a custom breakpoint to control the page width at which the UI switches from displaying the mobile/small view vs. the desktop/view.
16+
Set a custom breakpoint to control the page width at which the UI switches from displaying the mobile/small view vs. the desktop/large view.
1717
</C.Property>
1818
<C.Property @name="hasA11yRefocus" @type="boolean" @default="true">
1919
Controls whether a "navigator narrator" and a "skip link" are added to the navigation (provided by the [`ember-a11y-refocus` Ember addon](https://github.com/ember-a11y/ember-a11y-refocus)). It can be programmatically turned off by passing `false`. Warning: if it is set to false, then it will fail Bypass Blocks, [Success Criteria 2.4.1](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html). Since this component appears on every page, the application will not be considered conformant.

website/docs/components/app-side-nav/partials/code/component-api.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,9 @@ This is the full-fledged component (responsive and animated).
2121
<C.Property @name="isMinimized" @type="boolean" @default="false">
2222
Controls if the App Side Nav is rendered collapsed or expanded when initialized. This allows an application to preserve the collapsed/expanded state across sessions. After the initial render, this argument is altered based on user interactions (collapse/expand the App Side Nav or resize the window) and it is not a suitable way of controlling the App Side Nav state from outside after render (it’s an internal state).
2323
</C.Property>
24+
<C.Property @name="breakpoint" @type="string" @default="1088px">
25+
Set a custom breakpoint to control the page width at which the UI switches from displaying the mobile/small view vs. the desktop/large view.
26+
</C.Property>
2427
<C.Property @name="onToggleMinimizedStatus" @type="function">
2528
Callback function invoked when the `AppSideNav` is collapsed or expanded. The function receives a boolean argument stating if the `AppSideNav` is minimized or not.
2629
</C.Property>

website/docs/components/app-side-nav/partials/code/how-to-use.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -118,7 +118,7 @@ Below is an example (inspired by the Cloud UI navigation) of how the two kinds o
118118

119119
```handlebars
120120
{{!--
121-
for demo purposes we set `@isResponsive` to `false` but in your app it will probably need to be set to `true`
121+
for demo purposes we set `@isResponsive` to `false` but in your app it will probably need to be set to `true`
122122
(or omitted to rely on defaults)
123123
--}}
124124
<div class="doc-app-sidenav-demo--cloud-ui">
@@ -175,7 +175,7 @@ When the App Side Nav is used in conjunction with portals, the nesting of naviga
175175
As mentioned above, the full-fledged `Hds::AppSideNav` component is “responsive” by default:
176176

177177
- when the **viewport is `desktop`**, the sidebar navigation is static and has a fixed width
178-
- the width at which the viewport is considered “desktop” is controlled by a dedicated CSS variable `--hds-app-desktop-breakpoint`; if needed it can be overwritten (at `:root` level) to define a custom “desktop” breakpoint
178+
- the width at which the viewport is considered “desktop” can be overwritten using the `@breakpoint` argument
179179
- when the **viewport is `mobile`**, the sidebar navigation is responsive and the user can minimize or maximize its width via a toggle button (the component will take care automatically of the transitions between these two states)
180180
- in this case the App Side Nav occupies only a minimum width in terms of page layout, even when expanded (it partially covers the main content)
181181
- a toggle button is added to the App Side Nav, used to expand/minimize its width
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
---
2+
title: Breakpoints
3+
caption: Standardized breakpoints for different device widths.
4+
description: Breakpoints are width values that standardize responsive experiences across the HashiCorp product suite.
5+
links:
6+
figma: https://www.figma.com/design/uX4OEaJQdWfzULADchjAeN/HDS-Foundations-v2.0?node-id=13020-244&t=0N1UWbTuY6sSq3Od-1
7+
previewImage: assets/illustrations/foundations/breakpoints.jpg
8+
---
9+
10+
<section data-tab="Guidelines">
11+
@include "partials/guidelines/guidelines.md"
12+
</section>
13+
14+
<section data-tab="Code">
15+
@include "partials/code/how-to-use.md"
16+
</section>
Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
## How to use the breakpoints
2+
3+
In [responsive design](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design) it's common practice to define specific media queries in CSS that can be used to control not only the layout of the entire page and its parts, but also other aspects of a UI like typography, spacing, the rendering of decorative elements, the resolution of media assets, and much more. These media queries are built using CSS `@media` declarations in combination with a set of standard breakpoints.
4+
5+
Our design system defines [breakpoint values](/foundations/breakpoints#the-ranges) based on browser viewport widths. The intervals between these breakpoints create distinct ranges, which can be used with the [Sass](/foundations/breakpoints?tab=code#sass) and [JavaScript](/foundations/breakpoints?tab=code#javascript) helpers to implement responsive designs for our applications.
6+
7+
### Sass
8+
9+
To use the Sass helpers provided by the design system, you must import the corresponding Sass file (via `@use`, [as recommended](https://sass-lang.com/documentation/at-rules/use/#differences-from-import)) from the `@hashicorp/design-system-components` package:
10+
11+
12+
```scss
13+
// from @hashicorp/design-system-components package
14+
@use "mixins/breakpoints" as *;
15+
```
16+
17+
!!! info
18+
19+
If you are not able to import the file using the declaration above, [contact the Design Systems Team](/about/support) for support.
20+
21+
!!!
22+
23+
Once the file is imported, you will have access to the Sass helpers described below.
24+
25+
#### Mixins
26+
27+
Sass mixins offer the simplest, most efficient way to implement responsive layouts using the standard breakpoints defined in our system. We provide three different mixins:
28+
29+
- `hds-breakpoint-above($name)` - for media queries that apply to a viewport range **above** a certain breakpoint (useful for a mobile-first approach)
30+
- `hds-breakpoint-below($name)` - for media queries that apply to a viewport range **below** a certain breakpoint (useful for a desktop-first approach)
31+
- `hds-breakpoint-between($lower, $upper)` - for media queries that apply to a viewport range **between** two breakpoints
32+
33+
Here is an example of how the mixins could be used in a mobile-first responsive layout:
34+
35+
```scss
36+
// from @hashicorp/design-system-components package
37+
@use "mixins/breakpoints" as *;
38+
39+
.my-responsive-layout {
40+
// this is the default behavior, that covers the range 0px–767px
41+
display: flex;
42+
direction: column;
43+
gap: 1rem;
44+
45+
// at 768px the layout changes, from a vertical stack to an horizontal one
46+
@include hds-breakpoint-above('md') {
47+
direction: row;
48+
}
49+
50+
// at larger viewports we increase the spacing between the items
51+
@include hds-breakpoint-above('xl') {
52+
gap: 2rem;
53+
}
54+
}
55+
```
56+
57+
The same layout could be achieved using a desktop-first approach in a similar way:
58+
59+
```scss
60+
// from @hashicorp/design-system-components package
61+
@use "mixins/breakpoints" as *;
62+
63+
.my-responsive-layout {
64+
// this is the default behavior
65+
display: flex;
66+
direction: row;
67+
gap: 2rem;
68+
69+
// at smaller viewports we decrease the spacing between the items
70+
@include hds-breakpoint-below('xl') {
71+
gap: 1rem;
72+
}
73+
74+
// at 768px the layout changes, from an horizontal stack to a vertical one
75+
@include hds-breakpoint-below('md') {
76+
direction: column;
77+
}
78+
}
79+
```
80+
81+
Of course, these are oversimplified examples. In your implementation, you will have to choose which mixin is best suited to achieve the desired responsive layout. This will depend on the design specifications, the context of the layout within the page, and how it relates with other UI elements.
82+
83+
#### Key/Value Map
84+
85+
For special use cases, we also provide a Sass map–`$hds-breakpoints`–which is a lower level helper than the mixins. Here's an example of how this map could be used:
86+
87+
```scss
88+
// explicit import of `map` module (required by Sass)
89+
@use "sass:map";
90+
// from @hashicorp/design-system-components package
91+
@use "mixins/breakpoints" as *;
92+
93+
@each $name, $size in $hds-breakpoints {
94+
.my-custom-breakpoint-class--#{$name} {
95+
// here you have access to the breakpoint name and its value (width in px)
96+
}
97+
}
98+
```
99+
100+
### JavaScript
101+
102+
We also provide helpers in case you need to access the breakpoints names/values in JavaScript code.
103+
104+
You have access to the list of breakpoint names and values using the `hdsBreakpoints` map:
105+
106+
```javascript{data-execute=false}
107+
import { hdsBreakpoints } from '@hashicorp/design-system-components/utils/hds-breakpoints';
108+
109+
// do something with a specific breakpoint value
110+
const myBreakpoint1 = hdsBreakpoints['xl'].value; // numeric (eg. 1440)
111+
const myBreakpoint2 = hdsBreakpoints['lg'].px; // size in px (eg. 1088px)
112+
const myBreakpoint3 = hdsBreakpoints['sm'].rem; // size in rem (eg. 30rem)
113+
114+
// loop over all the breakpoints
115+
Object.entries(hdsBreakpoints).forEach(([name, sizes]) => {
116+
// do something with a specific breakpoint value in px
117+
const myBreakpointSizePx = sizes.px;
118+
});
119+
```
Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
Breakpoints are viewport widths where layouts adjust to support responsive experiences on varied screen sizes and devices. These values are used to create utilities and helper components that standardize changes in UI at these widths.
2+
3+
## The ranges
4+
5+
There are five HDS breakpoint values: `sm`, `md`, `lg`, `xl`, and `xxl`.
6+
7+
| Name | Value | Application |
8+
| ------ | ------------ | ----------------------------- |
9+
| sm | 480px | 480 → 767 |
10+
| md | 768px | 768 → 1087 |
11+
| lg | 1088px | 1088 → 1439 |
12+
| xl | 1440px | 1440 → 1919 |
13+
| xxl | 1920px | 1920 and up |
14+
15+
The breakpoint name refers to a range of pixel values, not just the starting value. For example, the `sm` breakpoint refers to widths between 480px and 767px. This helps simplify the language around what these ranges mean when designing and increases the flexibility in implementation.
16+
17+
_Note: the range 0-479px is intentionally left without a name. We don't anticipate designers needing to produce mockups for screen sizes below this width and from the audits conducted, Cloud UI has set a standard of 480px for the most narrow design. From a development perspective, in a mobile-first approach the range below 480px can be covered using default styles (overwritten via media queries for subsequent ranges)._
18+
19+
### Custom values
20+
21+
The provided breakpoints serve as a cohesive _starting_ point for design, which is why templates have been provided in our [Patterns library](https://www.figma.com/design/5Pv32j4QiOOD8lkFTD1dxC/HDS-Patterns-v2.0?m=auto&node-id=71-11371&t=OvSfKLEJhHntQQZA-1) for this purpose. However, custom values may be necessary for specific use cases that these breakpoints do not cover. For example, if a team discovers that users with 2500px viewports are using a product, a nuanced approach to the UI at that screen size may be required. In such cases, a custom width value may be used to enhance the user experience.
22+
23+
!!! insight
24+
25+
If a custom value already exists that is relatively close to an established breakpoint, we recommend migrating it to the nearest standard breakpoint. This creates a consistent and predictable experience for the user as they work within (and across) the HashiCorp product suite.
26+
27+
!!!
28+
29+
## Designing with purpose
30+
31+
Not all designs require redesigning at each breakpoint. Only when designs are considered complicated and/or constrained by UI elements should a designer take the time to show how they change as the viewport changes in size.
32+
33+
For example, a UI featuring a table layout may not require changes for each breakpoint because the expected behavior is for the table to maintain its full width regardless of the breakpoint value. A design isn't necessary to elaborate this standard behavior.
34+
35+
![](/assets/foundations/breakpoints/breakpoints-table-example.png)
36+
37+
Redesigning across multiple breakpoints is often necessary for complex UIs, such as a landing page with cards arranged in a grid. As the viewport size decreases, both the position and content of the cards change, requiring nuanced designs across breakpoints. In such scenarios, designers should specify how the layout adjusts at the `sm`, `md`, and `lg` views.
38+
39+
![Diagram depicting "large", "medium", and "small" screen sizes displaying a varying number of columns in rows of content blocks.](/assets/foundations/breakpoints/breakpoints-card-designs-shfting.png)
40+
41+
## Responsiveness in Helios
42+
43+
Responsive behavior is already built into some Helios components. These components include, but are not limited to:
44+
* [App Side Nav](/components/app-side-nav) (width collapses below lg breakpoint)
45+
* [Stepper Nav](/components/stepper/nav) (layout shifts below sm breakpoint)
46+
* [Pagination](/components/pagination) (layout stacks below lg breakpoint)
10.1 KB
Loading
22.9 KB
Loading
188 KB
Loading

0 commit comments

Comments
 (0)