Bootcamp
Responsive layout in Bubble: breakpoints, grouping and alignment
Photo by Mahmudul Hasan on Unsplash
Open an A4 PDF on your phone and you will experience the exact problem responsive design solves. You pinch, you scroll sideways, you flip the phone to landscape and squint. The document was made for one fixed size, and your screen is not that size. That is what a non-responsive page feels like on a phone, and with mobile carrying most web traffic, it stopped being forgivable years ago.
Bubble’s responsive engine, released in late 2022 on top of the modern CSS flexbox model, makes fluid layouts genuinely achievable without code. But the engine only rewards builders who understand the ideas underneath it: where breakpoints go, the two responsive strategies, and how container layouts and alignments actually behave. That theory is this article; the build articles for the bootcamp landing page put it into practice.
Breakpoints are the screen widths at which a layout changes to suit different devices: the moment three cards become one column, or a nav bar becomes a hamburger menu. Good breakpoints are decided deliberately, not discovered by accident.
Why layouts learned to move
The web of the 1990s was fixed-width: layouts ran down the page at one size, and a bigger monitor just meant empty space around a design made for someone else’s screen. When smartphones arrived the tools had not caught up, so the mid-2000s standard was a desktop application plus a separate mobile version of the same thing (remember m.facebook.com?). CSS eventually closed the gap with the flexbox model, where elements respond to their contents and the space they are given, and Bubble’s responsive engine sits directly on that capability. The practical consequence: one page that adapts, instead of parallel versions to maintain, provided your containers are structured properly from the start.
The standard breakpoint ranges
These are the present-day standard widths, and Bubble has adopted them as built-in breakpoint variables:
- 320 to 768 pixels (small): mobile phones, and tablets held in portrait.
- 768 to 992 pixels (medium): the next size up, roughly mobile landscape.
- 992 to 1200 pixels: tablets in landscape and very small laptops.
- Above 1200 pixels (extra large): laptops at full screen, desktops, ultra-wide monitors.
A useful anchor: a 1440-pixel design canvas is roughly a 13-inch MacBook with the browser at full screen; and big-monitor users often keep windows at partial widths, so they hit your smaller breakpoints more than you would think.
These numbers are not permanent; they shift as devices change, and Bubble lets you add custom breakpoint variables (say, 860 or 1600) or delete ones you do not use. Either way, fewer deliberate breakpoints beat many reactive ones: define how each element behaves within each range, and the layout stays predictable.
Adaptive versus stacking
There are two responsive strategies, and you will use both.
Adaptive means: between these widths show one version, between those widths show another. You hide or swap content rather than reflowing it. Data-heavy pages do this constantly, dropping lower-priority columns and tertiary options as the window shrinks; losing secondary nav links from a header is the classic case. The implementation is a conditional: wrap the elements in a group (say Group Links), then When Current page width < 900 set This element is visible to no. Generally you will use a breakpoint value in that condition, but occasionally the content inside the group dictates a custom number.
Stacking means the layout reflows. A hero with text on the left and an image on the right brings the image down underneath the text as the width shrinks. Stacking has more variations than it first appears: with three columns, you might stack only the third underneath while the first two stay side by side, and you will usually widen the stacked one so it fills its new row, because a lone column sitting at 60 per cent of the page width looks strange. Stacking is rarely just reordering; it is also adjusting minimum and maximum widths so each arrangement fills its space.
Images deserve a special mention, because one that looks perfect on desktop can fall apart in a narrow layout. The robust approach is to set the image as a group background with crop the image to fit the element size: the group shows whatever portion of the image fits its current dimensions and trims the rest. For that to work, choose images with the focal point in the middle ninth of the frame; a subject in a corner will eventually get trimmed off by some layout.
Mobile-first or desktop-first is a data decision
Mobile-first means designing for the narrowest range (320 to 768) first, then converting that layout up to desktop. TikTok is a clean example: its desktop site is visibly the mobile experience, the content column holding the centre and the extra width spent on sidebars and space. Desktop-first starts wide and adapts down; a financial trading platform designed for ultra-wide monitors, dense with small labels and simultaneous data, prioritises ruthlessly (adaptive) and stacks what remains on a phone.
Which way to go is a data question, not a fashion choice. Instagram famously declined to build a proper iPad app for years, and the traffic stats explain why: even when mobile and desktop split something like 50/50 or 60/40, the tablet share is often three to five per cent. If a company with Instagram’s budget makes that call, it tells you something about priorities.
The deciding factor is the situational context of your users. iAuditor illustrates it well: office staff analyse data on a full-width desktop dashboard with search and filters, while field staff enter data on phones. Those are effectively different screens serving different purposes, and that is fine. Make “which device do you want to use for this feature?” an explicit UX research question rather than an assumption.
On pages: since the new responsive engine, our strong preference is one responsive page per feature, because a second version doubles your maintenance forever. The exception is when mobile and desktop are genuinely two different front ends over the same back end. Equally, you may decide a back-office tool needs no mobile layout at all, because its users are at desks.
Container layouts and alignments
Everything in Bubble is a box, and each container’s container layout defines how the boxes inside it behave. There are four options: Fixed, Align to parent, Row and Column, of which the last three are responsive. Fixed is drawing on paper: what you see is what you get, in x/y coordinates. Intuitive at first, but once you are comfortable with responsive containers it is very hard to go back.
Align to parent divides the parent into nine sections (Bubble calls them nonants) and pins each child to one of them. It suits a signup page where an auth box should sit dead centre at any window size, or a card where something must stick to the bottom edge. Useful to know; rarely used day to day.
Rows and columns do the real work, and the fastest way to learn them is an exercise worth an hour of anyone’s time. Create a page, set its container layout to Row and its width to 1440. Add four 280 × 280 groups, Group A through Group D, each with a loud background colour. Now walk through the six container alignments:
- Left: the groups queue from the left edge, one behind the other.
- Centre: still a row, but the whole queue slides to the middle.
- Right: the queue floats to the right edge.
- Space around: equal space around each element. With these dimensions you get 40 at each edge and 80 between the boxes.
- Space between: the outer elements are pushed hard to the edges and the leftover space is divided equally between: the one to remember for headers and navs, where a logo goes hard left and links hard right.
- Add a column gap of 40: now the spacing between boxes is pinned at 40 regardless of alignment.
That gap setting is the important habit. Use the column and row gaps on the parent instead of scattering 40 pixels of padding here and 20 of margin there: define the behaviour once on the parent, and the children fall into place. The box model maths also becomes legible: four boxes at 280 plus three gaps at 40 is 1240, exactly the 1440 page minus 100 a side.
The row gap applies when items stack downward. If your stacked gap looks bigger than the number you set, check the container for a minimum height: a minimum forces extra space, so the elements no longer define the height. Remove it and the page becomes only as tall as its contents, and the gap reads true. This generalises into one of the most useful rules in Bubble layout: minimums and maximums get in the way more often than they help, so leave them empty unless you have a specific reason.
Column containers mirror all of the above vertically: top, middle and bottom alignment, plus the same space-around, space-between and gap behaviour running down the page.
Tools and testing strategies
- Live in the responsive tab. Drag the width, jump between breakpoints, toggle visibility and states, and read the current page width as you go. It is much faster than previewing, because there is nothing to reload. Test there first; confirm in the browser second.
- Use canvas placeholders. A dynamic expression like
Current date/time formatted as...renders in the editor as a long ugly expression that pushes its box out of shape. Give the element a canvas placeholder (“Monday, Jan 29 2024”) and you design and test against realistic content. The same feature exists for dynamic images. - Remember debug mode adds space at the bottom of a preview. Useful, but check the page without it before judging your footer.
- Test on actual devices, not just the editor, and learn the browser inspect tool.
Then the maintainability habits. Keep settings on parent elements, and where possible on the parent’s style, so children inherit rather than repeat: DRY, don’t repeat yourself. If you catch yourself copy-pasting fully configured container groups, ask which settings can move up. Keep one clean template page and clone from it for new pages, deleting what you do not need; you inherit properly configured outer containers and app-wide consistency for free.
Breakpoint variables complete the picture, because they plug into conditionals. A hero style can carry the conditional When Current page width < Mobile landscape to reduce its left padding, defined once on the style: responsive behaviour maintained centrally, not per element.
Putting it to work on a real page
Here is how the theory lands on the bootcamp’s landing page assignment. The Figma design works on a four-pixel grid, with side margins of 156 on desktop, 40 on tablet and 20 on mobile. Those margins are implemented as padding, because padding sits inside the box: full-width backgrounds still reach the screen edges while content keeps a clean line down both sides.
The page itself is a Column; sections run down it with a consistent row gap, header at the top, footer at the bottom. Each section follows a two-layer pattern:
- Outer section groups: a Row, container alignment centred, fit width to content off (so backgrounds span the full screen), fit height to content on (so content defines the page length), carrying the breakpointed paddings.
- Inner containers: no minimum width or height, zero padding, centred, with a maximum width of 1128 so content never over-stretches on very wide screens. Below 1200 the side paddings do the constraining, so the max only matters up high.
Then each section gets a named strategy before any settings change: the header is adaptive (nav links swap for a hamburger menu, the logo for a compact icon on mobile); the hero stacks its left and right halves; the services cards stack below 768; the testimonials keep their layout and step the typography down; the contact section stacks its fields and details; and the footer stacks and rearranges, moving the social icons above the divider line. Typography shifts at breakpoints too: same hierarchy, smaller sizes.
Try it yourself
Do the four-boxes exercise before building anything real; it makes container alignments intuitive in an hour. Then open a page you have built in the responsive tab and drag it from 320 to 1440. Everywhere it embarrasses you, resist patching the symptom: fix the container, remove stray minimums, set the gaps on the parent, and let the children fall into place.
This skill in the AI era
Responsive implementation is close to free now: modern CSS frameworks, the ones AI tools write fluently, handle the flexbox for you. What has not been automated is the judgement this module teaches: choosing breakpoints on purpose, knowing when to adapt versus stack, and deciding mobile-first from user data rather than habit. When we brief Claude Code on a build, that judgement is the spec and the machine writes the layout code, which is why builders who learned it carried it straight across to AI-assisted development. If you would rather see that division of labour applied to your own product, that is exactly what we do when we build with AI in Sydney.
If this sparked something, let's talk.
No pitch, no pressure — just a conversation about what you're working on.
Let's talkRelated posts
Bootcamp
A simple approach to data modelling
A four-step method for designing a database schema: identify entities, map relationships, choose fields. Taught through the CRM data model built in Bubble.
Bootcamp
Module 5 — Application architecture: pages, states and reusable pieces
Single-page vs multi-page apps, URL parameters, custom states, reusable elements — and a big practical building a main template with an expanding navigation drawer.
Bootcamp
API calls as actions vs data (and the planning checklist)
When to use Bubble API calls as actions versus data sources, a one-to-many auth pattern, and the planning checklist that keeps integrations from failing silently.