Breakpoints up, down, only

[alex-page]

I am a huge fan of the new functionality for breakpoints. I am interested though how useful providing up down and only is to product teams.

• Do teams need total breakpoint tokens * 3 (up + down + only) breakpoints?
• What layouts and user interfaces benefit most from the multiple breakpoints?
• Could we leverage coverage to force folks to use a specific approach for breakpoints? e.g. only down breakpoints are allowed
• Could we encourage mobile first layouts by choosing one approach over others?
• How would we document up down and only to developers and designers?

Before we make this API public I would love to get folks opinions on this.

[BPScott]

Could we leverage coverage to force folks to use a specific approach for breakpoints? e.g. only down breakpoints are allowed

My personal preference is "mobile first" which biases towards "X and up" only breakpoints, as designs should be additive - "design mobile first and then desktop layouts is mobile stuff plus some extra bits" rather than "design desktop first and then mobile layouts are desktop stuff with a bunch of stuff taken away".

I'm a really big fan of naming the ranges that we provide, rather than the individual breakpoint numbers. This is possibly the best ASCII art I've ever done. "768px" isn't a super useful number as it lacks context "a media query of 768px and up" feels better to me. I think curation at the "range" level lets us impart more information to the use as we can name things like "when the navigation column is expanded" and "when the navigation is collapsed" which is harder if we're limiting ourselves to naming a number (768px) and "up/down".

[aaronccasanova]

I'm a really big fan of naming the ranges that we provide, rather than the individual breakpoint numbers.

With our recent/experimental approach there is nothing stoping teams from creating named media conditions that best describe their business requirements.

e.g. Here is a subset of the generated _media-queries.scss file:

/* Breakpoints - Aliases */
$p-breakpoints-xs: 0em;
$p-breakpoints-sm: 35em;
$p-breakpoints-md: 48em;
$p-breakpoints-lg: 63em;
$p-breakpoints-xl: 111em;

/* Breakpoints - Media conditions */
$p-breakpoints-sm-up: '(min-width: 35em)';
$p-breakpoints-sm-down: '(max-width: 35em)';
$p-breakpoints-sm-only: '(min-width: 35em) and (max-width: 48em)';

$p-breakpoints-md-up: '(min-width: 48em)';
...

Where teams would eventually be able to compose their own named media conditions (if necessary).

@import '@shopify/polaris/styles/media-queries'

// Basic re-assignment
$navigation-expanded: $p-breakpoints-md-up

// Custom
$navigation-expanded: "(min-width: #{$p-breakpoints-md})"
$navigation-collapsed: "(min-width: #{$p-breakpoints-xs}) and (max-width: #{$p-breakpoints-md})"
etc...

I'm not sure, at a system level, we can reliably make assumptions (breakpoint ranges) that are applicable to every application (especially in a component library). IMO, what's important is having established breakpoint values that are understood and adopted across design and development teams.

[BPScott]

I'm not sure, at a system level, we can reliably make assumptions (breakpoint ranges) that are applicable to every application (especially in a component library)

This is a really good point - each app is a bit different, though if they're consuming polaris then if feels safe to assume that they'll be using our components so we can curate a list of breapokints and ranges based on when changes occur within Polaris components. I've saw a spreadsheet documenting the current state of the world, which is fantastic data gathering.

I picked navigation as an example because that's something specific that this component library controls - It's the polaris Frame and Navigation components that are responsible for rendering the navigation, and thus choosing the point at which it collapses. It is not up to the consuming app to decide that breakpoint.

I'd imagine that there'd be a set of breakpoints we push to end users - "these are the moments that the polaris components change, so your stuff changing at the same time would be unsuprising and consistent". I imagine stuff like "when the polaris nav is show/hidden", "when the polaris typography typographqy sizes change" and "when the polaris layout stuff changes from stacked to multi-column" could exist, in addition to the low-level building blocks like small/medium/large (contrast typography stuff - I imagine we'd aim for tokens for building-blocks "24px" and and semantic "heading-1").

With our recent/experimental approach there is nothing stoping teams from creating named media conditions that best describe their business requirements.

💯 Big fan of that rational, love the direction of trying to empower, by providing the low-level building blocks in addition any more semantically named values

[aaronccasanova]

I agree with all the above! There are definitely opportunities for us to expose additional named breakpoint ranges from Polaris for consumers to hook into and make adjustments along side our (internal) responsive behavior 👍 That being said I would imagine, for the most part, these named breakpoint ranges could be composed of up, down, only. I'm hoping this standardization will take the 70 unique media queries found on /admin and reduce them down to ~13 (regardless of any additional named breakpoint ranges).

[aaronccasanova]

Thanks for kicking off this discussion and providing a great prompt! I'll start by addressing these point for point and following up with my personal preferences.

• Do teams need total breakpoint tokens * 3 (up + down + only) breakpoints?

This is quite a tough question to answer generically. With most layout scenarios there are multiple ways to solve the same problem. While I think we should have a recommended approach (e.g. default up), the most important goal should be to enable engineers to best describe their layout intentions. On /admin alone we have 70 unique media queries that for the most part could be expressed with up, down, and only media conditions.

e.g. What example best describes the author's intent?

.my-class {
  padding: 0px;
  @media md-up { padding: 20px }
  @media lg-up { padding: 0px }
}
// vs
.my-class {
  @media md-only { padding: 20px }
}

• Could we leverage coverage to force folks to use a specific approach for breakpoints? e.g. only down breakpoints are allowed

The easy answer is yes, we have the ability to add lint rules for media queries via @shopify/stylelint-polaris. The hard part is how can we intelligently provide guidance from a tool that has no context of the business requirements or authors intent. Which gets into familiar territory where if system doesn't empower authors they will build their own solutions.

• Could we encourage mobile first layouts by choosing one approach over others?

Yes, imo we should absolutely encourage mobile first (e.g. up). However, I don't believe that using a down media conditions means you've violated mobile first principles. There are scenarios where it is cleaner to use down media conditions or even combining up and down conditions.

• How would we document up down and only to developers and designers?

Here is a WIP that could be reference on the Polaris documentation site:

We use 5 mobile first breakpoints for responsive design within Polaris: `xs`, `sm`, `md`, `lg`, and `xl`

| 0px ->
| xs
      | 560px ->
      | sm
               | 768px ->
               | md
                        | 1008px ->
                        | lg
                                  | 1776px ->
                                  | xl

Each breakpoint exposes 3 media conditions that can be used to apply responsive styles throughout your application:
* up   - Applies styles from the defined breakpoint alias and up e.g. `@media #{$p-breakpoints-md-up}`
* down - Applies styles from the defined breakpoint alias and down e.g. `@media #{$p-breakpoints-md-down}`
* only - Applies styles for only the defined breakpoint alias e.g. `@media #{$p-breakpoints-md-only}`

These media conditions follow the pattern $p-breakpoints-<alias>-<direction>

Personal take

A common theme throughout my feedback is around exposing an API that engineers want to use and allows them to best describe their intent. Not accounting for 3rd party apps, I've estimated we are already using ~300 only, ~600 down, and ~600 up media conditions (not accounting for any named media conditions). Being that our existing architecture already has a form of up, down, and only media conditions, I'd like to assume positive intent that engineers are using the appropriate tools to express their responsive design requirements. As opposed to assuming everything that is not an up media condition is "wrong".

Lastly, I want to mention that our most recent addition of up, down, and only media conditions was inspired by open-props media.css and MUI Breakpoints.

[kyledurand]

I'd love to be able to build everything mobile up only but that's just not possible at Shopify. Historically designers default to desktop and smaller screens are more an afterthought, in both design and prototyping.

My only concerns here are with only because in generating them we essentially generate two useless values at the top and bottom of the scale. This could lead to a some confusion for only a small amount of ergonomics gained.

All that said we are a design system and have to be flexible so if there's a want or need for only, and it does seem like it's a popular feature, then I'm fine with including it.

[aaronccasanova]

For reference here are all the generated breakpoints media conditions

/* Breakpoints - Aliases */
$p-breakpoints-xs: 0em;
$p-breakpoints-sm: 35em;
$p-breakpoints-md: 48em;
$p-breakpoints-lg: 63em;
$p-breakpoints-xl: 111em;

/* Breakpoints - Media conditions */
$p-breakpoints-xs-up: '(min-width: 0em)';
$p-breakpoints-xs-down: '(max-width: 0em)';
$p-breakpoints-xs-only: '(min-width: 0em) and (max-width: 35em)';

$p-breakpoints-sm-up: '(min-width: 35em)';
$p-breakpoints-sm-down: '(max-width: 35em)';
$p-breakpoints-sm-only: '(min-width: 35em) and (max-width: 48em)';

$p-breakpoints-md-up: '(min-width: 48em)';
$p-breakpoints-md-down: '(max-width: 48em)';
$p-breakpoints-md-only: '(min-width: 48em) and (max-width: 63em)';

$p-breakpoints-lg-up: '(min-width: 63em)';
$p-breakpoints-lg-down: '(max-width: 63em)';
$p-breakpoints-lg-only: '(min-width: 63em) and (max-width: 111em)';

$p-breakpoints-xl-up: '(min-width: 111em)';
$p-breakpoints-xl-down: '(max-width: 111em)';
$p-breakpoints-xl-only: '(min-width: 111em)';

My only concerns here are with only because in generating them we essentially generate two useless values at the top and bottom of the scale. This could lead to some confusion for only a small amount of ergonomics gained.

We only generate 1 "useless" media condition for only at the top of the scale (and useless as in it's the same as up at xl) e.g.

$p-breakpoints-xl-up: '(min-width: 111em)';
$p-breakpoints-xl-down: '(max-width: 111em)';
$p-breakpoints-xl-only: '(min-width: 111em)';

The other useless value your referring to is xs-down as there's no such thing as a breakpoint below 0px 😄

$p-breakpoints-xs-up: '(min-width: 0em)';
$p-breakpoints-xs-down: '(max-width: 0em)';
$p-breakpoints-xs-only: '(min-width: 0em) and (max-width: 35em)';

IMO, the trade off here was documentation. It's much easier to document Each breakpoint exposes 3 media conditions that can be used to apply responsive styles throughout your application:... as opposed to describing this as well as the special cases we don't generate.

Also, I've been putting "useless" in quotes throughout my feedback as I don't believe xl-only is "useless" if its the best way to describe the authors intent. There has already been discussion about adding 2x, 3x, etc. breakpoints (though we are prototyping with the current 5).

[lgriffee]

I saw a spreadsheet documenting the current state of the world, which is fantastic data gathering.

Not sure if this is the one you were mentioning @BPScott—yesterday, I did a breakpoint audit in Polaris and created a spreadsheet* to try and understand what's going on better. Wanted to list it here since I think it will be helpful in determining our approach moving forward.

*If this link breaks in the future I've created a simplified version of the tables in GitHub.