Breakpoints in Webflow let us design not just
for desktop computers that match a single display size, but for all kinds of devices
in both directions. That's because styles cascade down to smaller
devices, and up to larger displays. We're going to cover some of the basic concepts
involving breakpoints, and we’ll cover some advanced stuff, too. We’ll do style and layout (as it relates
to breakpoints), how to add additional, larger breakpoints, we'll talk about how you can
preview what your design will look like on a much, much larger display without having
to go test that design on a much, much larger display. We’ll cover how to override styles, how
to clear styles, how to test not just responsiveness but fluidity in your design, and that's it. Let's start with style and layout. And we'll start on the base breakpoint. Changes here (on the base breakpoint) will
affect all devices — all breakpoints by default. Here’s how. When you design something on your base breakpoint? By default, all your styles (your layouts)
pass down to smaller devices. The heading here is the same size on all devices. That's expected. When you make a change? Let's make a change to this heading style...we'll
choose a different font size...maybe closer to 60 pixels. One immediate thing to notice: the label for
that property (the font size)? It's now blue. That indicates there's been a change to a
property (the font size) on our current view (our base breakpoint). And if we check out the other views? (The other breakpoints?) That change was reflected in the smaller devices. In fact, let’s go back to tablet here for
example, and with our heading selected, we can just click that label (notice how it's
more of an amber color)...we can see that we're getting that 60-pixel font size from
our base breakpoint (from our default desktop breakpoint). But here's where breakpoints come in handy. Maybe that change looks fine in tablet, but
it's a bit cramped in mobile landscape. If we make the change there? On mobile landscape? If we change to something more like 40 pixels? We know that label, the moment we made a change
turned blue (that indicates there's a value — our font size — set on this breakpoint
— on tablet). And we already know that change will pass
down towards smaller devices, but check this out: that 40-pixel font size? It didn't affect tablet. And it didn't affect our base breakpoint. Both of those are still 60. Changes to style and layout always originate
here at the base breakpoint, and they cascade (changes always pass down to smaller devices...and
they pass up to larger devices). And this isn't just font size. Let's look at our section. It might make more sense, maybe starting on
mobile landscape, to remove some of that extra padding on our section here. Let's drop to something...maybe closer to
20. (We’re holding down option or alt and dragging
to adjust both sides at once.) And we can do the same with our other section. It has a lot of padding by default, let's
reduce that (let's drop the padding so we can really respect the limited screen real
estate on a mobile device). And everyone’s thinking the same thing:
it doesn’t look great with the text running up against the edges. That’s okay. Because breakpoints. Now. Saying “because breakpoints” doesn’t
fix this. In fact, outside of the hopefully-short-term
colloquial removal of “of” from the English language, “because breakpoints” adds no
value at all. But here’s what does add value: we can select
our container (we have a plain, default container inside our sections)... and we can add some
padding here on mobile landscape. Maybe 10 pixels on each side. And not only does that fix the container,
but it automatically generated a class. (We can see in our selector field that a class
named Container was automatically created.) But because web design is built on CSS and
classes are magic, we can select any other containers (this is any container on this
page, in fact, anywhere in our project), and apply the same container class to those. We’ll also do this on the container in our
navigation (in our navbar a the top). And it’ll inherit (anything container we
apply that class to will inherit) the padding we added on the left and right. But what about our grid at the bottom? Things start getting pretty cramped here,
but they're also a bit close on tablet. In tablet, let's go in to edit our grid. Right now it's three columns (it has three)...so
let's remove one of them. Let's switch down to mobile landscape? We can change the font size here later...but
let’s look at mobile portrait. And 2-across is definitely a bit much for
such a narrow display. Let's change that (let's go in and make our
grid — instead of two columns, let's make it one column only). And because changes cascade down, if we go
back to mobile landscape? We still have two columns there. In fact, let’s click the amber indicator
for columns, and we can see, we’re inheriting the 2-column design from tablet...which we
did just a few moments ago. Let’s close out of editing our grid. And let’s change the font sizes a bit. Our top one (our main heading), let’s type
in a different value like 30. Same thing for the subheading — let’s
select that and make it maybe 20? Again, this will be on a mobile device, we
might want to reduce that margin (that space underneath the text to something a bit lower
like 30. And let’s do the font size on the lower
text, too. We can make these headings have a slightly
smaller font size — maybe something closer to 20 pixels. And we can do the text underneath (the little
paragraphs underneath the headings). Let’s make those 15 pixels). All these changes, as we know, cascaded down
to mobile portrait. And just like that. We optimized a design that started on desktop
— but we made it work for tablet, mobile landscape, mobile portrait, and NES. That's cascading in one direction...what about
larger devices? Well, if we go and add a breakpoint (let's
add our 1280 breakpoint which is good for the MacBook Air or the 13" MacBook Pro). On larger devices, changes do the same thing...but
they cascade up. So if we go back to our base breakpoint and
grab our heading? If we go into our color picker and make the
text color something like pink? That color change will pass down...we can
check it on tablet, mobile landscape, all the way to mobile portrait. And it cascades up, too. Our 1280 breakpoint has a pink heading. In fact, let's look at the property label
(we see it's amber because that value — that pink color is coming from our base desktop
breakpoint). Fortunately, for our eyes and our sanity,
there's an undo button. But what if we make a change here in the larger
breakpoint (1280)? That change will affect even larger breakpoints. Let's increase the size (the maximum width)
of our container to something more like 1200. And since we have that same class? (Our Container class applied to the container
in the bottom section and in the navbar on the top?) Changes affected those containers, too. Again, if we go back to our base breakpoint,
it's still the same as we left it...changes cascade from the base breakpoint towards smaller
AND larger devices. But that also means changes to our 1280 breakpoint? They'll affect even larger sizes, too. Now. A lot of people might stop here. That's okay. Larger breakpoints are entirely optional (in
fact, that's why they don't show up in a new project by default). For us, let's explore by adding another one
— this is our 1440 breakpoint. This is most larger laptop displays like the
16-inch MacBook Pro, the Surface Book when you're in landscape... And maybe here it makes more sense to widen
the container even more. It's still 1200 pixels from our previous breakpoint
(and we can confirm this with the container selected by clicking into the amber indicator
(we're inheriting the 1200 max width from our 1280 breakpoint). But maybe we can do something different on
this view — like 1360 here. Again, this can be whatever you want it to
be. Notice, of course, it turned blue because
we've added an override (we've added a new property to this view — to our 1440 breakpoint). That’s good for now. Finally, let's add 1920. This is the 21" or 27" iMac, the Pro Display
XDR, most 1080p or 4K monitors by default — and here we're going to do a couple of
things. But first, we need to move to scaling. And here’s why: A second ago, we showed our second-largest
breakpoint (1440). We said this was the breakpoint for the 16"
MacBook Pro. And in Apple's own tech specs, they list the
pixel width on that display as 3,072. So by that math, the 16" MacBook Pro should
be in the biggest breakpoint, way beyond our largest breakpoint (1920). So why do we say it's in the second-largest
breakpoint? And the answer is this: for most users on
hi-DPI or Retina displays, whether they're using macOS or Windows or Linux...they'll
use scaling. Most manufacturers have this on by default. And it means the display is still using all
the pixels on your screen, but assets are smoothly scaled up. Apple does this really well in their display
settings — as you hover over each scaling option, they use the language “looks like”
to describe that even though you’re using all the pixels on the screen, things will
be scaled to look like those resolutions. So. Do you have to do the math? Do you have to reference page after page after
page of notes different display (different devices)? You can...but we also have common device widths
right at the bottom. Let’s go back over to our 1440 breakpoint. If we want to preview what things might look
like on a MacBook Air or a 13” MacBook Pro? We can just grab towards the edge of the display,
resize our canvas, and we can see — there's the 13” MacBook Pro. But it’s not just on this breakpoint. Let’s go down to mobile portrait as another
example. We can do the same thing — we can grab the
edge of the canvas, and we can drag — we can preview what the design looks like on
different devices, in this case, an iPhone 11 Pro. But scaling solves another challenge. If we're on a 16" MacBook Pro? And we want to design for larger displays? How do we make that happen? Well, here we are on a 16" MacBook Pro. And all we do? Is click the breakpoint. The canvas will automatically scale to preview
what the design will look like at a width of 1920. You can still select, you can edit — you
can do everything you normally do, but the elements — the whole page will be scaled. We can even go beyond this. Want to see what it looks like on a 27" iMac? On our MacBook Pro here, let's go in, and
type 2560. That's what it looks like on a much larger
screen. In fact, we can go over to the edge (we'll
hover over until the canvas edges turn blue), and we can click and drag to simulate an even
larger canvas — everything will automatically scale. In fact, let’s finish this part on the MacBook
Pro. At any time, we can go in and type a value
(type a width into canvas settings). We’ll go back to 1920. And. Things are still scaled, but that’s okay. Since we have a lot more space, let's go in
and set the container width to something even wider. Again, we set it to 1360 on our previous breakpoint,
let's set it to 1700 here on our largest breakpoint. And with all that extra room, let's try something
different. Let's go into our grid. And instead of 3-across, let's add a few columns
and make this 6-across. (By the way, if you're not using CSS grid,
it's magical. Except it's not magic; it's CSS). And just like that, we've created another
change that will affect all displays that are 1920 or larger. (The change didn't affect the other breakpoints,
because, as we know, changes cascade upwards to larger devices, just like changes cascade
downwards to smaller devices.) That’s scaling. What about overriding styles? Well, we've been covering cascading, but something
to note here — this is a pretty common pattern. Let's say we're on tablet and we change the
button color. (With the button selected, we're changing
its background color.) And because our tablet breakpoint is the only
place we changed the color, that means it passes down to smaller devices, and it does
that because no button color has been set on mobile landscape or mobile portrait. But how do we override that change? On mobile landscape, let's change the color
again. (Let's just change the background color to
something obviously different.) And when we do? The result, of course, is that the tablet
button color is just as we left it, but we’ve overridden that color on mobile landscape. And because changes cascade in that direction,
mobile portrait has our new color, too. In fact, that's how overriding works — that's
the whole point of breakpoints. You start on the base desktop breakpoint,
and make a series of overrides on the other devices — those overrides pass down to smaller
screens, and they pass up to larger screens. That's overriding things on different breakpoints. What about clearing things? Let's get one thing out of the way. Everything we're talking about applies to
style changes (and changes to our layout). If we delete something? Even if we're only editing in this view (this
breakpoint)? That thing is deleted from the page entirely. And that element is gone from the document
(it’s not visible on any view). Let’s undo and get our heading back. And the second thing here is this: if we manually
move it in the document order (over here in the navigator, if we move the heading, that
change (that move) will apply to all views — all breakpoints, unless we've done something
to manually override that change with styling). Let’s undo that change so the heading comes
first. But when we want to clear (or reset) a style? Maybe we don't love our changes to the button
color? On tablet, for instance, we might want to
remove that override (remove that changed background color). We just click in...and reset. If we go in, we can see that background color
is now coming from our base (our desktop breakpoint). Did that destroy the rest of our work on the
other views? Not at all — we still have the styling changes
we made on mobile landscape. Same thing here. We can remove that (we can reset that style),
and when we do, we remove the color we added before. What about mobile portrait? Well, since we reset the changes we made in
tablet and mobile landscape, the button’s styling (we can click in and see this) — it’s
passing all the way down from our base desktop breakpoint. And that's the main idea. When we make style changes on different breakpoints,
they apply to those breakpoints. And, like we’ve said a bunch of times, styles
cascade down to smaller devices and up to larger ones. But because there are a thousand things we
can change and control, it really helps to click through and see how your design looks...and
functions on each display. And that leads us to testing responsiveness
and fluidity. Responsiveness is just the idea that stuff
responds to the width of the browser’s viewport. We can click through to see how everything
looks on each breakpoint — and we're able to see our design as it applies to those device
widths. In fact, if we hover over any of our icons
here, we can see the pixel width (that starting range) that each breakpoint affects. But then there's fluidity. These aren't fixed widths at all. In fact, like we showed earlier with MacBook
Pro and the iPhone, you can grab the handle or even the edge of the canvas here — and
click and drag to test how everything's responding. (On each view — each breakpoint — you
can test your design on all widths.) But it gets better. Go into preview mode on the top? And from here, you can click and drag and
it'll automatically switch breakpoints when you hit the end of each device's range. That means you can test to make sure your
design cleanly responds on all display widths — exactly how you want it to respond. And that's it. We covered a lot — that’s because there’s
a lot to cover. But breakpoints are really powerful because
they let us design for lots of devices without needing to redo our work on every single one
of them. So. We covered breakpoint styles and layout, how
to add larger breakpoints, we showed scaling, we talked about how to override styles, how
to clear styles, how to test responsiveness and fluidity, and then we faded to black just
a bit too early.
