Title: CSS functionality is broken
Last modified: April 14, 2026

---

# CSS functionality is broken

 *  [getsnoopy](https://wordpress.org/support/users/getsnoopy/)
 * (@getsnoopy)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/css-functionality-is-broken/)
 * Hello,
 * I’ve noticed some of the CSS functionality in your plugin is broken. This is 
   how:
    1. For any form element/block added onto the Gutenberg form editor, there’s an 
       option to specify **Additional CSS classes**. When specified, these CSS classes
       get added to a wrapper element with the CSS class `mailpoet_paragraph`, rather
       than the actual element itself. This breaks functionality when needing to style
       the element, especially with theme CSS classes that are pre-defined (see screenshot
       below of how the button is supposed to look and how it does look).
    2. There’s a forced **Input Padding** field that sets padding on all form inputs,
       and there’s no way to “unset” it. If it’s set to `0`, all the fields actually
       have their padding set to `0`; if it’s reset, it goes back to `5`. This also
       interferes with the default theme styles. Since these interventions are being
       done using inline styles, there’s no good way to override them either (unless
       one decides to write custom code to overpower them with the `!important` declarations
       in rules, which is really bad form). It should default to the “unset” state,
       and if the user wants to add a global form element padding, they should be able
       to do so (similar to how all other blocks/elements work in the Theme Customization
       Gutenberg editor).
    3. As a minor point related to the previous point, fields like the Input Padding
       field don’t allow the user to specify a CSS unit (e.g., `%`, `rem`, `vw`, etc.).
       This is also expected, given that the user is able to do this in the regular
       theme-related Gutenberg editor.
 * ![](https://i0.wp.com/i.imgur.com/kvdLO1x.png?ssl=1)
 * In reference to list item 1
 * ![](https://i0.wp.com/i.imgur.com/QgQZq2K.png?ssl=1)
 * In reference to list item 1
 * ![](https://i0.wp.com/i.imgur.com/0RtS9CP.png?ssl=1)
 * In reference to list item 2

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Thread Starter [getsnoopy](https://wordpress.org/support/users/getsnoopy/)
 * (@getsnoopy)
 * [1 month, 1 week ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18883693)
 * Another aspect of this issue is that setting **Font Family** to **Theme’s default
   fonts** doesn’t have any effect as well, since there’s a large selector in some
   fixed CSS coming from the plugin that essentially targets all the text of the
   form and sets the font family and size of text in it explicitly, not allowing
   the `body` styles to cascade through:
 *     ```wp-block-code
       .mailpoet_form_html p, .mailpoet_form_html ol, .mailpoet_form_html ul, .mailpoet_form_html li, .mailpoet_form_html dl, .mailpoet_form_html dt, .mailpoet_form_html dd, .mailpoet_form_html blockquote, .mailpoet_form_html figure, .mailpoet_form_html fieldset, .mailpoet_form_html form, .mailpoet_form_html legend, .mailpoet_form_html textarea, .mailpoet_form_html pre, .mailpoet_form_html iframe, .mailpoet_form_html hr, .mailpoet_form_html h1, .mailpoet_form_html h2, .mailpoet_form_html h3, .mailpoet_form_html h4, .mailpoet_form_html h5, .mailpoet_form_html h6, .mailpoet_form_iframe p, .mailpoet_form_iframe ol, .mailpoet_form_iframe ul, .mailpoet_form_iframe li, .mailpoet_form_iframe dl, .mailpoet_form_iframe dt, .mailpoet_form_iframe dd, .mailpoet_form_iframe blockquote, .mailpoet_form_iframe figure, .mailpoet_form_iframe fieldset, .mailpoet_form_iframe form, .mailpoet_form_iframe legend, .mailpoet_form_iframe textarea, .mailpoet_form_iframe pre, .mailpoet_form_iframe iframe, .mailpoet_form_iframe hr, .mailpoet_form_iframe h1, .mailpoet_form_iframe h2, .mailpoet_form_iframe h3, .mailpoet_form_iframe h4, .mailpoet_form_iframe h5, .mailpoet_form_iframe h6{	font-family: Arial, Helvetica, sans-serif;	font-size: 16px;}
       ```
   
 *  Plugin Support [Thu P. a11n](https://wordpress.org/support/users/thup90/)
 * (@thup90)
 * [1 month ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18888634)
 * Hi there,
 * Thank you for taking the time to write such a detailed and well-structured feedback—
   we appreciate it!
 * I’d like to address each of your points:
 * **1. Additional CSS classes applied to the wrapper element** You’re right that
   the “Additional CSS classes” field currently adds classes to the `mailpoet_paragraph`
   wrapper `<div>` rather than directly to the form input or button element itself.
   I understand this limits the usefulness of theme-predefined CSS classes that 
   expect to be applied directly to the element. I’ll make sure to note this feedback
   for future development.
 * As a potential workaround for now, you could use the **Custom CSS** panel in 
   the form editor (available under the form’s Settings tab) to target the specific
   elements with more precise selectors. For example, you could use `.your-custom-
   class input` or `.your-custom-class .mailpoet_submit` to target elements within
   the wrapper.
 * **2. Input Padding with no “unset” option & inline styles** This is a known area
   of feedback. The inline styling approach for padding does make it difficult to
   override with standard CSS classes, as you noted. There is an existing feature
   request on our feedback board to address this: [Remove inline styles from forms](https://mailpoet.canny.io/feature-requests/p/remove-inline-styles-from-forms).
   I’d encourage you to add your vote there so the team can better gauge demand 
   for this improvement.
 * In the meantime, the most reliable (though admittedly not ideal) workaround is
   to use `!important` declarations in your theme’s **Additional CSS** (via _Appearance
   > Customize > Additional CSS_ for classic themes, or _Appearance > Editor > Styles
   > Additional CSS_ for block themes) to override the inline styles.
 * **3. No CSS unit selection for padding fields** That’s valid feedback. The form
   editor currently only supports pixel values for padding, whereas the core WordPress
   editor allows for other units.
 * **4. Font Family set to “Theme’s default fonts” not working** I understand the
   frustration with the broad CSS selector that explicitly sets `font-family: Arial,
   Helvetica, sans-serif` on all form text elements. When “Theme’s default fonts”
   is selected, it should ideally allow the theme’s body font styles to cascade 
   through rather than applying a fixed fallback.
 * As a temporary workaround, you can override the font-family using the form’s **
   Custom CSS** panel or your site’s **Additional CSS** by targeting the form elements
   specifically.
 * Thank you again for the thorough feedback. These are valuable observations that
   can help improve the form editor experience. It would be great to log these to
   our [Feature Request Board](https://mailpoet.canny.io/feature-requests), where
   other users can vote for your ideas and help with prioritization.
 *  Thread Starter [getsnoopy](https://wordpress.org/support/users/getsnoopy/)
 * (@getsnoopy)
 * [1 month ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18889749)
 * Hello,
 * **Regarding #1:** Yes, I could target elements using form-specific custom CSS,
   but that only works if I have specific styles to override/replicate. I want to
   use a CSS class on one of the form elements that has multiple rulesets defined
   on it in various parts of the theme’s CSS code. Since CSS doesn’t have a “include
   in this ruleset all styles that this selector has defined” feature, there’s no
   way to just use all those pre-defined styles wholesale. I’d have to essentially
   hunt down all the styles that the theme provides for such an element, and copy/
   paste those again into the Custom CSS part of the form editor—which is not just
   cumbersome, but inefficient and fragile (I’ll have to manually track changes 
   every time the underlying theme’s CSS changes).
 * For the moment, I’m doing a far cleaner workaround where I wrote a custom plugin
   that injects JS onto the page which manually finds the elements I’d like to target
   and sets the additional CSS classes on those elements so that I can use the predefined
   styles set on those classes.
 * **Regarding #2:** I’m using another workaround, which is to just go into the 
   settings of the form in the database and deleting the `input_padding` option 
   so that it doesn’t render anything on the page. This is obviously fragile in 
   that every time I have to change the settings of the form, those DB changes get
   overwritten, so I have to do them again, but it’s cleaner than writing even more
   CSS rules on top to get my desired effect.
 * The larger point in general about all the issues (except #3) is that it worked
   out that I’m technically knowledgeable, so I can do all these workarounds (setting
   aside the fact that I had to spend so much time debugging these issues and coming
   up with the workarounds in the first place); what about others who likely are
   not code-savvy at all?
 * Moreover, these are not “features” that would be “nice to have”, but _bugs_ that
   significantly affect the experience of users. They should be the highest priority
   in your task-lists/sprints, so that people can focus on using the plugin and 
   improving their website rather than fighting the plugin’s shortcomings. The fact
   that the “inline styles” issue was reported back in 2020 and it still hasn’t 
   been addressed (6 years later) is very concerning, and doesn’t bode well for 
   any “feature requests” I might report on that board. Please drop all other tasks
   and work on addressing these issues. If you need help implementing these fixes,
   feel free to reach out to me; I’d be glad to help.
 *  Plugin Author [Bruna a11n](https://wordpress.org/support/users/bruberries/)
 * (@bruberries)
 * [1 month ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18893134)
 * Hi [@getsnoopy](https://wordpress.org/support/users/getsnoopy/)! Thanks for the
   detailed follow-up and for sharing your workarounds.
 * To address your core question about whether these are bugs or feature requests:
 * Issues #1, #2, and #3 (class placement, inline padding, px-only units) — these
   are intentional design decisions made for cross-theme rendering consistency. 
   MailPoet forms need to look reasonable across thousands of themes without configuration,
   and the current approach prioritizes that. We understand the tradeoff frustrates
   developers who want tighter theme integration, and the Canny request remains 
   the best way to signal demand for changing that philosophy.
 * Issue #4 (font-family override when “Theme’s default fonts” is selected) — you’re
   right that this one is different. If the setting says “use theme fonts” but the
   CSS resets force Arial regardless, that’s a gap between what the UI promises 
   and what the code delivers. I’ll flag this specifically to the development team
   as a potential bug.
 *  Thread Starter [getsnoopy](https://wordpress.org/support/users/getsnoopy/)
 * (@getsnoopy)
 * [1 week, 4 days ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18910271)
 * Hi [@bruberries](https://wordpress.org/support/users/bruberries/), thanks for
   your answer. As a response:
 * The bug is not that MailPoet decided to choose some defaults that make sense 
   for a large number of users; it’s that it doesn’t give the ability for users 
   to opt out of the defaults that it (i.e., your team) chose.
 * The point of the template editor is to give users the ability to customize templates,
   is it not? That is, to allow them to make the forms and such blend in with their
   WordPress installation’s theme. (Even if that isn’t your goal, this indeed still
   does happen, as all of MailPoet’s templates still get the WP installation’s theme
   styles applied to them as a matter of course. And it clearly isn’t your goal 
   to completely override the styles of the host installation’s theme and solely
   use MailPoet’s custom styles.) As such, this means that what is correct behaviour
   is determined by the user’s installed WP theme, and that requires MailPoet to
   be as adaptive as possible, not to be as tight/closed as possible.
 * Things like `rem`, `em`, and `%` units all use the theme’s defaults as baselines,
   which means the styles are more adaptive. Similarly, not having a forced **Input
   Padding** means that the theme’s default styles for input elements take over 
   and the form elements look like they belong on the website…which, ironically,
   is what basically every user wants. Just the same, having the class be placed
   on the actual element being targeted (which is what the template editor UI implies,
   seeing as there’s no mention anywhere of an intrusive “Paragraph” element being
   inserted as a wrapper) allows users to target the actual element in question 
   instead of a MailPoet paragraph element that is foreign to the user’s installed
   WP theme.
 * Again, though I (and many others like me, going off your very own Feature Request
   board) clearly believe that not having these forced things as defaults is the
   best way to go, it’s fine if you want to have them as defaults (and changing 
   them would be a feature request). But to not give users an opt-out is the bug
   because you’re not allowing for possibilities your team hasn’t considered, which
   is highly likely given that—as you mentioned—there are thousands of themes out
   there, and it’s breaking layouts/styles as a result. Moreover, it seems like 
   at least one of the things I mentioned above has already been a “feature request”
   on your Feature Request board for over 6 years, to no avail.
 * Finally, I found yet another couple of style issues with your template editors:
    1. The Confirmation Email template editor (under **_Settings_** > **_Sign-up Confirmation_**
       > **_Enable visual subscription confirmation emails_**) doesn’t respect the **
       Content background** colour setting located under the **Styles** accordion header
       because there’s a `background-color: inherit` rule that’s clobbering the CSS
       style rule that sets the user-chosen background colour.
    2. The footer of the email (where the “If you received this email by mistake” text
       exists) doesn’t follow the **Text** styles defined under the **Styles** accordion
       header, nor does it allow any sort of font or other customization.
    3. The font size fields for the various textual elements (e.g., **Heading 1**, **
       Text**, etc.) are drop-down menus with fixed options instead of text boxes /
       number spinners that allow manual control, which is yet another point of frustration
       where I can’t control the text sizes in emails to match those on my website.
 * Like I said, it seems like CSS/style functionality in the plugin is broken in
   far too many places, so I would strongly recommend a sweep across your entire
   code base / feature set to make sure everything works properly.
 *  Plugin Support [Lynn J.a11n](https://wordpress.org/support/users/lynnjat7/)
 * (@lynnjat7)
 * [1 week ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18915152)
 * Hi [@getsnoopy](https://wordpress.org/support/users/getsnoopy/),
 * Thanks for reaching back out. I do understand that many of the CSS issues you
   have pointed out here work well for our less technical customers who want to 
   get a form up and going quickly, but can become roadblocks for experienced designers
   who want fine control over their form design.
 * I’ve raised three separate issues as bugs with our development team:
    - issue 1 – CSS issues with the confirmation email -> I confirmed that the background
      color is not holding and the font in the footer is not inheriting properly.
    - issue 2 – allow more flexible units such as em instead of just px for fonts
      and padding, and allow entry of any value rather than just selection from 
      a dropdown -> these are both currently the way they are as the code for forms
      overlaps with the code for the email designer, and the email designer must
      conform to greater limits to work with a variety of email readers. I will,
      however, ask the dev team if this can be changed for forms exclusively.
    - issue 3 – form elements include inline CSS and force certain elements such
      as form field padding, which makes it a challenge to choose inherited styles
      from the theme -> as you have noted, this is a requested feature on our request
      board already and thus is already a “to do” item on our developer’s list, 
      but is currently rated a low priority with no ETA. I will add your comments
      here to the open issue urging them to reconsider their priority ranking.
 * Thank you for your valuable feedback here, and it’s good to hear that while these
   tweaks would have made your life easier, your skills as a designer did allow 
   you to achieve the final look you wanted. As thousands of website owners use 
   MailPoet – the vast majority of whom do not have design skills of your caliber–
   the majority of our target market are people who do value a very simple setup
   with basic settings that will create a form quickly. As a result, issues 2 and
   3 are likely to remain a lower priority compared to important functionality for
   the plugin, but we will continue to track these issues and keep them as goals.

Viewing 6 replies - 1 through 6 (of 6 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fcss-functionality-is-broken%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/mailpoet/assets/icon-256x256.png?rev=3284564)
 * [MailPoet - Newsletters, Email Marketing, and Automation](https://wordpress.org/plugins/mailpoet/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/mailpoet/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/mailpoet/)
 * [Active Topics](https://wordpress.org/support/plugin/mailpoet/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/mailpoet/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/mailpoet/reviews/)

## Tags

 * [css](https://wordpress.org/support/topic-tag/css/)

 * 6 replies
 * 4 participants
 * Last reply from: [Lynn J.a11n](https://wordpress.org/support/users/lynnjat7/)
 * Last activity: [1 week ago](https://wordpress.org/support/topic/css-functionality-is-broken/#post-18915152)
 * Status: not resolved