- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
The width that inherits settings from both neighbours and is verified against neither — and it is not only tablets that land there.
Tablet view in a page builder: the width nobody checks
Most builders offer three views — desktop, tablet, mobile — and most people use two. The tablet view is opened once during a build, looks approximately right, and is never returned to. It is also the width where the largest number of layout defects hide, because it is the one that inherits settings from both neighbours and is verified against neither.
The traffic argument for caring is weaker than it used to be, and it is not the main one. The reason to check tablet is that it is not only tablets: the same rules apply to a large phone in landscape, a small laptop, a browser window that is not maximised, and a page opened in a split screen. Those together are not a rounding error.
How inheritance actually works
| Where you set it | What inherits it | Consequence |
|---|---|---|
| Desktop | Tablet and mobile, unless overridden | A desktop change silently reaches both smaller views |
| Tablet | Usually mobile as well | A tablet fix can change the phone unexpectedly |
| Mobile | Nothing below it | Safe to adjust, and often where all the fixing happens |
That middle row is the one that surprises people. Adjusting a value at tablet in most builders sets it for every width at or below tablet, so a change made to fix an iPad also lands on every phone. It is the reason a page that was correct on mobile stops being correct after someone “just fixed the tablet view”.
The practical rule is to set as much as possible at desktop, override at mobile where the layout genuinely differs, and touch tablet only when neither of those produces an acceptable result. Every tablet-specific override is a value that has to be maintained in three places instead of one.
What actually breaks at this width
- Three-column layouts. Three columns are comfortable on a desktop and cramped on a tablet, where each becomes too narrow to read. Two rows of two, or a two-plus-one arrangement, is usually better than either three columns or a full stack.
- Font sizes set for desktop. A heading sized for a wide screen wraps awkwardly at tablet, often into a single orphaned word.
- Fixed-width elements. Anything with an absolute width overflows or leaves a strange gap. This is the most common cause of the page scrolling sideways at this width and nowhere else.
- Sticky bars. A fixed element sized for a desktop takes a disproportionate share of a tablet screen — one of the trade-offs in sticky header behaviour and height.
- Hidden elements. A visibility rule set for “mobile” may or may not include tablet, depending on the builder, so something intended to disappear on a phone can remain here or vanish unexpectedly; the decision framework is in hiding an element on mobile.
- Embedded forms. Frames sized against a desktop width clip or leave dead space, which is the mechanism behind why an embedded frame clips.
The elements worth opening individually
Anything that reflows on a proportion of the width deserves a look. A wide the progress bar element either wraps or shrinks; an the accordion FAQ element with long headings does the same. Buttons are worth checking because a button that fits neatly on both neighbours can wrap at the intermediate width, and what the submit button should say matters less when half of it is on the second line.
Images and their crops shift too. A hero that centres its subject at desktop can crop it out at tablet, and the loading strategy from lazy loading funnel images may mark a different image as the first-screen one at this width, since the fold sits somewhere else.
The column ordering question is the same one as on a phone, just less extreme: which column comes first when they stack, and whether the important content is still above the action. That is the ground covered in how a phone stacks your columns, and tablet is where partial stacking makes the answer least obvious.
Testing it without a tablet
You do not need the device. Resize a desktop browser window slowly from wide to narrow and watch where the layout changes — every point where something jumps is a breakpoint, and the awkward widths are always just either side of one. That sweep takes a minute and finds more than opening the builder’s tablet preview, which renders an idealised width rather than the range.
Check landscape as well as portrait, since a tablet in landscape is close to a small laptop and often falls into the desktop rules with too little room for them.
Then load the real page rather than the preview. A builder’s internal preview approximates the width and does not always run the same code, and a page that looks correct in the editor and wrong in a browser is common enough to be worth assuming until checked.
Where the defects come from
Most tablet problems arrive rather than being created. A section copied from another page or pulled out of a shared library brings its overrides with it, and those were set against a different design — one of the reasons a saved section needs verifying at every width rather than the one you built it in, as saving a section to a library argues. Pages duplicated between accounts carry the same baggage, which is the general problem in what moves and what breaks on import.
Keep the number of overrides small for the same reason a small library is better than a large one: every per-width value is another thing that can be wrong, and a page with few of them behaves predictably as the window changes. That also tends to be the lighter page, which does no harm to the measurements in what a page speed score measures.
Frequently Asked Questions
Is the tablet view still worth checking?
Yes, and not mainly because of tablets. The same rules apply to a large phone in landscape, a small laptop, a browser window that is not maximised, and a page in a split screen. Together those are not a rounding error.
How does inheritance work between the views?
Desktop values flow down to tablet and mobile unless overridden, and in most builders a value set at tablet also applies to mobile. That is why a page which was correct on a phone stops being correct after someone adjusts the tablet view.
Where should layout values be set?
As much as possible at desktop, with overrides at mobile where the layout genuinely differs, and tablet touched only when neither produces an acceptable result. Every tablet-specific override is a value to maintain in three places rather than one.
What breaks most often at tablet width?
Three-column layouts that become too narrow to read, headings sized for a wide screen that wrap into an orphaned word, and fixed-width elements that overflow — the usual cause of a page scrolling sideways at this width and nowhere else.
How can tablet be tested without a tablet?
Resize a desktop browser window slowly from wide to narrow and watch where the layout jumps. Every jump is a breakpoint and the awkward widths sit just either side of one. That sweep finds more than the builder’s tablet preview, which renders one idealised width.
Why do tablet defects appear in pages nobody edited?
Because they arrive with copied content. A section pulled from a shared library or duplicated from another page brings its per-width overrides with it, and those were set against a different design.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.