Troubleshooting Elementor Styling Conflicts with Gravity Forms

Overview

This article explains how Elementor’s styling can override the Gravity Forms theme, and how to identify and resolve the conflict.

Elementor applies its own CSS to inputs, labels, and buttons on the pages it builds, including forms it did not create. When that styling overrides the Gravity Forms theme, the form still works; it just doesn’t look the way you intended.

Symptoms

  • Inputs, labels, or buttons don’t match the styling configured in Gravity Forms.
  • The same form looks different on an Elementor page than elsewhere on the site.
  • Fonts, colors, or spacing changed after Elementor Pro was activated.
  • Style settings changed in the form editor have no visible effect on the page.
  • Custom CSS only takes effect when !important is added.

Why It Happens

How the Form is Embedded

There is no Gravity Forms widget in Elementor itself. Forms reach an Elementor page in one of these ways, and the method affects what can style them:

  1. Elementor’s Shortcode widget, holding a

    Oops! We could not locate your form.

     shortcode. This is the most common method and exposes no form styling options of its own.
  2. A third-party Gravity Forms widget. GravityKit’s free Gravity Forms Widget for Elementor styles the widget box (background, spacing, and border) and lets you choose the form theme. Widgets from Elementor addon packs and styler plugins add their own controls for inputs, labels, and buttons, which add another layer of CSS.
  3. An Elementor pop-up. Popup markup is often not handled like the rest of the page, so styles and scripts can behave differently inside a pop-up.

Elementor Styles

Elementor’s global fonts, colors, and Theme Style › Form Fields target inputs, labels, and buttons on the whole page, regardless of which plugin rendered them. A Gravity Form inherits them alongside its own theme.

Selector Specificity

When both stylesheets set the same property, the more specific rule wins. Elementor’s rules are often more specific than the form theme’s, so the form theme loads correctly but the browser uses Elementor’s value, and changing a Gravity Forms setting shows no effect.

Styler Widgets

A styler widget adds its own style settings on top of both the form theme and Elementor’s CSS. GravityKit’s widget does not do this, because its style controls cover only the widget container.

Stale Generated CSS

Elementor writes the CSS for each page to a file and reuses it, so a change can appear to do nothing. Clearing the cache does not rebuild the file immediately; it is written the next time the page is visited.

Elementor › Tools › General

Note: Gravity Forms’ No-Conflict Mode will not fix this. It prevents third-party styles and scripts from loading on Gravity Forms admin screens, which can help when the form editor itself misbehaves, but it has no effect on how your form looks to visitors.

Confirm the Issue

  1. Place the same form on a page using the default WordPress editor. If it looks correct there, the difference is coming from Elementor or from a third-party Elementor plugin’s styles.
  2. Right-click a field that looks wrong and choose Inspect. In the Styles panel, find the property that is wrong and see which stylesheet supplies the winning rule. That tells you whether to change Elementor, a widget, or the form theme.
  3. Check which form theme is in use at Forms › Settings › Default Form Theme, or in the block, shortcode, or widget settings for that form. The CSS API applies to the Orbital theme but not to the Gravity Forms 2.5 Theme. Orbital’s visual style settings (input size, colors, labels, buttons) appear only in the form block’s sidebar, so they are not available when the page is built in Elementor.
  4. Clear the Elementor cache at Elementor › Tools › General, then reload the front end. The files are rebuilt on that visit. If the appearance changes, the stored CSS is out of date.

How to Fix It

Note: Reaching for !important means you are fighting at the wrong level. Use Inspect to find which stylesheet is winning, and change the setting at that source.

  1. If an Elementor rule is winning, edit Site Settings › Theme Style › Form Fields, or the widget’s own style settings, rather than overriding the selector.
  2. If a Gravity Forms rule is winning, use the CSS API. Set the custom properties on .gform-theme--framework, which the form wrapper already has, and scope them to one form with #gform_wrapper_{id} when they should not apply site-wide. Global properties look like --gf-color-primary, and more specific ones follow --gf-{area}-{property}-{state}, such as --gf-ctrl-bg-color-focus.
  3. If a third-party styler widget is in use, check its styling settings before writing any CSS.
  4. Write selector-level CSS only for cases the CSS API doesn’t cover, and scope it to the form wrapper rather than to input elements in general, so it doesn’t affect other forms on the site.
  5. After any change, clear the Elementor cache at Elementor › Tools › General, reload the page to rebuild the file, then clear any caching plugin, host cache, or CDN in front of the site.
  6. If the problem persists, contact Elementor support or the developer of your Elementor widget plugin for help with the Elementor styles that are overriding the form.

Resources

​Disclaimer: Third-party services, plugins, or code snippets that are referenced by our Support documentation or in Support Team communications are provided as suggestions only. We do not evaluate, test or officially support third-party solutions. You are wholly responsible for determining if any suggestion given is sufficient to meet the functional, security, legal, ongoing cost and support needs of your project.

Feedback, feature, and integration requests, and other functionality ideas can be submitted at https://gravity.com/feature-request/.