> ## 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.

# Responsive Breakpoints with the --on-* Suffix System

> Apply AtomicKit utility classes at specific viewport sizes using the --on-xs through --on-xxl breakpoint suffix system for responsive Elementor layouts.

AtomicKit offers two complementary approaches to responsiveness. For values like font sizes and spacing that should shift gradually as the viewport grows or shrinks, AtomicKit uses fluid scaling with CSS `clamp()`. For structural decisions — changing a flex direction, hiding an element, or reordering items — you need discrete control at specific breakpoints. The `--on-*` suffix system is how you express those layout shifts: append a breakpoint suffix to any supported class name and that override takes effect only at the viewport size you specify.

## Breakpoint map

AtomicKit ships six breakpoints, covering everything from widescreen displays down to small mobile viewports. Each suffix maps to a CSS media query:

| Suffix     | Media Query         | Viewport                   |
| ---------- | ------------------- | -------------------------- |
| `--on-xxl` | `min-width: 2400px` | Widescreen and above       |
| `--on-xl`  | `max-width: 1366px` | Laptop and below           |
| `--on-l`   | `max-width: 1200px` | Tablet landscape and below |
| `--on-m`   | `max-width: 1024px` | Tablet and below           |
| `--on-s`   | `max-width: 880px`  | Mobile landscape and below |
| `--on-xs`  | `max-width: 767px`  | Mobile only                |

<Info>
  Notice that `--on-xxl` uses `min-width` (a "wide and above" query), while all other suffixes use `max-width` ("this size and below"). Design mobile-first by setting your default class for small screens and overriding upward with `--on-xxl`, or design desktop-first and override downward with the `max-width` suffixes.
</Info>

***

## How to use responsive suffixes

Append the suffix directly to the end of the class name with no space. The base class always applies first; the suffixed variant overrides it when the media query is active.

**Syntax:**

```
{base-class}--on-{breakpoint}
```

**Example — flex column that becomes a row on tablet and below:**

```html theme={null}
<!-- Applied via Elementor Advanced > CSS Classes field -->
flex flex-col flex-row--on-m
```

Here, `flex` enables flex display, `flex-col` sets the default direction to column, and `flex-row--on-m` overrides the direction to row at viewports 1024 px wide and below. You apply all three classes in the **Advanced → CSS Classes** field, space-separated, just like any other utility combination.

<Tip>
  Always write the base class first for readability. Seeing `flex-col flex-row--on-m` makes it immediately clear what the default behavior is and where it changes.
</Tip>

***

## Responsive layout example

The following class combination creates a three-column card grid that collapses to a single column on mobile:

```html theme={null}
<!-- Container: row layout that stacks on small screens -->
flex flex-row flex-col--on-xs gap-6

<!-- Each card: full width on mobile, auto width otherwise -->
flex-basis-auto flex-basis-full--on-xs
```

And a navigation bar that hides on mobile and reappears on larger screens:

```html theme={null}
<!-- Show on desktop, hide on mobile -->
flex hidden--on-xs
```

<Note>
  When you hide an element with a responsive suffix, the element is still in the DOM — only its display value changes. This is intentional for accessibility and SEO. If you need to remove content entirely on certain devices, use Elementor's built-in responsive visibility controls instead.
</Note>

***

## Supported utility families

Responsive suffixes are available on structural utilities that affect layout and composition. They are intentionally **not** available on every utility family — fluid scaling handles continuous value shifts, so breakpoint overrides are reserved for genuinely discrete structural changes.

The following families support `--on-*` suffixes:

<CardGroup cols={2}>
  <Card title="Display" icon="eye">
    `flex`, `block`, `inline`, `hidden`, and related display values.
  </Card>

  <Card title="Overflow" icon="arrows-left-right">
    `overflow-hidden`, `overflow-auto`, `overflow-scroll`, and axis variants.
  </Card>

  <Card title="Object Fit" icon="image">
    `object-cover`, `object-contain`, `object-fill`, and related values.
  </Card>

  <Card title="Aspect Ratio" icon="crop">
    `aspect-square`, `aspect-video`, `aspect-auto`, and numeric ratios.
  </Card>

  <Card title="Positioning" icon="crosshairs">
    `relative`, `absolute`, `fixed`, `sticky`, and `static`.
  </Card>

  <Card title="Z-Index" icon="layer-group">
    `z-0` through `z-50` and `z-auto`.
  </Card>

  <Card title="Flex Direction" icon="arrows-up-down">
    `flex-row`, `flex-col`, `flex-row-reverse`, `flex-col-reverse`.
  </Card>

  <Card title="Flex Wrap" icon="rotate">
    `flex-wrap`, `flex-nowrap`, `flex-wrap-reverse`.
  </Card>

  <Card title="Alignment" icon="align-center">
    `justify-*`, `items-*`, `self-*`, and `content-*` alignment utilities.
  </Card>

  <Card title="Flex Basis & Order" icon="sort">
    `flex-basis-*` size steps and `order-*` values.
  </Card>
</CardGroup>

***

## Best practices

<Accordion title="Use suffixes for structural shifts only">
  Responsive suffixes exist to change how elements are arranged at different screen sizes — not to tweak every visual property at every breakpoint. Apply a suffix when the layout genuinely needs to reorganize (a row becomes a column, an element is hidden), not for minor stylistic adjustments. Fluid scaling handles gradual changes to font sizes and spacing automatically.
</Accordion>

<Accordion title="Keep the base class readable first">
  Write your default (unsuffixed) classes before any responsive overrides. Reading `flex-col flex-row--on-m` is immediately clear; reading `flex-row--on-m flex-col` forces the reader to figure out which is the default. Consistent ordering makes the CSS Classes field easier to scan.
</Accordion>

<Accordion title="Prefer fewer breakpoint changes over stacking many suffixes">
  Each additional breakpoint suffix adds cognitive overhead and increases the risk of conflicting overrides. Aim for one or two structural breakpoints per component. If you find yourself adding three or more suffixes to a single element, consider whether a simpler layout approach would serve the design better.
</Accordion>

<Accordion title="Test at actual device sizes, not just resized browser windows">
  The breakpoint values in AtomicKit are chosen to align with common device categories, but real devices don't always match. Use browser DevTools device emulation — and test on actual hardware when possible — to confirm your responsive overrides behave as expected.
</Accordion>

***

## Related concepts

For values that should scale gradually rather than jump at breakpoints, see the [Fluid Scaling](/concepts/fluid-scaling) page. Font sizes, spacing, and gap values use CSS `clamp()` so a single class stays proportional across the full viewport range — no suffix needed.