Because the layout wrapper HTML is not post-processed after moving content rendering, I needed to use VariablesPostprocessor because padding can be configured by a CSS variable.
[MAILPOET-5640]
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
This is a continuation of the idea of separating content rendering
and adding content to the HTML template.
I assume that in the future, we may move more parts from the renderer
to the content render (e.g. we may introduce a block for layout wrap).
[MAILPOET-5798]
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]
This commit adds a method that returns map of CSS variables and their values defined based on the theme.json
It is a preparation step for a postprocessor that will use this map to replace variables with values in final HTML.
There are many clients that don't support CSS variables
[MAILPOET-5918]
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]
