Responsive breakpoint overrides.

Glopzi has three breakpoints. They’re fixed and named:

• Desktop: the default. The values you set without thinking about breakpoints land here.
• Tablet: typically below ~1024 pixels wide. Optional override layer.
• Mobile: typically below ~768 pixels wide. Optional override layer.

The exact pixel thresholds match Tailwind’s defaults for new sites and adapt to the values your custom site sets if your CSS already defines them. Visitors get the breakpoint that matches their viewport at page load.

The lookup order at runtime, simplest first:

• On a desktop visitor, Glopzi reads only the desktop values.
• On a tablet visitor, Glopzi starts with desktop values, then overlays tablet values for any properties you overrode.
• On a mobile visitor, Glopzi starts with desktop values, then tablet values (if any), then mobile values (if any).

The result: an override is a diff, not a duplication. If you only change opacity for mobile, everything else (translate, scale, easing, duration) inherits from desktop. Edit desktop later and the change flows through automatically.

The flow is the same for every property:

• In the toolbar, click the breakpoint you want to override (tablet or mobile icon).
• The canvas resizes to that viewport. The right panel shows current values, with override-aware controls.
• Edit the property. The moment you change a value, a small override dot appears next to that property’s row to indicate it’s no longer inheriting.

You can override any animatable value: opacity, transform, color, easing, duration, delay, even split-text settings. Overrides scope per-property, so you can override just opacity for mobile while everything else inherits.

To revert a property to inheriting from the parent:

• Make sure you’re viewing the breakpoint where the override exists.
• Click the override dot next to the property row. The value clears and the row reverts to inheritance. The field shows the inherited value, slightly dimmed.

Removing an override on tablet falls back to desktop. Removing an override on mobile falls back to tablet (if tablet has its own override) or desktop.

Almost everything per animation:

• Property values at any keyframe (opacity, x, y, scale, rotate, blur, color, and so on).
• Timing: duration, delay, stagger.
• Easing: a different curve per breakpoint if you want.
• Triggers: change the trigger entirely on mobile (for example, “in view” on desktop, “load” on mobile so it doesn’t depend on scroll position).
• Disabling: turn an animation off on mobile entirely while leaving it on for desktop.

Targets and animation type can’t be overridden. An animation always points at the same element and stays the same kind across breakpoints.

The patterns that show up most often:

• Slower on small screens. Mobile visitors see less surface area at once. Slowing animations 20-30% on mobile often feels better.
• Less translate distance.A 60-pixel slide-up looks elegant on desktop but feels excessive on mobile where it’s a larger fraction of the viewport.
• Different trigger.“In view” on desktop where you can see what’s coming, but “load” on mobile where vertical scroll obscures things.
• Disable expensive effects. Heavy WebGL backgrounds can be left on for desktop and disabled for mobile to save battery and bandwidth.

See Responsive animations done right for a deeper look at the patterns and trade-offs.

• The toolbar: where the breakpoint switcher lives.
• Responsive animations done right: conceptual guidance for what to override and what to leave alone.
• Saving and publishing: overrides save with the rest of the animation; nothing extra to publish.