Please don't hardcode essential theme specific things.

[mkkeck]

Block editor does not respect theme developers / designers work.

The Gutenberg editor has portential, is a great project and makes using WordPress really easier.

But some times its also really confusing and frustating, that the block editor does overwrite theme's styles or does not give theme developers and designers options to configure some block settings and features. Please let theme developer and designer do their work as they need, and give them more control over settings, available inspector panels and block support.

Here I write down some "specials", which are really essential for theme's specific things, I think these should be fixed.

Hardcoded social icons without available adding own services (at the moment theres a PR in work)

This is an essential theme and or plugin specific thing. Some icons for other social networks are missing and are important for theme authors and user. For example: XING is missing.

Hardcoded colors in table block

There's at the moment no option to overwrite the background colors for table cells. Users need a way to adjust these theme specific. See #32394

Hardcoded class names: has-×××-color, is-style-×××

Many theme developers using existings css frameworks (for example Bootstrap, Foundation, PureCSS, etc). It would be very good to add an option to map the naming convention of these framweworks to Gutenberg. See #11763.

The naming convention for block classes is sometimes not clear and does not allways follow BEM.

For example has-background-color-blue would be much clever as has-blue-background-color.
To explain: A user defines a color for links, and name his color "link". This results in the class names has-link-color and has-link-background-color. The problem is has-link-color is already defined by Gutenberg. Of course the user could use another name, but it would more helpfull that the generated color class names becomes has-color-link and has-background-color-link.

For text align there's still used has-text-align-left, has-text-align-right. Why not using this aproach for color settings (border, background-color, text-color) too?

Hardcoded block settings /support /features without opt-out:

For example in button block there is a width-setting panel. But theme developers designs their button in their own way, with own sizes, spacings borders etc. So authors or editors don't need, and perhabs should not, overwrite the settings.
Other example is with social link block, where authors and editors can damage theme stylings with overwriting wrong colors and or sizing. See #19796, #31310, #34575, #34557

[richtabor]

In theory, I agree with the sentiment that opinionated styles should be driven by the theme (likely via theme.json). That effort will continue to be worked on 100%.

But theme developers designs their button in their own way, with own sizes, spacings borders etc.

I think this is a remnant of pre-Gutenberg/pre-FSE themes. We want to give users the ability to customize/styles — not lock them into the theme's decisions. I agree, there will be consequences of flexing a theme's design language for user-oriented options, but in the end it's their choice.

With theme.json it is possible to control whether or not colors, borders, and other controls exist within the editor. It's still being explored in detail, so perhaps there's room for extending that to the Button block's width control (not sure though).

[mkkeck]

I think this is a remnant of pre-Gutenberg/pre-FSE themes. We want to give users the ability to customize/styles — not lock them into the theme's decisions. I agree, there will be consequences of flexing a theme's design language for user-oriented options, but in the end it's their choice.

That is right for themes, which requires customizable settings by the end-user (author, editor). But there are reasons, where options needed to disallow specific settings.
For example a big intranet blog with many authors and editors, which requires fixed settings and styles for coorporate identity, there should some not overwriten by authors or editors and of course never by Gutenberg.

With theme.json it is possible to control whether or not colors, borders, and other controls exist within the editor.

That's not really true, because at the moment, my theme.json is merged with Gutenbergs theme.json.
Styles, not needed and / or not wanted by the theme, are always available and can overwrite, which should never happen, theme styles (See #34575).

[CandaceJohnsonDesigns]

The reason for moving to more of a cascading styles approach (core -> plugin/theme -> user) is that content is highly dynamic and there are circumstances where the content requires slight adjustment. This does not mean that theme development should be lax and not style for different circumstances; after all, most users just want to add content as quickly as possible and wants everything to look good right out of the box. However, allowing minor adjustments improves user experience. Give them enough room to "grow and change", but not enough to hang themselves with...

As a theme developer, you can still control a majority of what a user can manipulate. Block supports, including custom color, gradients, typography, padding/margins can be added or removed in theme.json. All block styles can be overridden during theme development. If you do not want the block to support a specific style, for example, .is-style-outline in the Button block you can unregister it using unregister_block_style. You can even set default styles to ensure those are used primarily. Create block patterns for easy layout and style control.

The one thing I will agree with you on is there is not enough leeway with certain supports. One thing I ran into was wanting to add a "overlay effect" background-color on hover for buttons styles with .is-style-outline. I would currently need to duplicate the color as RGBA in my CSS to allow for alpha channels, which means code duplication... I also think generating these presets is easier using SASS functions... It would be great if we could hook into the generation of these somehow.

[mkkeck]

The reason for moving to more of a cascading styles approach (core -> plugin/theme -> user) is that content is highly dynamic and there are circumstances where the content requires slight adjustment. This does not mean that theme development should be lax and not style for different circumstances; after all, most users just want to add content as quickly as possible and wants everything to look good right out of the box. However, allowing minor adjustments improves user experience. Give them enough room to "grow and change", but not enough to hang themselves with...

I understand, but theme developers should have more control over all theses settings. There are some situations which require theme developers adjust theme styles, settings and allow or dissallow them.

On the other hand, I know users, which say that all the options stress them. They want only publish their content without to need to adjust every setting for every block.

As a theme developer, you can still control a majority of what a user can manipulate. Block supports, including custom color, gradients, typography, padding/margins can be added or removed in theme.json.

That's not available and supported by all blocks. The best example is the social link block, there I can not forbidden to set colors and sizes with theme.json.
Another example is the button block, where I can not forbidden the sisizng control with theme.json.

This means I have to hack these and other blocks, to remove hardcoded settings.

All block styles can be overridden during theme development. If you do not want the block to support a specific style, for example, .is-style-outline in the Button block you can unregister it using unregister_block_style.

I know. But also, this does not work complete. It does not work with registered block styles, which are registered by Gutenberg via Javascript. And I think that's nearly all core blocks? Yes I know, there is a Javascript version unregisterBlockStyle.

But with register variations and styles it is not possible to register for example a new social service for the social link block. Because these are hardcoded twice.
Means: "... all block styles can be overwritten ..." is not really true.

To remove code duplication, I would prefer, there is no core style, which I must unregister, if I don't want. I think, it would be better to put them into a json file, which is easier to edit.

For my theme, I've hacked the social link block, which reads a json file, registers the variations (services) and block styles. All done with a new PHP function to register the social link block.

You can even set default styles to ensure those are used primarily. Create block patterns for easy layout and style control.

Yes I know. But I am not sure, if I can insert the block for example in the group block or a dynamic block, in WordPress 5.6 it was not working.

UPDATE: It's working with WordPress 5.8.

The one thing I will agree with you on is there is not enough leeway with certain supports. One thing I ran into was wanting to add a "overlay effect" background-color on hover for buttons styles with .is-style-outline. I would currently need to duplicate the color as RGBA in my CSS to allow for alpha channels, which means code duplication... I also think generating these presets is easier using SASS functions... It would be great if we could hook into the generation of these somehow.

Code duplication is often done, for example see the social link block. Why the services hardcoded twice in PHP and Javascript? These does not make sense.

Also it does not make sense, that Gutenberg says, how I have to write my theme and styles. Means: I have more and more to analyse the core styles, searching for an !important to get an idea why my theme styles are not working. And please note, there are some existing themes out there, made for the current WordPress and or Gutenberg, and with next release these themes may be broken. This could hapen with merging core and theme styles and inline for example the colors, borders, fontsizes etc. with the !important flag. See #34575.

And yes of course I know many of the build tools for developing a theme: Sass, Gulp, Webpack, Babel etc.

I am not really shure, what other theme developers think. But with every new release, I think, I loose more rights to adjust settings, have more to hack and duplicate code to get only the things I really need and to get my styles work.

[CandaceJohnsonDesigns]

@mkkeck

The default behavior of the social links is to display each icon with their specific brand colors. Due to the specificity required for this, in order to override the color choice, styles must be placed inline. An alternative solution would be to extract the color(s) as a CSS custom property and incorporate a "Use brand colors" toggle in the Block settings panel.

Potential CSS Example:

:root {
    // Default Core Colors: Social Links
    --wp-block--social-links--background-color: #f0f0f0;
    --wp-block--social-links--color: #444;
}

// Core styles
.wp-block-social-links:not(.is-style-logos-only) .wp-social-link {
    background-color: var(--wp-block--social-links--background-color);
    color: var(--wp-block--social-links--color);
}

// As theme developer, you can then override the default social icon colors by 
// overriding the custom properties

.wp-block-social-links:not(.is-style-logos-only) .wp-social-link {
    --wp-block--social-links--background-color: var(--wp--preset--color--{your-color-name});
    --wp-block--social-links--color: var(--wp--preset--color--{your-color-name});
}

// Class can be added (or removed) to block props via a toggle in the Block settings panel
// If "Use brand colors" is toggled off, add color panel to inspector controls.
.has-brand-colors {

    .wp-block-social-links:not(.is-style-logos-only) .wp-social-link-wordpress {

        // Override defaults with specific brand color ONLY when toggled to use brand colors
        --wp-block--social-links--background-color: #3499cd;
        --wp-block--social-links--color: #fff;
    }
}

Then any user color selections would update the custom properties inside style attribute of the block.

const iconColorStyle = iconColor !== undefined ? {
		"--wp-blocks--social-links--color": `var(--wp--preset--color--${iconColor})`
	} : {};

const iconBackgroundColorStyle = iconBackgroundColor !== undefined ? {
		"--wp-blocks--social-links--background-color": `var(--wp--preset--color--${iconColor})`
	} : {};

return (
		<div { ...useBlockProps( ) } style={ Object.assign( {}, iconColorStyle, iconBackgroundColorStyle ) } >
			...
		</div>
	);

As for a new Social service, that would require a new Social Link Icon component and has nothing to do with styles. The Social Links block currently supports quite a few social icons links and it offers a "ChainLink" icon for any that are not supported. Injecting SVG is still considered unsafe and that is why Wordpress does not natively support uploading SVGs at this time. Unless you extend and customize the block on your own, which it seems you managed to do in some form?

In addition, Wordpress supports both PHP and Javascript versions for backward compatibility and in order to use social links outside the Block Editor ( in the Footer or Header, for example). Eventually Wordpress will move to a complete FSE experience and blocks could be used for the entire site, but we need PHP versions for this application of social links at this time.

Using the custom properties technique above, it may be possible to remove the need for !important overrides, which can be messy to work around.

[mkkeck]

@CandaceJohnsonDesigns
It does still not make sense, that social services have to be written in js and php. Here's a solution how could it be done:
#19041 (comment)

Than your code sample does not work on IE11 and/older MS Edge. Perhaps that may be important to users, which still need supporting such browser on front end side.

The other point is, your solution is a next step in code duplication. Why should I accept, that always core styles are loaded, which I have to overwrite with own styles? It does not make sense, loading styles, for example for social services, twice (the core and mine).
So, that's why I'm asking for hooks to disable loading core styles.

[CandaceJohnsonDesigns]

Wordpress 5.8 dropped support for IE11 and older : See here.

So if you are utilizing theme.json, custom properties are being generated and used already.

As a developer, I prefer having base styles and overriding as needed and loading in these base styles is not very expensive.

[mkkeck]

Wordpress 5.8 dropped support for IE11 and older : See here.

Yes, per core styles, and mainly on backend.
Found on your reference site:

Themes typically have their own browser support policies, and changes in WordPress Core do not affect those

It is still possible to write themes and styles supporting these browsers. And it should be still possible for special situations.

So if you are utilizing theme.json, custom properties are being generated and used already.

Yes I know, and of course this is often "buggy". See #34575. WordPress or Gutenberg should never style the front end, it should still be done by themes.

As a developer, I prefer having base styles and overriding as needed and loading in these base styles is not very expensive.

Thats what I also do, but when I overwrite many styles than perhaps I don't need the core styles be loaded. It does still not make sense loading styles for same things twice.

[mkkeck]

As for a new Social service, that would require a new Social Link Icon component and has nothing to do with styles.

I know.

The Social Links block currently supports quite a few social icons links and it offers a "ChainLink" icon for any that are not supported.

I know this also.

Injecting SVG is still considered unsafe and that is why Wordpress does not natively support uploading SVGs at this time.

With a SVG sanitizer injecting and uploading SVG is not really unsafe. There are plugins available, and of course it would be easy to intergrate such functionality into WordPress core.

Unless you extend and customize the block on your own, which it seems you managed to do in some form?

Of course, so I've started this issues.

In addition, Wordpress supports both PHP and Javascript versions for backward compatibility and in order to use social links outside the Block Editor ( in the Footer or Header, for example). Eventually Wordpress will move to a complete FSE experience and blocks could be used for the entire site, but we need PHP versions for this application of social links at this time.

Thats not the point. The point is code duplication of settings for some blocks. Means, write the same config for PHP and Javascript twice. That does not make sense. And of course it does not make sense that it is hardcoded, e.g. for the social link block.