# WIP: Copy Styles from Form Element ID to Global Class Copies Field Definitions, Causing Incorrect CSS on Reordered Fields

**URL:** <https://forum.bricksbuilder.io/t/wip-copy-styles-from-form-element-id-to-global-class-copies-field-definitions-causing-incorrect-css-on-reordered-fields/40763>\
**Category:** Bugs\
**Tags:** v2-4-5\
**Created:** [November 5, 2026, 9:50pm UTC](https://forum.bricksbuilder.io/t/wip-copy-styles-from-form-element-id-to-global-class-copies-field-definitions-causing-incorrect-css-on-reordered-fields/40763 "2026-11-05T21:50:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hrood](https://forum.bricksbuilder.io/letter_avatar_proxy/v4/letter/h/3ab097/32.png) [@hrood](https://forum.bricksbuilder.io/u/hrood)\
**Post date:** [November 5, 2026, 9:50pm UTC](https://forum.bricksbuilder.io/t/wip-copy-styles-from-form-element-id-to-global-class-copies-field-definitions-causing-incorrect-css-on-reordered-fields/40763/1 "2026-11-05T21:50:48Z")

</div>

Using **Copy Styles** to transfer styling from a Bricks Form element’s ID to a global class also copies the form’s field definitions into that class. When the global class is subsequently applied to another form with different fields, Bricks generates field-specific CSS based on the original form’s configuration.

This causes unintended styling on the second form and is difficult to identify or correct through the builder interface.

**Steps to Reproduce:**

1. Create a Bricks Form element containing Name, Email, Phone, and Message (textarea) fields.

2. Set the Message textarea height to `150px`.

3. Configure additional styling on the Form element’s ID, such as input borders, backgrounds, and padding.

4. Use **Copy Styles** to copy the Form element ID’s styles to a new global class (e.g., `ndig-form`).

5. Apply the new global class to the original form.

6. Create a second Form element with a different field configuration, where the fourth field is not a textarea.

7. Apply the same global class to the second form.

8. Save and inspect the second form’s frontend CSS.

**Actual Result:**

Bricks stores the original form’s entire `fields` array in the global class, including the textarea’s `height: 150` setting.

When applied to the second form, Bricks generates:

```auto
.ndig-form.brxe-form .form-group:nth-child(4) {
    height: 150px;
}

```

This incorrectly applies a 150px height to the fourth field of the second form, even though that field is not a textarea and has no height setting.

Removing the global class from the second form immediately resolves the issue. Removing the height setting from the second form does not, because the configuration is stored in the global class.

**Expected Result:**

Copy Styles should transfer reusable styling properties without copying the Form element’s field definitions or other content/configuration data into the global class.

Field-specific settings should not be inherited by unrelated form fields based solely on their position.

**Workaround:**

Export the global classes JSON, locate the affected class, and manually remove the `fields` array from its `settings` object while preserving the intended styling properties.

**Additional Notes:**

The issue persisted after switching to external CSS and regenerating styles. Examination of the exported global classes JSON confirmed the unwanted field definitions were stored in the global class.

This may affect other Bricks elements if Copy Styles similarly transfers content or structural configuration into global classes, but I have not run into that anywhere else yet.

---

<div class="post-metadata">

**Author:** ![timmse](https://forum.bricksbuilder.io/user_avatar/forum.bricksbuilder.io/timmse/32/1192_2.png) [@timmse](https://forum.bricksbuilder.io/u/timmse)\
**Post date:** [November 6, 2026, 6:28am UTC](https://forum.bricksbuilder.io/t/wip-copy-styles-from-form-element-id-to-global-class-copies-field-definitions-causing-incorrect-css-on-reordered-fields/40763/3 "2026-11-06T06:28:11Z")

</div>

Thanks for your report!  
I was able to reproduce the issue and have created an internal task.

We’ll update this thread as soon as we have a solution ✌

---

<div class="post-metadata">

**Author:** ![williamsmith](https://forum.bricksbuilder.io/letter_avatar_proxy/v4/letter/w/edb3f5/32.png) [@williamsmith](https://forum.bricksbuilder.io/u/williamsmith)\
**Post date:** [November 10, 2026, 3:14am UTC](https://forum.bricksbuilder.io/t/wip-copy-styles-from-form-element-id-to-global-class-copies-field-definitions-causing-incorrect-css-on-reordered-fields/40763/4 "2026-11-10T03:14:30Z")

</div>

The key detail for me is that the fields array travels with the class, not just the styling props. That explains why removing the height from the second form changes nothing—the override lives in the class definition, so it wins regardless of what the second form declares. Worth checking whether the class editor exposes that stored array at all, or if it’s only visible via the generated CSS. If it’s the latter, anyone applying the class is debugging blind. A workaround in the meantime might be hand-building the class rather than using Copy Styles, though that loses the convenience the feature is meant to provide.
