Skip to main content
Not every responsive adjustment should happen at a hard breakpoint. Font sizes that snap from 16 px to 24 px at exactly 768 px can feel abrupt, and spacing that stays identical from a 1400 px desktop down to a 375 px phone often looks too cramped or too generous at the extremes. AtomicKit addresses this with fluid scaling: selected utility families output CSS clamp() values so that sizes and spacing shift continuously and proportionally as the viewport width changes — no breakpoint overrides required.

​
Why fluid scaling helps

With a traditional breakpoint approach, you define a value at several fixed widths and accept that it stays constant between those points. The result is a series of visual steps:
  • A heading is 24 px from 0–767 px, then jumps to 32 px at 768 px, then to 48 px at 1200 px.
  • The jump is immediate and can look mechanical, especially on mid-range or foldable devices that sit between your defined breakpoints.
Fluid scaling removes the steps. The value starts at a minimum size on small viewports, increases proportionally as the viewport grows, and reaches a maximum size on large viewports — all in a single continuous curve. The practical result is:
  • Better readability at every viewport width, not just the ones you explicitly designed for.
  • Fewer utility classes per element — one class covers the full range rather than needing a base class plus several --on-* overrides.
  • More natural proportions between typographic scale and layout at intermediate sizes like tablets, landscape phones, and ultrawide monitors.

​
How it works

Fluid scaling relies on the CSS clamp() function, which accepts three arguments: a minimum value, a preferred (viewport-relative) value, and a maximum value. 
clamp(minimum, preferred, maximum)
The browser uses the preferred value when it fits between the minimum and maximum. If the viewport is too narrow, the minimum is applied instead; if it’s too wide, the maximum takes over. The preferred value typically combines a rem base with a vw component so it grows as the viewport widens. Here is an example from a large heading utility: 
.hero-title {
  font-size: clamp(2rem, calc(1.5rem + 2vw), 4rem);
}
  • At narrow viewports, font-size clamps to 2 rem (the minimum).
  • As the viewport widens, font-size follows calc(1.5rem + 2vw), growing proportionally.
  • At wide viewports, font-size clamps to 4 rem (the maximum) and stops growing.
AtomicKit pre-calculates the clamp() expressions for each step in a fluid utility family, so you apply a class like text-xl or m-8 and the browser handles the interpolation automatically.
The clamp() function has broad browser support across all modern browsers. No polyfill or fallback is needed for Elementor sites targeting current browser versions.

​
Fluid vs. fixed utility families

Not every utility benefit from fluid scaling. Layout helpers, color utilities, and declarative states have values that are categorical rather than continuous — there is no meaningful “interpolation” between display: flex and display: block. AtomicKit applies fluid scaling only where smooth transitions add value.
FamilyScalingReason
text-* (font sizes)FluidTypography reads better when it scales proportionally with the viewport
m-* (margin)FluidSpacing that breathes at large viewports and compresses gracefully on mobile
p-* (padding)FluidSame rationale as margin — proportional containment feels natural
gap-* (flex/grid gap)FluidGrid and flex gaps should stay proportional to the items they separate
ColorsFixedColors are categorical — there is no “halfway” between two brand colors
Font weightsFixedWeight steps are discrete; intermediate values look inconsistent across fonts
display / positioningFixedThese are on/off states, not continuous scales
maximum-width-*FixedContainer max-widths are layout constraints tied to specific design decisions
Border widthsFixedHairline, thin, and medium borders are intentional categorical choices
Component presetsFixedPreset styles encode specific design intent and should not drift
leading-* (line-height)FixedLine-height ratios are unitless multipliers, not viewport-relative values
If you need a spacing or font size value that doesn’t change at all — for example, a fixed icon size or a label at an exact pixel size — use an Elementor Size Variable or a custom CSS override rather than a fluid utility. Fluid classes are optimized for values that should respond to the viewport.

​
Best practices

Because text-*, m-*, p-*, and gap-* classes already scale across the full viewport range, you usually don’t need to add --on-* suffix variants for those families. Reach for a responsive suffix only when you also need a structural change (like switching flex direction), not just to adjust a size.
Fluid scaling works best when the sizing relationships stay consistent. If your headings scale fluidly but your padding is fixed, the proportion between text and its container will shift noticeably at extreme screen sizes. Apply fluid p-* or m-* classes to the same containers where you use fluid text-* classes.
Think of fluid scaling as designing two states — the smallest acceptable size and the largest acceptable size — and letting the browser interpolate between them. Define your design intent at mobile and desktop sizes first, then verify the intermediate sizes look proportional rather than designing for every breakpoint individually.
If you apply a fluid text-lg class and also write a custom CSS rule that sets font-size: 18px on the same element, the specificity battle will produce unpredictable results depending on selector weight. Keep fluid properties under AtomicKit classes and reserve custom CSS for properties AtomicKit doesn’t cover.

​
Related references

Typography Utilities

Browse the full text-* scale and see the clamp() values output by each step, from text-xs to text-9xl.

Spacing Utilities

Explore the fluid m-*, p-*, and gap-* scales — including the clamp() ranges applied at each spacing step.