A couple questions about styles in the Wordpress block editor

[DylandeBruijn]

Hi Greg and the community,

A couple questions about the usage of styles in the Wordpress block editor:

• I'm using ACF custom blocks and Tailwind Typography is setting the styles for the content (headings, paragraphs, lists) in these blocks. What's the best way to go about this? Should I set default styles (reset) every time I make a new block? Should I replace the xxx_content_class('entry-content') function in content-page.php with class="entry-content"?
• The font-family in the Wordpress block editor is serif for me. When I try to set it to sans-serif in base.css it doesn't get inherited. Basically how do I go about making the styles in the Wordpress block editor as close to the styles on the front-end?
• I'm trying to find a good standard for Wordpress development at our agency. What do you generally use? FSE, classic or hybrid themes? Do you have a repo of an example project I could learn from?

Thanks in advance!

[DylandeBruijn]

I checked the styles that are applied in the Wordpress block editor and I'm wondering where these styles are coming from and how I can reset them like how Tailwind preflight does for the front-end. Or is that a bad idea?

:where(.editor-styles-wrapper) h1, :where(.editor-styles-wrapper) h2, :where(.editor-styles-wrapper) h3, :where(.editor-styles-wrapper) h4, :where(.editor-styles-wrapper) h5, :where(.editor-styles-wrapper) h6 {
    color: revert;
    font-size: revert;
    font-weight: revert;
    line-height: revert;
    margin: revert;
}

This is one of my custom blocks:

<?php

/**
 * Icon With Content block template.
 *
 * @param array $block The block settings and attributes.
 * @param string $content Inner blocks content if jsx is enabled
 * @param boolean $is_preview True during preview render
 * @param array $context any context variables from parent blocks if applicable
 */

$wrapper_attributes = get_block_wrapper_attributes(
	array(
		'id'    => $block['anchor'] ?? '',
	)
);

$icon = get_field('icon');
$title = get_field('title');
$content = get_field('content');
?>

<?php if (! $is_preview) : ?>
	<div <?php echo $wrapper_attributes ?>>
	<?php endif; ?>

	<div class="bg-ruby font-sans py-24 not-prose">
		<div class="max-w-content mx-auto has-global-padding">
			<div class="flex flex-col justify-center items-center text-center gap-8">
				<?php echo wp_get_attachment_image($icon, 'full', false, array('class' => 'size-[80px] object-contain object-center')) ?>
				<h2 class="text-4xl font-medium text-blush font-serif"><?php echo $title ?></h2>
				<?php if ($content) : ?>
					<div class="text-xl text-blush space-y-8">
						<?php echo $content ?>
					</div>
				<?php endif ?>
			</div>
		</div>
	</div>

	<?php if (! $is_preview) : ?>
	</div>
<?php endif; ?>

[gregsullivan]

Hi Dylan—Thanks for posting this! I'll go through your bullet points in order:

• I think what you might be looking for here is the not-prose class. You can read about it in the Tailwind Typography README file.
• This should be working out of the box with _tw. I've tested previously, and the block editor will use sans-serifed type by default, but changing to serifed in base.css will switch the block editor as well. It would be worth looking at which styles are being applied in the block editor to see where the serifed font is coming from if you've set a sans-serif one in base.css.
• _tw is a hybrid theme, which continues to be my approach at this point. FSE is going to get there in time, but I'm not using it for client work yet. I also get the impression development has slowed down with the reduction in contribution from Automattic.

I think it's worth trying not-prose, in terms of your second comment. That might solve your problems. If not, it would be worth investigating where the other styles are coming from and working from there.

Hope that helps!

[DylandeBruijn]

No problem! I appreciate you taking the time to continue to look into this.

[gregsullivan]

What are you seeing when you try? I generated a fresh theme and copied all of your code over to mine. I added it alongside some core blocks:

(Your block is at the very bottom.)

I'm using ACF Pro 6.3.12 with no other plugins active, core version 6.7.2.

[DylandeBruijn]

Hi Greg, sorry I had a busy week.

Here is what it looks like in the Block Editor for me:

When I inspect my ACF block it has the default browser margins because these have been reset by load-styles.php. See the image below and notice the style block:

When I check the blocks in the front-end this is what it looks like:

Notice the lack of margins on the ACF block due to the CSS reset coming from Tailwind preflight.

The styles of ACF blocks in the block editor and front-end are out of sync for me. ACF blocks in the editor get different styles in the editor compared to the front-end.

I use ACF Pro 6.3.12 and WordPress 6.7.2, the only plugin I have active is ACF Pro.

[gregsullivan]

So I see this as a bit of a good-news, bad-news situation:

• This now looks right to me to the extent that things aren't outright broken as they were originally, and you're seeing the same thing I am.
• I hadn't noticed some of the subtleties of your test: You're hoping to see a purely unstyled h2 in the block editor after switching to not-prose.

I was stuck on fixing the bug that was affecting things originally—when nested CSS broke the block editor when it was loaded outside of an iframe—so I missed the finer points of the latter issue.

This is something that you'll get hit with in other places, too. Outside of the reset, there are other styles supplied by the block editor that need to be specifically overridden to make things look the same on the front end and back end. As a specific example, you can see some of that happening in these styles that are part of the _tw additions to Tailwind Typography:

https://github.com/gregsullivan/_tw-typography/blob/53c84808ca3d920dc14f2b7bd419539249b18758/index.js#L125-L164

In the case of your h2, you basically need to explicitly set the color, line height, margins, font size and font weight if you're not setting them elsewhere. So, for example, you should still be getting the color value you set for body, and the same could be true for other values. But I have definitely needed to be more explicit with some of these to ensure the block editor and front end match up. I'll generally just leave the unnecessary styles on the front end, though there typically aren't actually very many: I'd be setting the margins, font-weight, font-size, etc., on the front-end anyway. So it's just something I'll do on a block-by-block basis as I go, and I'd say it's normally zero added classes, and I don't think more than one or two if I do need to add something.

Please let me know if that all makes sense, or if there's anything I'm misunderstanding!

[DylandeBruijn]

Hi Greg, thank you for your thorough reply!

Most of it makes sense to me.

Couple questions:

• Is it possible to run Preflight in the block editor as well? Or is this a bad idea?
• Do you have an example where you put the reset for the block editor in your projects?

What I would like - in a perfect world - is to run a reset like Preflight in both the front-end and the block editor if possible.

[DylandeBruijn]

Hi Greg, I also noticed something else in the editor:

This is what an ACF block in edit mode looks like when I'm not selecting it:

Notice the # next to "Read more" coming from this style block

:where(.editor-styles-wrapper) .prose-a\:text-primary :is(:where(a):not(:where([class~="not-prose"],[class~="not-prose"] *,[class~="acf-block-body"][class~="is-selected"] *))) {
    color: var(--color-primary);
}

This is what an ACF block in edit mode looks like when I'm selecting it:

Notice the # Next to "Read more" coming from this style block

a {
    color: #2271b1;
    transition-property: border, background, color;
    transition-duration: .05s;
    transition-timing-function: ease-in-out;
}

There is a noticeable change in styles. The font-size and font-weight of the text in the ACF repeater field changes as well for example.

In my mind I expect the styles between the front-end and block editor to work as follows:

• ACF blocks in the block editor and in preview mode should look like how they do on the front-end for a nice editor experience. Of course there are exceptions when you want to override the block styles in the editor when the need arises (slider block for example).
• ACF blocks in the block editor and in edit mode should have the default ACF styles, these should not be touched by Wordpress default styles or the theme.
• Core blocks should have the styles set by Wordpress or coming from theme.json
• Classic content / WYSIWYG content / non-block content should be styled by Tailwind Typography using prose.

Let me know your thoughts about this.

[gregsullivan]

Hi Dylan,

Just following up to let you know that all of these changes have now been made, either in @_tw/typography, or in _tw itself.

If you ever get a chance to give the new version a spin, I'd love to hear your feedback!

[DylandeBruijn]

Hi Greg,

That's funny, I was literally looking over this issue again yesterday. The frontend is absolutely fine but I still run into some issues in the backend (block editor) during preview mode for ACF blocks. Most of it is CSS specificity issues. For example if I want to reset the styles for ACF blocks by assigning them to the .acf-block-preview class they overwrite the Tailwind utility classes I use in the block due to higher specificity. Another issue is Wordpress CSS classes with higher specificity overwriting my Tailwind utility classes in my blocks.

Example of this problem, the following Tailwind class is set on an image used in my ACF block:

:where(.editor-styles-wrapper) .h-full {
    height: 100%;
}

But it gets overwritten by this Wordpress class due to higher specificity.

.block-editor__container img {
    height: auto;
    max-width: 100%;
}

I'll give the new version a go and let you know my findings!

[DylandeBruijn]

Hi Greg,

I just merged and tested your changes and they do fix some of the issues. I made some custom changes for my project but the Preflight styles now get correctly applied in my .acf-block-preview classes. However the issue of Wordpress classes sometimes overwriting Tailwind classes due to a higher specificity persists.

I've been thinking about this and an obvious solution could be to make the Tailwind classes always have a higher specificity by using !important. But I expect this to cause it's own set of problems, loss of style inheritance for example. I'll test this and see how it goes.

Another solution could be to configuring Tailwind to prepend a higher-specificity selector to all of its utility classes. This selector then needs to be added to root of the website and block editor so the Tailwind classes are still usable. I only found resources mentioning this in older Tailwind versions, I have no idea if this is still possible in Tailwind 4. Maybe PostCSS can help?

https://tailkits.com/blog/tailwind-important-selector/

Thank you for the update, I appreciate your work and I'm happy with the rest of the theme. It has improved the efficiency at our agency by a lot.

[DylandeBruijn]

I've added important to my utilities in the tailwind.css file and it fixed the issue for the moment. Still testing.

@import "tailwindcss/utilities" important;
@import "./tailwind/custom/utilities.css";

[gregsullivan]

Please let me know how your testing goes! Tailwind 4 does allow prefixing, but it doesn't change the specificity.

Using PostCSS to wrap everything is non-trivial, as you end up capturing things like Preflight, where we don't want to increase the specificity.

One option might be to conditionally wrap that part of tailwind.css in a selector:

@if $target != editor {
	@import "tailwindcss/utilities";
	@import "./tailwind/custom/utilities.css";
} @else  {
	.entry-content {
		@import "tailwindcss/utilities";
		@import "./tailwind/custom/utilities.css";
	}
}

[sidonaldson]

Just to jump in here, as I have a similar expectation. New to _TW.

I generated my theme, added custom fonts and overrode the values

/**
 * Add your theme below:
 */
--font-sans: "American Grotesk";
--font-serif: "Martina Plantijn", serif;

The front end immediately picks up these fonts but the backend doesn't. The block editor is still the default Wordpress fonts.

I can see the blocks in the editor are wrapped in the prose class but it doesn't seem to do anything. My expectation would be they do and from reading above that's what Dylande would like as well. Wrapping custom blocks in no-prose to revert it.

I realise it's a complex issue but must be a common expectation, is the recommendation to leave the editor fonts as-is?

[gregsullivan]

Hi Simon—Thanks for this! Can you confirm whether your theme contains a postcss.config.mjs file in the project root? If not, it might be that you're using a version of the theme generated before I fixed Dylan's initial issue above.

If you do have a postcss.config.mjs file in your project root, please open an issue and tell me more about your project configuration, as what you described above should already be working.