SOLVED: Potential Editor / Frontend Parity Bug Pertaining to Form Element

Browser: Chrome 150.0.7871.187
OS: macOS
URL: Investors | Invest in the Future of Shirtdesk
Video: Jam

I think I may have discovered a potential bug that creates disparity between the editor view and the frontend view as can be seen in the linked video.

I used the following custom CSS to change the gap property value of the form:
%root% {
gap: var(--space-m);
}
and the value of the --space-m variable is clamp(1.75rem, calc(1.6667rem + 0.3704vw), 2rem)

Additionally, I used the following width value for all of the 50% fields in the Form element settings to account for the gap in the fields’ width:
calc((100% - var(–space-m)) / 2)

As long as the form renders correctly on the frontend, which it does, this obviously isn’t a big deal. But nonetheless, I still wanted to raise the potential issue.

I figured I would also ask if there are any plans for a Form (Nestable) element in the future. I think it would be very useful. For example, while the Form element uses flexbox, the display settings don’t seem to be exposed anywhere in the editor, which feels somewhat limiting.

Hi Brandon,
Thanks for your report!

The Form field width control is a % number control. In the builder preview, the CSS generator appends the % unit even when the value is a calc() expression that already contains %, which can produce an invalid value like calc((100% - var(--space-l)) / 2)%.

The frontend generator does not append the extra % in this case, so the frontend output is correct.

In my opinion, it should be the same. We’ll update this thread once it’s fixed.

1 Like

Thanks so much, Stefan. I really appreciate your explanation and your willingness to look into this further!

We’ve addressed this in Bricks 2.3.11, now available as a one-click update in your WordPress Dashboard.

Please read the changelog entry before updating, and let us know if you experience any issues.