CSS transform

Why Does an Offscreen Menu Create Horizontal Scroll?

by

Offscreen menu horizontal scroll usually happens when a hidden mobile menu is pushed outside the viewport with negative offsets, left:100%, right:-280px, translateX(), or an oversized backdrop.

Mobile Menu Overflow Fix

Why does an offscreen menu create horizontal scroll?

An offscreen menu can create horizontal scroll even when it is closed. The menu may look hidden because it sits outside the visible screen, but its box can still contribute to the scrollable width of the page. This is common in mobile navigation, slide-out panels, account drawers, filter sidebars, and cart menus.

The bug usually appears after a developer tries to hide a menu by moving it away from the viewport. A rule like right:-280px or transform:translateX(100%) feels logical because the panel disappears visually. But if the element is still attached to the page in a way that expands the scrollable area, the user gets a sideways page instead of a clean closed menu.

  • Offscreen menu
  • Mobile navigation
  • Horizontal scroll
  • CSS transform

Test the hidden state, not only the open state

Many offscreen menu bugs happen while the menu is closed. Paste the closed menu CSS into a controlled preview and disable the offscreen offset, transform, or fixed width. If the horizontal scrollbar disappears, the hidden menu is not really hidden from the scrollable layout.

Related: Try this in the FrontFixer Live Inspector.

Open Live Inspector

What the bug looks like

The page slides sideways on mobile, often even before the menu is opened.

Why it happens

The menu is hidden by moving it offscreen instead of keeping it inside a safe fixed layer.

What usually fixes it

Use a fixed drawer, safe width, transform-based state, and clip the drawer system intentionally.

Why hiding a menu offscreen is not always safe

A mobile drawer is usually meant to feel like it lives outside the screen until the user taps the menu button. That design pattern is normal. The mistake is treating “outside the visible screen” as the same thing as “not affecting layout.” CSS does not always work that way. A positioned element can be visually outside the viewport and still become part of the scrollable overflow area.

The safest mental model is this: the menu should be a fixed overlay system, not a normal page section that has been shoved to the side. If the drawer belongs to the overlay layer, it should be positioned with position:fixed, bounded by the viewport, and moved with a controlled transform. If the drawer is treated like a normal block inside the document, it is much easier for its width and offset to widen the page.

Do not judge the menu only by whether it is visible. Judge it by whether the page remains the same width when the menu is closed, opening, and open. A clean offscreen menu should not create a horizontal scrollbar in any of those states.

Closed still mattersThe closed state can be the state that creates the scroll bug.
Fixed is usually saferA drawer tied to the viewport is easier to control than one sitting in normal document flow.
Width must be fluidUse min() or max-width so the panel never beats the phone.
Hide with state, not chaosMove the menu predictably and keep the page width stable.
Error 1

The drawer is hidden with a negative right value

This is the classic mobile drawer bug. The menu is positioned on the right side and hidden with a negative value. Visually, the drawer disappears, but the page may still become wider than the screen because the drawer is sitting outside the safe viewport.

Broken code

Negative right 
.mobile-drawer {
  position: absolute;
  top: 0;
  right: -280px;
  width: 280px;
}

Broken visual result

Drawer leaks outside
overflow
Mobile page

The content fits, but the hidden drawer is still outside.

MenuHomeGuidesContact
The drawer is hidden visually, but the right-side leak creates horizontal scroll.

Correct code

Fixed drawer 
.mobile-drawer {
  position: fixed;
  inset: 0 0 0 auto;
  width: min(280px, 86vw);
  transform: translateX(100%);
}

.mobile-drawer.is-open {
  transform: translateX(0);
}

Fixed visual result

Viewport owns drawer
safe
Mobile page

The drawer is controlled by the viewport, not document width.

MenuHomeGuidesContact
Use a fixed drawer with fluid width and transform state instead of a negative page offset.
Error 2

The menu is placed at left:100%

Another common pattern hides the menu by placing its left edge at the end of the parent. That can be fine inside a clipped overlay, but if the element is attached to the document, it may create a full extra panel width beyond the viewport.

Broken code

Left 100% 
.drawer {
  position: absolute;
  left: 100%;
  top: 0;
  width: 260px;
}

Broken visual result

Extra panel width
left:100%
Content area

The hidden drawer begins after the viewport edge.

DrawerProfileSettingsLogout
The menu starts after the page width, then adds its own width on top.

Correct code

Translate inside fixed layer 
.drawer {
  position: fixed;
  right: 0;
  top: 0;
  bottom: 0;
  width: min(260px, 86vw);
  transform: translateX(100%);
}

.drawer.is-open {
  transform: translateX(0);
}

Fixed visual result

No extra document width
stable
Content area

The drawer belongs to an overlay layer and does not widen the page.

DrawerProfileSettingsLogout
The drawer can still slide, but the document width stays unchanged.
Error 3

The backdrop or menu strip is wider than the viewport

Sometimes the drawer is not the only problem. A backdrop, menu strip, or inner navigation row may use 100vw plus padding, a negative right value, or a fixed desktop width. The menu system then creates overflow even if the panel itself seems reasonable.

Broken code

Oversized menu layer 
.menu-backdrop {
  position: fixed;
  inset: 0;
  width: calc(100vw + 70px);
}

.menu-strip {
  position: absolute;
  left: 18px;
  right: -80px;
}

Broken visual result

Backdrop leaks
wide layer
Menu overlay

The overlay layer itself is wider than the screen.

HomeServicesContact
The backdrop and strip create overflow even if the drawer is not visible yet.

Correct code

Bounded overlay 
.menu-backdrop {
  position: fixed;
  inset: 0;
  width: auto;
}

.menu-strip {
  position: absolute;
  left: 18px;
  right: 18px;
  max-width: calc(100% - 36px);
}

Fixed visual result

Overlay is bounded
fits
Menu overlay

The overlay uses the viewport without exceeding it.

HomeServicesContact
Use inset:0 and safe inner spacing instead of widening the overlay manually.
Error 4

The transform distance is based on the wrong box

Transform-based drawers are usually better than negative offsets, but they still need the right containing layer. If the panel is inside a normal page wrapper or has a desktop-sized width, translating it can still leave a visible or scrollable leak. The panel should be sized for the viewport and transformed from a fixed edge.

Broken code

Wrong transform context 
.drawer {
  position: absolute;
  right: 18px;
  width: 320px;
  transform: translateX(82%);
}

Broken visual result

Transform still leaks
translated
Sliding drawer

The drawer is translated from a box that is already too wide.

PanelSearchFiltersApply
A transform is not automatically safe if the drawer width and position are unsafe.

Correct code

Safe transform state 
.drawer {
  position: fixed;
  right: 0;
  top: 0;
  bottom: 0;
  width: min(320px, 88vw);
  transform: translateX(100%);
}

.drawer.is-open {
  transform: translateX(0);
}

Fixed visual result

Transform is controlled
safe
Sliding drawer

The transform belongs to a viewport-sized drawer system.

PanelSearchFiltersApply
Size the drawer safely first, then animate the state with transform.
Premium pattern

A production-minded offscreen menu pattern

A strong offscreen menu keeps the drawer in a fixed overlay layer, uses a fluid width, moves with transform, avoids negative document offsets, locks page interaction intentionally, and never relies on the body hiding horizontal overflow to cover a bad menu state.

Premium code

Safe drawer system 
.drawer-layer {
  position: fixed;
  inset: 0;
  pointer-events: none;
  overflow: clip;
  z-index: 1000;
}

.drawer-layer.is-open {
  pointer-events: auto;
}

.drawer {
  position: absolute;
  inset: 0 0 0 auto;
  width: min(340px, 88vw);
  max-width: 100%;
  transform: translateX(100%);
  transition: transform .22s ease;
}

.drawer-layer.is-open .drawer {
  transform: translateX(0);
}

Premium visual result

Drawer layer, no page leak
premium
Safe drawer layer

The page width stays stable while the drawer opens and closes.

Fixed layer
Fluid drawer
Transform state
No overflow
MenuHomeFixesTools
Premium drawer CSS does not hide a broken layout. It creates a safe overlay system from the start.

Fast practical rule

If an offscreen menu creates horizontal scroll, do not start by adding overflow-x:hidden to the whole site. First test the closed menu state. Remove negative offsets, replace document-based positioning with a fixed overlay layer, make the drawer width fluid, and move the drawer with a controlled transform.

Debug checklist

  • Inspect the closed menu state, not only the open menu state.
  • Search for right:-, left:100%, left:100vw, and large translate values.
  • Check whether the drawer is absolute inside the document instead of fixed to the viewport.
  • Replace fixed drawer widths with width:min(340px, 88vw) or a similar safe value.
  • Use inset:0 for the overlay layer instead of manually setting oversized viewport widths.
  • Keep the backdrop, drawer, and inner menu strips bounded to the same viewport layer.
  • Avoid solving the problem only with body { overflow-x:hidden; }.
  • Test the page width while the menu is closed, opening, and fully open.
Best first moveTemporarily remove the drawer from the DOM. If scroll disappears, the menu system is the source.
Most common causeA closed drawer is hidden with a negative right value or left:100%.
Most sneaky causeThe backdrop or inner menu strip is wider than the viewport.
Better mindsetA drawer should be an overlay layer, not a normal page element pushed sideways.

Related fixes that can help

Offscreen menu overflow often connects to mobile menu bugs, hidden page width, unsafe viewport units, absolute positioning, and negative offsets.

Why is my mobile menu not opening? If the drawer also fails to open, close, or respond to taps. Read this fix
Horizontal scroll on mobile? If the whole page slides sideways after the menu is added. Read this fix
Why is my page wider than the screen? If you need the broader page-width diagnosis. Read this fix
Why does an absolute element create mobile overflow? If the menu is positioned with absolute offsets. Read this fix
Why does 100vw cause horizontal scroll? If the drawer or backdrop uses viewport width. Read this fix
Why does a negative margin create horizontal scroll? If the menu uses breakout spacing or negative offsets. Read this fix

Final takeaway

An offscreen menu creates horizontal scroll when the closed state still occupies or leaks into scrollable space. The menu may look hidden, but if its box sits outside the viewport with negative offsets, oversized widths, or unsafe transforms, the page can become wider than the screen.

Build the drawer as a fixed overlay layer, give it a fluid width, keep the backdrop bounded, and animate with transform inside a safe system. That lets the menu slide without dragging the entire document width along with it.

The cleanest test is simple: the document should not become wider when the menu component exists on the page. A closed drawer, an open drawer, and an animating drawer should all preserve the same viewport width. If any state creates sideways scroll, the drawer system still needs safer boundaries.

Want more fixes like this?

Browse more mobile menu, overflow, and responsive CSS debugging guides in the FrontFixer library.

CSS Fixes All Fixes

Why Is My CSS Transition Not Working?

by

A CSS transition usually stops working when the transition is placed on the wrong state, the property cannot be animated, the starting value is missing, or another CSS rule overrides the change.

CSS Animation Fix

Why is my CSS transition not working?

A CSS transition can look broken even when the syntax seems correct. The element may jump instantly, the hover state may change without animation, the accordion may open suddenly, or the effect may work in one direction but not the other. The real cause is usually one of a few things: the transition is on the wrong selector, the property cannot animate smoothly, the browser has no starting value, or another rule is overriding the final state.

Browse CSS Fixes Browse All Fixes
  • CSS transition
  • Hover animation
  • Animatable properties
  • Motion debugging

What the bug looks like

The element changes instantly, only animates one way, ignores the transition, or jumps when it should slide, fade, lift, or expand smoothly.

Why it happens

CSS transitions only animate between known values for animatable properties. If the property cannot interpolate, there is nothing to animate.

What usually fixes it

Put transitions on the base state, animate transform or opacity when possible, define clear start/end values, and avoid transitioning display.

Error 1

The transition is only written on the hover state

This is one of the most common transition mistakes. If the transition is only declared inside :hover, the browser may animate when entering hover but snap back when leaving. The base element should know how to transition.

Broken code

Transition on hover only 
.card:hover {
  transform: translateY(-6px);
  background: #fff5ef;
  transition: transform .2s ease;
}

Broken visual result

Snaps back
Card hover The card changes, but the reverse movement can feel abrupt because the base state has no transition.
Jump
The transition belongs on the normal state, not only on the changed state.

Correct code

Transition on base element 
.card {
  transition:
    transform .2s ease,
    background .2s ease;
}

.card:hover {
  transform: translateY(-6px);
  background: #fff5ef;
}

Fixed visual result

Smooth both ways
Card hover The base element owns the transition, so the browser can animate in and out of the state.
Smooth
Put the transition on the element before the state changes.
Error 2

You are trying to transition display

display:none to display:block is not a smooth animation. The element is either in the layout or not. The browser cannot gradually interpolate between those two states.

Broken code

Display cannot fade 
.menu {
  display: none;
  transition: display .2s ease;
}

.nav:hover .menu {
  display: block;
}

Broken visual result

Appears instantly
display: none → block not smooth
transition: display .2s ease bad target
The browser cannot animate display like opacity or transform.

Correct code

Opacity and transform 
.menu {
  opacity: 0;
  transform: translateY(8px);
  pointer-events: none;
  transition:
    opacity .2s ease,
    transform .2s ease;
}

.nav:hover .menu {
  opacity: 1;
  transform: translateY(0);
  pointer-events: auto;
}

Fixed visual result

Fades and slides
opacity: 0 → 1 smooth
transform: translateY(8px) → 0 smooth
Animate properties the browser can interpolate smoothly.
Error 3

The changed property is not included in the transition

If you change transform but only transition background, the color may animate while the movement jumps instantly. The transition list has to include the property that changes.

Broken code

Wrong property listed 
.box {
  transition: background .2s ease;
}

.box:hover {
  transform: translateX(80px);
  background: #ff6a3d;
}

Broken visual result

Movement jumps
Box movement The background can animate, but the transform is not in the transition list.
Jump
The property that changes must be part of the transition.

Correct code

Transition real changes 
.box {
  transition:
    transform .2s ease,
    background .2s ease;
}

.box:hover {
  transform: translateX(80px);
  background: #ff6a3d;
}

Fixed visual result

Movement is smooth
Box movement Now both the movement and the background color have transition instructions.
Smooth
Transition the properties you actually change.
Error 4

The property causes layout jumps instead of smooth motion

Some properties can animate, but they are expensive or visually awkward because they force layout recalculation. Animating width, height, margin, or top can feel jumpy. For motion, transform is usually safer.

Broken code

Layout-heavy animation 
.badge {
  width: 88px;
  transition: width .2s ease;
}

.badge:hover {
  width: 170px;
}

Broken visual result

Layout gets pushed
Expanding badge The element grows by changing layout size, which can push nearby content.
Wide
Changing layout dimensions can create visual instability around the element.

Correct code

Transform instead 
.badge {
  transform: scale(1);
  transition: transform .2s ease;
}

.badge:hover {
  transform: scale(1.08);
}

Fixed visual result

Motion without layout push
Scaling badge The element feels animated without forcing surrounding layout to recalculate.
Scale
For motion, prefer transform and opacity when they fit the design.
Premium pattern

A production-minded transition pattern

A better transition setup is intentional. It defines a stable base state, animates predictable properties, respects reduced motion preferences, and avoids layout-heavy changes unless they are truly necessary.

Premium code

Smooth and safer 
.card {
  transform: translateY(0);
  opacity: 1;
  border-color: #e5e7eb;
  box-shadow: 0 12px 28px rgba(15,23,42,.06);
  transition:
    transform .2s ease,
    border-color .2s ease,
    box-shadow .2s ease;
}

.card:hover,
.card:focus-within {
  transform: translateY(-4px);
  border-color: #ffd2c2;
  box-shadow: 0 18px 38px rgba(255,106,61,.12);
}

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: none;
  }

  .card:hover,
  .card:focus-within {
    transform: none;
  }
}

Premium visual result

Predictable motion
Production-ready transition

The card has a clear base state, a clear hover/focus state, smooth visual feedback, and a reduced-motion fallback.

Premium transitions are not just decorative. They are controlled, readable, and less likely to create layout instability.

Fast practical rule

If a CSS transition is not working, inspect whether the property actually changes. Then check whether that property is animatable, included in the transition list, and declared from a clear starting value on the base element.

Debug checklist

  • Put transition on the base element, not only on :hover.
  • Confirm the property you are changing is included in the transition list.
  • Check whether the property can actually animate smoothly.
  • Avoid trying to transition display:none to display:block.
  • Use opacity, transform, or max-height patterns when appropriate.
  • Define a clear starting value and ending value.
  • Check DevTools to confirm no stronger rule overrides the hover or active state.
  • Use prefers-reduced-motion for more respectful production UI.
Best first move Force the hover or active state in DevTools and check whether the property really changes.
Most common cause The transition is declared only on the changed state instead of the base element.
Most confusing cause The CSS is valid, but the property cannot animate the way you expect.
Better mindset A transition does not create a state change. It only smooths a state change that already exists.

Related fixes that can help

If your transition does not work, the real cause may be hover targeting, CSS not updating, specificity, or a hidden clickable layer.

Why is my hover effect not working? If the transition depends on hover, but the hover state itself is not being triggered. Read this fix
Why is my CSS not updating? If you added transition code but the page still shows the old behavior. Read this fix
Why is my button not clickable? If the transition target is covered by another layer or cannot receive pointer input. Read this fix

Final takeaway

A CSS transition not working usually means the browser has no smooth path between two values. Either the transition is on the wrong selector, the wrong property is listed, the property cannot animate, or the final state is being overridden.

Start by proving that the property actually changes. Then make sure the base element owns the transition and the property can be interpolated. Once those pieces are correct, the transition becomes predictable instead of mysterious.

Want more fixes like this?

Browse more CSS interaction and layout debugging guides in the FrontFixer library.

CSS Fixes All Fixes