Given displays from which we access the web are becoming bigger, Webflow's breakpoint approach has become "tablet-first" instead of desktop-first. Although I'm a confessed Webflower and a believer on this platform, this article addresses the main frustrations of working with Webflow's breakpoints.
In Webflow, the desktop-first approach has always prevailed over mobile-first. The difference between these two is that the former prioritizes design and implementation for desktop displays, making adjustments for smaller devices later in the process. While the latter is the opposite approach, where the process starts at the smallest size and then it is adapted for larger displays. This second approach forces us to work with the strictly required. Given the scarce physical space in mobile devices, this approach constantly questions the significance of including or not certain information and/or elements. It comes to creating a mobile experience with the minimum required, leaving the secondary information and accessory elements for bigger displays.
With that in mind, if mobile-first is the appropriate approach, why we, Webflow and people from the design world, keep pursuing a desktop-first approach in our sites? For the same reason we ask for dessert when it looks like there is no more space left. To delight ourselves.
When we see final mockups in desktop version, we enjoy it in all its glory, asymmetric layouts, decorative elements that scape the expected visual flow, animations triggered by the pointer position... Resources that in a mobile format are not viable.
Now that we've touched base on mobile and desktop-first approaches, I'm going to talk about how Webflow tackles breakpoints.
The way we work with breakpoints in Webflow has had little change since the early days of the platform. We've always had 4 breakpoints
This way, primary styles are defined on the base breakpoint (desktop) and, when needed, styles are updated for smaller breakpoints.
I have no idea where the 992px value comes from, but it always felt small, even when I started using the platform back in 2014. It doesn't mean that I was creating my designs at 992px but, once in Webflow, I needed to make sure that the implementation wasn't looking bad at the mentioned width. It is worth mentioning that, even then, design mock-ups were normally delivered at 1440px.
With the advent of bigger displays, Webflow understood (too late) that we couldn't keep working with a set of breakpoints that intended the same styles for a 1920px display that for a 992px one.
Thus three new breakpoints made they appearance. These breakpoints define the following ranges:
These three new breakpoints, unlike the existing ones, are nameless and optional.
We need to keep in mind that with this new addition, the base breakpoint keep the same lower value: 992px. The upper limit will depend on which breakpoints we choose to make available. For example, if we turn on the 1440px, the base breakpoint will go from 992 to 1440px.
Here is where we arrive to the main problem with Webflow breakpoints. What it was a desktop-first approach, where we define our main styles for large displays and then updating those styles for smaller devices, now looses its essence by the time we add any of the new larger breakpoints.
Now we can't work desktop-first, even less mobile-first —that was out of the debate since Webflow's launch—. What we have now is a "tablet-first" approach (I don't know if the term exists but it works perfectly for this scenario). The problems with the base and larger breakpoints are two.
On the first place, we need to think in two directions, meaning that our process in Webflow is less "clean". We need to structure our layouts in the base breakpoint in a way that, not only helps our responsive work for smaller widths, but makes sense for the larger breakpoints we decide to activate. Hence the term "tablet-first", since we are defining our layouts from a middle point. It would be much more logical to build all the way up from mobile or vice versa, all the way down from the largest breakpoint.
Our second problem is the width range at which our base breakpoint operates, specially at the lower end. Depending on which of the breakpoints have been activated, the upper limit of our base breakpoint will vary. But the lower limit doesn't change, being 992px. ¿Does Webflow think that people are accessing the web from 992px width laptops? It is hard to believe that. This situation doubles on the idea of calling Webflow a "tablet-first" platform. The lower limit of the base breakpoint it is closer to a tablet device than it is to a desktop or laptop display. In fact, the number of tablet devices with resolutions between 992 and 1280px is five times bigger than laptops on this same range.
Let me go through a normal process of building a new site in Webflow to illustrate how counterintuitive are Webflow breakpoints.
It's important to keep in mind that you should never ever start working on a larger breakpoint without defining your base styles. The same way you don't start working on the tablet view. If you do this, you will end up with a base breakpoint with no styles at all. It will look like those sites you visit where, mysteriously, the css file doesn't load.
As mentioned above, design mock-ups are normally handed-off on a 1440px art board. If you are lucky enough to start from a blank project, with no new breakpoints added, you can implement straight-away on the base breakpoint with your canvas set at 1440px or bigger. On this scenario, your base breakpoint goes from 992px all the way up.
You finish your first section and start playing with the canvas' width to check everything behaves as expected. As you go down to the base breakpoint lower limit —992px—, you can see how elements are too tight.
At this point, some of you would say I could play with the flex-basis value and the shrink and grow properties without having to add an extra breakpoint. You are right but this solution is not a general one and you most likely need to add new breakpoints if you want your site to look good on the lower end of the base breakpoint.
For the sake of what I'm trying to illustrate, I will add the smallest of the three larger breakpoints. Now our base breakpoint goes from 992 up to 1280px. This way we can loosen that tightness in the redefined base breakpoint.
Great! Now I have my layout looking good at 992px with the five cards sitting in two rows. But wait! Because I updated the styles properties in the base breakpoint, I changed how I want this section to behave in the larger breakpoint as well. I need to go back to my 1440px width and reapply the styles that allow a single row for my cards.
If I'm working on a single page site, this double work of reapplying styles in larger breakpoints it is not that bad. But this workflow is totally broken when you are working a on multi page project.
Let's say now that the client is handing-off 1920px mock-ups. They work on big displays and like to delight themselves with their work. You are an experienced Webflow dev and have done your homework creating a boilerplate template. With a couple of clicks you have all of your foundational stuff ready to go. For reasons that serve your way of working, this starting template has the 1280px turned on. Now your scenario is even worse. You have to start implementing at 1280px as it was 1920px. This will emerge tons of inconsistencies because a 1920px mock-up will almost never look good at 1280px or lower. Once you are able to manage all these inconsistencies, you can turn on the 1920 breakpoint and finally, override the base properties to create a faithful implementation of the designs given.
It is hard to understand why a tool like Webflow, that is empowering people to build for the web and revolutionizing how sites are built, has this important constraints when it comes to working with breakpoints.
I'm sure that breakpoints, given they are a fundamental part of the web development process, have a deep implication on different parts of the tool. The engine that creates the CSS from the visually applied properties in the styles panel for example; or the breakpoint-based interactions to name a couple. This makes reformulating the breakpoints in Webflow a major project.
I would say Webflow never paid proper attention to this important part of the responsive web, and when they realized they needed to address the issue of developing for larger screens, there was no time nor resources to come with a proper solution. That's why Webflow released the larger breakpoints as something that "works" on top of what existed. It looks like the objective was to give new breakpoints without changing what existed. In my eyes, the larger breakpoints solution was addressed with Webflow's engineering team in the center and not us, the final users.
Even the larger breakpoints have not been added to the per-breakpoint module in the interaction panel after more than one year from their release. This might point us that even Webflow doesn't believe on this solution and they will overhaul the breakpoint functionality in the (near) future. People would say at this point that I'm a dreamer.
With this scenario, it would be great to see an improvement on how Webflow breakpoints work. Giving us a more flexible to target different display widths. There are a lot of suggestions around this topic, but the main one for me would be to ability to choose which of the provided breakpoints is my base. Said in other word, decide if I want to work mobile-first, desktop-first or tablet-first.
¿Do you suffer from headaches when working with breakpoints in Webflow? ¿What are your main pain points when trying to adapt your project into different widths? You can follow the conversation with your comments on Linkedin, Twitter or Facebook.