Common tablet layout bugs and how to fix them

Some website faults only appear on a tablet. The phone view is fine, the desktop view is fine, and then a client opens the site on an iPad in the showroom and the dropdown menu refuses to open. These tablet layout bugs are frustrating because they sit exactly where teams test least. The good news is that the same handful of problems turn up again and again, and each has a well-known fix.

Here are the most frequent ones, how to recognise them and what a developer should change.

Bug 1: Menus and dropdowns that only open on hover

Symptom: on a tablet, tapping a top-level menu item either does nothing, jumps straight to the parent page without showing the submenu, or opens the submenu for a split second before closing it.

Cause: the dropdown was built with a CSS :hover rule and no alternative. Touch screens have no true hover state. Browsers try to emulate it on first tap, but the behaviour varies and is unreliable, especially when the parent item is also a link.

How to fix it

• Make submenus open on click or tap using a real button, with aria-expanded updated to show whether it is open.
• If the parent item needs its own page, add a separate small toggle button beside the link, or repeat the parent link as the first item inside the submenu.
• Use the hover: hover media feature to add hover-opening only for devices with a precise pointer, so desktop users keep the familiar behaviour.
• Close an open submenu when the user taps outside it or presses Escape on an attached keyboard.

Bug 2: Two columns squeezed until they break

Symptom: in portrait at around 768px, a sidebar and main content sit side by side, but the content column is so narrow that headings wrap on every word, buttons overflow and form fields become unusable.

Cause: the switch from stacked to side-by-side layout was set at a width that suits the design on a large screen, not the actual space the content needs.

How to fix it

Move the breakpoint up so columns only sit side by side when both have enough room, often above 900 or 1000 pixels. Better still, use CSS Grid with a minimum column width, such as minmax(280px, 1fr) with auto-fit, so columns wrap automatically when they would become too thin. Give sidebars a sensible minimum width rather than a percentage that shrinks indefinitely.

Bug 3: Oversized or awkwardly cropped images

Symptom: the hero image fills the entire tablet screen so no text is visible, or a banner cropped for a wide desktop cuts off the product or the person's face on a portrait tablet.

Cause: fixed heights in viewport units, such as height: 100vh, combined with object-fit: cover and no control over the focal point.

How to fix it

• Cap hero heights with a maximum, for example using min() to limit a height to a pixel value or a share of the viewport, whichever is smaller.
• Set object-position so the important part of the photo stays in frame when cropped.
• Where the subject genuinely changes with orientation, supply a differently cropped image through the picture element.
• Check that tablets are not being sent the largest desktop file when a smaller one would look just as sharp.

Bug 4: Layout breaks after rotating the device

Symptom: the page looks right when loaded in portrait, but after rotating to landscape a slider shows half a slide, a sticky element sits in the wrong place or content overlaps. Reloading fixes it.

Cause: JavaScript measured the screen once on page load and set sizes in pixels. When the width changes, nothing recalculates. Carousels and masonry galleries are frequent offenders.

How to fix it

Prefer CSS for layout sizing so the browser reflows automatically. Where scripts must measure, listen for resize events or use a ResizeObserver on the container, and debounce the handler so it does not run dozens of times during rotation. Test by rotating several times in a row, not just once.

Bug 5: Viewport height surprises and sticky elements

Symptom: a full-screen section is slightly taller than the screen, hiding its bottom button behind the browser toolbar, or a sticky header plus a sticky cookie bar leave very little room in landscape.

Cause: on mobile browsers the classic vh unit may not match the visible area, because address bars show and hide as you scroll. Landscape tablets are also short, so stacked sticky bars eat a large share of the height.

How to fix it

Use the newer svh or dvh units, which are designed around the small and dynamic viewport, with a vh fallback for older browsers. Reduce sticky header height on short screens with a height-based media query, and avoid having more than one sticky bar visible at once.

Bug 6: Desktop-sized controls on a touch screen

Symptom: in landscape, the site switches to its desktop layout, and suddenly pagination links, filter checkboxes and close icons are tiny.

Cause: the design assumes anything wider than 1024px is operated by mouse.

How to fix it

Use the pointer: coarse media query to enlarge hit areas whenever the primary input is touch, regardless of screen width. Padding on links and labels increases the tappable area without changing how the page looks.

A routine for catching tablet bugs before customers do

Add a short tablet pass to every release:

1. Open key pages at 768px, 820px and 1024px in browser responsive mode.
2. Repeat on one real tablet in both orientations, rotating mid-page.
3. Tap every menu item with submenus.
4. Fill one form with the on-screen keyboard open.
5. Scroll a full page with any sticky elements visible.

Most of these faults live in shared templates, so fixing them once repairs every page. If your theme makes the fixes hard to apply, our support team can look at the code and advise on the cleanest repair.

Frequently asked questions

Why does my dropdown menu work on desktop but not on iPad?

It most likely relies on hover to open. iPad Safari tries to simulate hover on tap, but the result is inconsistent, especially if the parent item is also a link. Switching to tap-to-open with a proper button solves it.

Does iPadOS load the desktop version of websites?

By default, Safari on recent iPads requests desktop-style pages, and the user agent looks like a Mac. Responsive layouts still adapt to width, but any server-side mobile detection based on user agent may treat iPads as desktops.

How can I test tablet layouts without owning a tablet?

Browser responsive modes let you check widths and simulate touch, which catches most layout issues. Rotation, hover emulation and toolbar behaviour are best confirmed on a real device, even a borrowed one.