Inputs Classes auto-replaced in front-end by CSForms?

Support
#1

Hi Themeco Team,

Today I discovered what appears to be a bug related to CSForms input’s Class in a custom JavaScript implementation that manages both a password strength indicator and a show/hide password feature within a password reset/change workflow.

Everything was working perfectly until recently.

The inputs are built using CS Forms, with custom names and Classs assigned in Cornerstone. My JavaScript relies on those Class to function correctly.

After investigating the issue, I found that CS Forms now seems to automatically replace the input’s Class on the front end, even when custom Class have been explicitly defined.

For instance, I have two password fields configured in Cornerstone, initially contain those values as Name and Class:

  • First password field: pass1 (as name and Class)
  • Second password field: pass2 (as name and Class)

However, in the front-end DOM (as inspected through Google Chrome DevTools), custom classes are being replaced with generic values as :

  • cs-input

This was not the previous behavior.

As a result, my class-based selectors no longer work because the IDs rendered on the front end no longer match those configured in Cornerstone.

I can easily update my code to work around this issue, but before doing so I would like to know whether this behavior is intentional and expected in CS Forms, or whether it is a bug that will be addressed in a future update.

From my understanding, it currently appears that developers can no longer define and preserve custom input classes within CS Forms.

Thank you for your clarification,

–
Florian

–
P.S. : Screenshots are attached for reference.

Capture d’écran 2026-06-25 à 10.13.25
Capture d’écran 2026-06-25 à 10.13.25898×504 32.4 KB
Capture d’écran 2026-06-25 à 09.52.03
Capture d’écran 2026-06-25 à 09.52.033590×676 207 KB
Capture d’écran 2026-06-25 à 09.50.28
Capture d’écran 2026-06-25 à 09.50.283620×846 265 KB

#2

The class control is going to control the input container. Placing it on the input was causing issues when using Custom CSS. Effects were originally only being placed on the input as well, but changing the container to handle effects resulted in the effects also working on the label which is probably more expected. The Custom Attributes are still placed on the Input if you need an identifier. In the future we will probably add individual id, custom attributes, and class controls for both the container and the input. Let me know if this helps and have a great day.

1 Like
#3

Hi @charlie

Thank you, this explanation is very clear!

I now have a much better understanding of how the class handling works and why delegating it to the container makes sense.

In that case, I’ll target three successive selectors to ensure backward and forward compatibility in case things evolve in the future.

Thanks again, and have a great day too

Florian