> ## Documentation Index
> Fetch the complete documentation index at: https://atomickit.copyelement.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Fluid Scaling: CSS clamp() for Typography and Spacing
> Discover how AtomicKit uses CSS clamp() to scale font sizes, spacing, and gaps smoothly across viewport widths without relying solely on breakpoints.
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.
```css theme={null}
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:
```css theme={null}
.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.
| Family | Scaling | Reason |
| ------------------------- | --------- | ----------------------------------------------------------------------------- |
| `text-*` (font sizes) | **Fluid** | Typography reads better when it scales proportionally with the viewport |
| `m-*` (margin) | **Fluid** | Spacing that breathes at large viewports and compresses gracefully on mobile |
| `p-*` (padding) | **Fluid** | Same rationale as margin — proportional containment feels natural |
| `gap-*` (flex/grid gap) | **Fluid** | Grid and flex gaps should stay proportional to the items they separate |
| Colors | **Fixed** | Colors are categorical — there is no "halfway" between two brand colors |
| Font weights | **Fixed** | Weight steps are discrete; intermediate values look inconsistent across fonts |
| `display` / positioning | **Fixed** | These are on/off states, not continuous scales |
| `maximum-width-*` | **Fixed** | Container max-widths are layout constraints tied to specific design decisions |
| Border widths | **Fixed** | Hairline, thin, and medium borders are intentional categorical choices |
| Component presets | **Fixed** | Preset styles encode specific design intent and should not drift |
| `leading-*` (line-height) | **Fixed** | Line-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
Browse the full `text-*` scale and see the `clamp()` values output by each step, from `text-xs` to `text-9xl`.
Explore the fluid `m-*`, `p-*`, and `gap-*` scales — including the `clamp()` ranges applied at each spacing step.