Because we want to have all editor configurations in theme.json, I moved heading font sized to theme.json and removed redundant filters.
[MAILPOET-5640]
When only the radius was defined, we set border solid and it caused
that sometimes it was rendered even when the width was not defined.
Overflow hidden ensures that inner link element doesn't break the border radius.
[MAILPOET-5907
Content renderer - renders the content of the email post
Renderer - places the content into the email HTML template and generates text version
[MAILPOET-5798]
When the border color is not set, a block uses text color as a fallback.
This was not working properly for the button block when the font color was picked from the color palette.
This PR fixes the issue and adds the proper border color class.
[MAILPOET-5919]
Instead of using our own logic for building padding style definition,
we switch to wp_style_engine_get_styles which generates the styles definitions for us.
It also handles value variable formatting to valid CSS (var:preset|spacing|50 to var(--wp--preset--spacing--50)).
[MAILPOET-5918]
Initially, I tried to place the definition to theme.json
(It could set it in styles.block.core/heading or styles.elements.h1...)
It was not possible to use theme.json because of the fluid typography
feature which, when enabled for a site, causes font sizes to being
converted to the fluid definition (clamp(x, y, z)) and which
is not usable for an email due to very little client support.
We need to make some changes in Gutenberg to be able to disable the feature.
Currently, the code for generating font sizes in CSS generated from the theme.json
looks directly at the global settings of the site.
[MAILPOET-5740]
Default background rendering has to be handled on the button renderer level
because of a specific markup for Outlook (bgcolor attribute). Default text color and paddings are
handled via CSS inlining. That's why they are tested in RendererTest
I used the same background color and font color as the one defined for the button
element in WP core theme.json, and I also used similar padding values
(In core they use "calc(0.667em + 2px) calc(1.333em + 2px)")
[MAILPOET-5814]
We don't reset font family on any level, so there is no need to
bubble the setting using a preprocessor and render the inline styles
explicitly in every block.
In this commit, I change how font-family settings are distributed/rendered
in the email renderer. In the new approach, we rely on class names defining font-family
and a generated CSS sheet with font-family definitions.
We apply the font-family CSS by inlining CSS rules for families in the later phase of
rendering after all individual blocks are processed.
[MAILPOET-5740]
