CSS functionality is broken

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:

.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;
}

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.

Hi @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.