Responsive CSS Classes

[ericwang401]

Describe the Problem

Elementor’s CSS Classes field is not responsive.

Right now, classes are effectively global: you can’t toggle to Tablet/Mobile and add/remove a class so it only applies within that breakpoint range. This is inconsistent with how Elementor handles per-element styles, where you can switch breakpoints and edit a value, and Elementor scopes that change to that device range.

This becomes a real problem if you’re trying to build anything remotely systematic (utility classes, type scales, spacing scales, etc.). Example: I want to apply a typography utility like text-lg on desktop, but switch to text-base on tablet/mobile. In Tailwind this is trivial (md:text-lg text-base). In Elementor, I’m forced to either:

• hardcode the typography values per breakpoint on every element (easy to desync), or
• duplicate elements and hide/show by device (gross), or
• write custom CSS media queries for every class override (defeats the point of having “developer tools” in the UI)

Given V4 is explicitly pushing developer-facing features (variables, classes, custom CSS), it’s really frustrating that classes have the name but not the capability.

Propose a Solution

1. Make the CSS Classes control breakpoint-aware

   • When I toggle to Tablet/Mobile breakpoints, I should be able to add/remove classes and have that change scoped to that breakpoint range.
   • It should work like other responsive controls: base value + overrides with inheritance (desktop -> tablet -> mobile).

2. Provide a clear override model (so it’s not a footgun)

   • Additive mode: breakpoint adds extra classes on top of base classes
   • Override mode: breakpoint can remove classes from the base list (not just add)
   • Show a diff/indicator so it’s obvious when a breakpoint deviates from base

Additional Context

A major use case is typography systems. Elementor currently makes it hard to define constrained type "tokens" that include both font-size + line-height in one reusable thing. Creating utility classes is a good workaround, but that workaround falls apart because classes aren’t responsive.

Workarounds today:

• Duplicate the element and hide/show per breakpoint
• Hardcode typography per breakpoint on every element
• Custom CSS media queries per utility class

All of these are unnecessary if the classes control simply behaved like every other responsive control in Elementor.

Agreement

• I confirm I have read and followed all the guidelines and instructions outlined in the Feature Request form.
• I agree that my discussion may be closed without further action if it doesn't meet all the requirements outlined in the Feature Request form.

[alexanderpankart]

Would be nice.
I made 8 size variables for my whole typography on all screen sizes, because of that :

• text_small: max(1.000rem, 0.954rem + 0.229vw)
• text_p: max(1.080rem, 1.011rem + 0.343vw)
• text_h6: max(1.160rem, 1.069rem + 0.457vw)
• text_h5: max(1.240rem, 1.126rem + 0.571vw)
• text_h4: max(1.320rem, 1.183rem + 0.686vw)
• text_h3: max(1.400rem, 1.240rem + 0.800vw)
• text_h2: max(1.480rem, 1.297rem + 0.914vw)
• text_h1: max(1.560rem, 1.354rem + 1.029vw)

That's my "workaround", but i'm quite happy with that.

[ericwang401]

Thanks for your input but could you walk me through how you would use this scale to implement your UI designs (not really related to responsiveness)? Like I have h3's with different font sizes, so I use more general utility classes

[alexanderpankart]

shorter version:

longer version:

Initially, I debated whether I wanted my layout to scale infinitely or cap out at a certain max-width. Since I want the site to scale infinitely, I opted for max(). If I had gone with a fixed max-width, I would have just stuck with clamp().

Next, I defined all the rem sizes for mobile—from the smallest to the largest font sizes—and set them to scale linearly. Once that was looking good on larger screens, I ran into the obvious issue: the surrounding container boxes needed to scale up as well. To fix this, I used a calc() formula to dynamically tie their dimensions to the font size.

Then I noticed that the gaps between the boxes were feeling disproportionately smaller on big screens, so I handled those with calc() as well.

It was a very nerdy math afternoon, but I'm quite happy with how it turned out haha.

Using this approach, I was even able to recreate the grid system that is currently lacking in the V4 Flexbox containers. Because all the values are now strictly defined mathematically, they remain stable and don't shift across different screen sizes. For example, here is the code for my standard 3-column grid:

calc(100% / 3.000 - 2.000 * (2 * max(1.560rem, 1.354rem + 1.029vw)) / 3.000)