concepts about theme integration with the editor

[joyously]

Reading the Gutenberg Handbook, it seems that theme integration is all backward.
Here is an alternative version of how it could work:

1. Opt-in features
   wide alignment - This feature should consist of adding a class to a block, and using built-in styles to represent the visual effect in the editor. The theme should not have to code a add_theme_support() call. If the theme provides a style for that class, it does. If it does not, it isn't styled. That's just how thealignleft and alignright classes work today with all themes.
   Block Color Palettes - This feature should not be generating dynamic class names. The editor should have some number of class names by default, that the theme styles (or not). By using different class names, the user is encouraged to have posts with many different classes. It should be the other way around. The classes supplied should be named for the "type" of style, not the specifics of the style. An example would be 'highlight' or 'stand-alone' or 'fine-print', where the theme can choose to style those with colors or sizes or margins, etc. The idea is to be consistent, so that changing themes does not involve fixing all the old posts with orphaned class names. If these were inline styles, that would be different, but also not really a good choice. Again, there is really no need for the theme to need to use add_theme_support(). This is a good place to consider using CSS Custom Properties.
   Block Font Sizes - This feature is similar to the color palette. There should be default class names and corresponding indicator on the font size interface component, but the user should not be encouraged to use class names tied to a theme (that would then be unstyled when the theme is switched). The theme can style the default classes without add_theme_support(). Also, absolute font sizes should not be used in examples.
   Disabling custom colors - Saying that a theme supports disabling custom colors is quite convoluted. I'm not sure I understand the intent here. Having anything in the editor dependent on the theme is a bad idea, because the user can change themes every day, but that should not affect how they edit their content. This whole concept should be removed. (See above).

2. Editor styles
   It says "You can use this to change colors, fonts, and any other visual aspect of the editor." But this is a departure from years of standards that the theme should not style the admin. The theme should style the content in the editor, but not the editor itself.
   Add the stylesheet - if this is still referring to styling the editor, it should under Plugins. Otherwise, the process of styling the content already exists as add_editor_style(), which should continue to work. It would be up to the theme to ensure that the stylesheet referenced will work with the new editor.
   Basic colors - Is this name(body.gutenberg-editor-page) going to change? Is it referring to the whole page or just the content? This is another area that would be good for using CSS Custom Properties.
   Changing the width - Why isn't Gutenberg using the global content_width? Themes already define it.

3. Default block styles - This is backward! If the theme is keeping up with current development, why would it want to add_theme_support( 'wp-block-styles' )? It's the themes that are not keeping up that need this by default. This way, the user can use the new editor without changing themes. This should be opt-out if there are truly styles that the blocks need to work. If the styles are not required for functionality, then why have them at all?

[jasmussen]

Hi Joyously, thanks for your thoughts.

wide alignment - This feature should consist of adding a class to a block, and using built-in styles to represent the visual effect in the editor. The theme should not have to code a add_theme_support() call. If the theme provides a style for that class, it does. If it does not, it isn't styled. That's just how thealignleft and alignright classes work today with all themes.

Back when we added this a while back, there was a lot of discussion with good arguments on both sides. The primary reason we ended up with this add_theme_support call was because nearly all existing WordPress themes won't know what to do with wide and fullwide alignments. That means a user of that theme will press the wide button, see a change in the editor but no change on the front-end, and possibly complain to the theme developer. Given how many themes there are, it seemed good to make a single line of text you could paste into functions.php to explicitly tell the editor: yep, we can handle wide and full wide!

Block Color Palettes - This feature should not be generating dynamic class names.
Block Font Sizes

I'm pretty sure there is a separate ticket discussing this, though I can't recall if that's resolved yet. Maybe this one? #2862

I'd like to keep feedback grouped on tickets so as to not fragment discussion and lose context of past decisions.

Disabling custom colors

There have been many past discussions about giving more control to theme developers to ensure a cohesive visual look. For example a small WordPress shop might be making a highly tailormade theme for a client, and they want to make sure only brand colors are used. In those cases, this optional function call can be a life saver for theme developers.

this is a departure from years of standards that the theme should not style the admin

Correct. This enables a far more detailed styling of editor content, so it can match the front-end and help create a connection between the two. Long term one hope is to make it so a separate editor stylesheet isn't necessary at all, but the theme stylesheet itself can be loaded.

Basic colors - Is this name(body.gutenberg-editor-page) going to change? Is it referring to the whole page or just the content? This is another area that would be good for using CSS Custom Properties.

I would think so. See #4681. But in the next release or two, it should also be unnecessary to include that class, and it should become sufficient to style the body, per #9008. So we'll need to update the docs once the dust settles from that change.

Changing the width - Why isn't Gutenberg using the global content_width? Themes already define it.

There are quite a few discussions open on this topic, and several closed. I would recommend giving feedback on, for example, #5650.

Default block styles - This is backward! If the theme is keeping up with current development, why would it want to add_theme_support( 'wp-block-styles' )?
This should be opt-out if there are truly styles that the blocks need to work. If the styles are not required for functionality, then why have them at all?

This was discussed and decided here. But to answer your question, the only styles that are "opt-in" here are opinionated styles. For example the blockquote in Gutenberg ships with a black left border — this is opt in, because most themes have already styled the blockquote. However the variations of blockquote are not opt-in, so if those variations are chosen they will work in the theme even if the theme hasn't styled that variation. In other words, there are no structural styles that are needed for the block to work in the opt-in files.

[jasmussen]

Given the discussions referenced and the fact that #9534 was opened before this, I'm going to close this one so as to not fragment the conversation. Please feel free to add your thoughts to that ticket as well.

If this was in error, we can always reopen!