Page MenuHomePhabricator

Decide on CSS breakpoints for the design system
Open, MediumPublic

Assigned To
Authored By
STH
Mar 10 2022, 2:56 PM
Referenced Files
Restricted File
Wed, Jun 22, 5:45 PM
Restricted File
Tue, Jun 21, 8:46 AM
Restricted File
Tue, Jun 21, 8:46 AM
F35239729: image.png
Tue, Jun 14, 1:14 PM
F35224430: Captura de Pantalla 2022-06-10 a las 11.53.21.png
Fri, Jun 10, 10:08 AM
F35224423: Captura de Pantalla 2022-06-10 a las 11.52.06.png
Fri, Jun 10, 10:08 AM

Description

Goal

Clarify what our breakpoints should be and document them as Codex tokens

Historically, most of the breakpoint groundwork was done in MobileFrontend and MinervaNeue.

User stories

  • As a designer I need that the most used and relevant screens are covered with the breakpoints, to be able to design on those screens and know that my designs will work well on those screen sizes.

Considerations

Current breakpoints definitions in Codex:

Defined in 'codex-base.json', status 2022-03-31

A capable mobile device considered minimum available screen width.
Many older feature phones that were already able to browse the web have screens smaller than this value. As they weren't considered smartphones with real HTML/CSS rendering capabilities, this min-width mostly acted as sanity check to ensure something is a smartphone.

@min-width-breakpoint-mobile: 320px;

A tablet considered devices' minimum available screen width.
Tablet size was defined with first wide-spread Samsung tablet, Galaxy S5 mini and low enough to cover early generation iPads (768px):

@min-width-breakpoint-tablet: 720px;

A desktop considered devices' minimum available screen width.
Currently used (as @width-breakpoint-desktop) in MW core, MinervaNeue and Vector. Extensions GrowthExperiment, MediaSearch, Wikibase, RelatedArticles (CodeSearch).

@min-width-breakpoint-desktop: 1000px;

Wider desktop breakpoint.
Currently used (as @width-breakpoint-desktop-wide) in Vector. Extensions UploadWizard/MediaUploader (CodeSearch). As @large in Flow defined 6 years ago.

@min-width-breakpoint-desktop-wide: 1200px;

Extra wide desktop breakpoint.
Defined 6 years ago in Flow as @xlarge. Not in use anywhere.

@min-width-breakpoint-desktop-extrawide: 2000px;

Additional data point
[[ https://codesearch.wmcloud.org/things/?q=%40media&i=nope&files=&excludeFiles=&repos= | Codesearch after @media ]]

NOTE: these breakpoints will be documented as legacy and we will create new breakpoints that fits better with the most used screens currently.
Most used screens during the last year:

Visit this web for more info.

Desktop:

  • 1920x1080 (22.33%)
  • 1366x768 (18.1%)
  • 1536x864 (10.78%)
  • 1280x720 (6.13%)
  • 1440x900 (5.98%)
  • 1600x900 (3.45%)

Tablet:

  • 768x1024 (33.71%)
  • 810x1080 (6.76%)
  • 1280x800 (6.63%)
  • 800x1280 (5.84%)
  • 601x962 (4.8%)
  • 962x601 (3.15%)

Mobile:

  • 360x800 (8.83%)
  • 414x896 (6.48%)
  • 360x640 (5.69%)
  • 390x844 (5.33%)
  • 412x915 (4.75%)
  • 360x780 (4.21%)

Developers notes

As the latest proposal changes two currently used breakpoints:
720 => 768
2000 => 1920
It seems reasonable to amend former with a workaround token as it seems possibly impactful, and latter by just using the new breakpoint value. Given how low usage of 2000 in our current codebase is and how small the differences would be projected.
It might be a helpful path forward, that we've defined breakpoint tokens so far with width, while in Codex and the future we're aiming for min-width/max-width.

Figma

Figma spec sheet with proposal here.

Acceptance criteria (or Done)

Design:

  • Create Figma spec sheet documenting our breakpoints
  • Add breakpoints in our Figma library

Code:

  • Document breakpoints in Codex demo (we could add a table like this)
  • Implement breakpoints in Codex

Event Timeline

Change 776007 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] docs: Simplify breakpoint documenting sentences.

https://gerrit.wikimedia.org/r/776007

Change 776007 merged by jenkins-bot:

[design/codex@main] docs: Simplify breakpoint documenting sentences.

https://gerrit.wikimedia.org/r/776007

I've been working in the Grids & Layouts task T298198 and I created this proposal based on our current breakpoints. Since breakpoints and grids are related, I have some questions about the breakpoints added in the task description:

  1. Would it be possible to update our current breakpoints? We could create more common sizes breakpoints like the following ones (e.g. 1440px - 1024px - 768px - 320px)
  1. If we can't create that new breakpoints, would it possible to mix some of the current breakpoints? 1000 and 1200 are too similar and we could mix them to have the following breakpoints:

@min-width-breakpoint-desktop-extrawide: 2000px
@min-width-breakpoint-desktop~~-wide~~: 1200px
@min-width-breakpoint-desktop: 1000px
@min-width-breakpoint-tablet: 720px
@min-width-breakpoint-mobile: 320px

cc: @Catrope @AnneT @Volker_E

STH triaged this task as Medium priority.May 17 2022, 5:19 PM

From the DST design session today, it makes most sense from a production perspective to mark a breakpoint like @min-width-breakpoint-desktop: 1000px as legacy outside of our token scale.
And test several more application use cases with affected products using the current 1000px token.

bmartinezcalvo added a subscriber: alexhollender_WMF.

I've worked on this new breakpoints proposal adding the following:

  • New breakpoints sizes: based on the most used screen sizes today
    • 1920px (max)
    • 1366px
    • 768px
    • 320px (min)
  • Legacy breakpoints: our current breakpoints
    • 2000px (max)
    • 1200px
    • 1000px
    • 720px
    • 320px (min)

About new breakpoints, I've created them based on the most used screens (here where you can find the most used screens today). So, I proposed breakpoints from 320px (the smallest screen) to 1920px, and we will apply a 1514px max-width content for our grids in this other task T298198.

👁 Here you can view the Figma file with the new breakpoints proposal.

NOTE: @alexhollender_WMF we need to know if 1200px and 1000px would have impact in DIP since in this proposal I've documented them as legacy.
NOTE: @alexhollender_WMF we need to know if 1200px and 1000px would have impact in DIP since in this proposal I've documented them as legacy.
  • we are currently using the 1200px breakpoint in order to reduce the size and spacing around the table of contents, so that the article can take up more space at that smaller size
  • we are currently using the 1000px breakpoint in order to hide the table of contents

Vector, MediaUploader, UploadWizard and one community skin, StarCitizenTools / mediawiki-skins-Citizen are the only ones using 1200px widely.

  • we are currently using the 1200px breakpoint in order to reduce the size and spacing around the table of contents, so that the article can take up more space at that smaller size
  • we are currently using the 1000px breakpoint in order to hide the table of contents

As we need to cover the 1000px and 1200px breakpoints because of DI requirements, I've worked in this new Figma proposal also based in some of the most used screens worldwide.

1920px breakpoint-XL

Chosen as the highest breakpoint since 1920x1080px it's the most used screen size on desktop devices (21.69%).

1366px breakpoint-L

Chosen since 1366x768px it's currently the 2nd most used screen size on desktop devices (18.42%).

1200px breakpoint-M

Although one of the most used screens is 1280px, it was too similar to the previous breakpoint 1366px. For this reason I think it makes sense to use 1200px instead to be able to cover a wider range of screens and layouts.

Captura de Pantalla 2022-06-10 a las 11.53.21.png (1×1 px, 560 KB)

In the case of 1024px, I tested it but it was too far from 1366px, so there was too wide a range between 1366-1024px and possible behaviors with the layout couldn't be covered, such as the left panel layout in a 1200px screen where the breakpoint-L 1366px would be insufficient since the ToC or left panel would be too narrow.

Captura de Pantalla 2022-06-10 a las 11.52.06.png (1×2 px, 1 MB)

768px breakpoint-S

Chosen since 768x1024px is the most used screen size on tablet devices (34.72%).

320px breakpoint-XS

We will use 320px for the smallest breakpoint since it’s the smallest screen available and we need to cover it.

NOTE: Regarding our current breakpoints, we'll keep them as legacy.

@Volker_E as this proposal was discussed yesterday during our DS design sync and we agreed to move forward with it, I move it to Ready for Development and leave it without assignment so you can assign it to you when you are prepared to start with it. In this task we will cover just the breakpoints (grids&layouts will be worked in T298198, where we'll try to cover all different product and layout use cases).

I'm a big proponent of the agreed on proposal, I think that it's very solid and while hold for major parts.

One note on the naming, while the t-shirt scale makes sense in a number of other token categories, I'd pledge to use mobile, tablet, desktop, desktop-wide and desktop-extrawide or similar.
It's really hard to apply those and keep the abstraction in head on this specifically unchanging category. Thoughts @bmartinezcalvo and @Sarai-WMDE…?

Volker_E renamed this task from [Design] Decide on CSS breakpoints for the design system to Decide on CSS breakpoints for the design system.Sat, Jun 11, 6:17 AM
Volker_E added a project: Design.

I'm a big proponent of the agreed on proposal, I think that it's very solid and while hold for major parts.

One note on the naming, while the t-shirt scale makes sense in a number of other token categories, I'd pledge to use mobile, tablet, desktop, desktop-wide and desktop-extrawide or similar.
It's really hard to apply those and keep the abstraction in head on this specifically unchanging category. Thoughts @bmartinezcalvo and @Sarai-WMDE…?

I don't thing using the name of the devices in the token name is the best solution since some of them works for more than one device, e.g. breakpoint-desktop would work for both small desktop screens and landscape tablets.

Instead of using t-shirt names (I used them to have a more short names and @Sarai-WMDE used them too for text size) we could use instead these other names we use in other tokens like shadows:

  • Extra Large
  • Large
  • Medium
  • Small
  • Extra Small

(It's the same than t-shirt names but with a more large name)

I move the task to Design Review since I need to collect feedback from more designers to check if our new breakpoints proposal fits well in all their projects.

Hi @bmartinezcalvo, thanks for the ping for feedback. I mostly agree with this proposal and it fits in with the 3 layouts we use on the Growth Desktop version of the homepage (see this task T258005 for reference to the responsive breakpoints we have set, and demo the page live at testwiki at Special:Homepage).

The one part that seems odd is the breakpoint-M (1200px) and breakpoint-L(1366px) sizes being quite close together to not make a material difference, and I would suggest either removing one, or reconsider the sizes with trending breakpoints in mind, so that perhaps we have Large at closer to 1536px. By trending, I mean if zooming out on the last 5 years of the statcounter site, the 1536x864 is moving higher, whilst the 1366x768 is moving down:

image.png (1×2 px, 550 KB)

Having a set of reference sizes is really useful for designers, especially when based on common used sizes. What is not clear to me is that the breakpoints should match exactly those reference sizes.

Defining breakpoints creates a set of ranges of sizes in which the design layout will be optimized for those sizes. An aspect that may be problematic is to define the breakpoints in a way that leaves the reference sizes at the very extreme of the ranges. This means that sizes that are very close to a reference size can get a design that is less optimized for them. For example, 1920px wide screens seem to be the most common desktop size based on the data above and is the reference size for the XL size, however a user that has a browser window that is not full-width (e.g., 1910px) will get the L version of the design which was optimized for a smaller L size (1366px).

These variations in sizes can exist for different reasons such as window size being different (smaller) than screen size or device diversity.

I think it may be more useful to have the reference sizes more centered in the ranges the breakpoints define. In that way when designing for a reference size, devices in the same category (slightly larger or smaller than the reference) will get the experience designed for their category. There is an article covering this idea in more length.

Based on last comments from @Pginer-WMF and @RHo I've been working on a new proposal aligning the breakpoints not with the right value of the most used screens but using these most used screen sizes as midpoint of each breakpoint (as explained in in this article sent by @Pginer-WMF ).

The breakpoints based on the midpoints of these most used screen sizes would be:

  • breakpoint-L 1680px and more
  • breakpoint-M 1120px - 1799px
  • breakpoint -S 640px - 1119px
  • breakpoint-XS 320px - 639px

{F35258903}

With this new proposal where the most used screens are at the midpoint of each breakpoint (view here):
  • We cover more screen sizes with fewer breakpoints. In this proposal we use 4 breakpoints while in the previous proposal we used 5 breakpoints (the 5 one was used for the 1200px one).
  • We cover a larger number of screen sizes as each breakpoint covers several important screen sizes. Also, the most used screens have been tested here and we can view that all them are well covered with these breakpoints.
  • We don't have very approximate breakpoints (as we had in the previous proposal @RHo where breakpoint-L and breakpoint-M were so close)
  • We cover important use cases as the ToC one @alexhollender_WMF (in 1280px screens we would use the breakpoint-M and the ToC would be a bit narrow but I think it could work)

{F35258981}

NOTE: as in the previous proposal, in this proposal we will have these new breakpoints but we'll keep our current breakpoints as legacy.

Thanks @bmartinezcalvo, this latest proposal with four breakpoints looks good to me!
Though I think there is a typo on breakpoint-M - I assume the range should be 1120px to 1679px (not 1799px as it is currently in the mock and figma)... is that right?

Thanks @bmartinezcalvo, this latest proposal with four breakpoints looks good to me!
Though I think there is a typo on breakpoint-M - I assume the range should be 1120px to 1679px (not 1799px as it is currently in the mock and figma)... is that right?

@RHo oh yes, it was a mistake. Updated with 1679px. Thank you Rita!

{F35265198}