New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃枍 Styling #9534

Open
mtias opened this Issue Sep 1, 2018 · 9 comments

Comments

Projects
None yet
6 participants
@mtias
Contributor

mtias commented Sep 1, 2018

Previously #5360

I'd like to define some areas of work around theme styling that go beyond WordPress 5.0. During the last 37 releases we have seen how the existing pieces interact together, so we should have a clearer idea of what has been working and what needs another look. While some of these tools and functionalities are already in place or underway, their full deployment will continue into the next phases of the project.

That means not everything has to be resolved now but we should make sure that the path forwards is one that can reach a fruitful destination one step at a time.

Strategy

  • Editor Styles. Gutenberg has allowed customizing how blocks look in the editor since the very beginning, but the mechanisms for doing so face some of the inherent problems of the cascade when we are working with a component mindset; on top of the structural differences between back-end and front-end. We need a better longer term solution and a smooth developer experience. The exploration in #9008 is looking very promising in reducing the amount of playing-the-CSS-specificity-game themes would have to do otherwise, while also avoiding coupling with any specific DOM structure. It also paves the way for an even more robust solution in the future once Shadow DOM is ubiquitous enough that we can rely on it for style encapsulation.

  • Block Style Variations. This Is an API that evolved relatively late in the process as a way to offer simple yet expressive customization mechanisms (#783, #7362). It allows registering new styles for blocks that are entirely based on class names. This needs to be expanded from a developer perspective (in JS it exists as wp.blocks.registerBlockStyle( 'core/quote', 'fancy-quote' );) so that block styles can be registered for any existing block from the server. Might be interesting to see if it can be tied closer with the above point about editor styles sot hat they can show in "block previews", etc. See further tasks in #7551:

// Server
add_block_style( $block_name, array(
    'class' => 'my-class',
    'title' => __( 'My Style' ),
) );
// for both editor and front-end
.{block-name}.is-my-class-style {
    color: blue;
}
  • Theme Support. There are a few aspects of customization that have been added as add_theme_support() calls (colors, fonts, wide alignments). There's also a discussion point about consolidating these declarations at #8732. However, theme support is problematic on a few fronts. It's unaware of context, which means supporting something like "wide" alignments doesn't take into account that "wide" might be contextual to the block nesting level you are operating at. Consider a case where a theme has two templates, a single column one and one with a sidebar. Whether adding content to the main column should have access to "wide" alignments depends on which template is being used. More importantly, with the addition of blocks like Columns or Section, it becomes evident that these alignments only make sense, as so far specified, when used at the root of the block list. As soon as blocks are added within multiple layers of nesting, the wide alignments cannot reflect the presentational intention anymore. This means that such a set of properties ought to be more flexible, depending largely on the context of the current InnerBlocks. Here are a few thoughts on how this could be developed:
    Absorbing add theme support as InnerBlock properties.
    Allowing themes to more flexibly define these properties through templates. See also #3588.

  • Colors, Fonts, & Configuration. The aspect that mostly makes sense of add_theme_support is one of configuration 鈥 a theme can specify which colors should cascade down to blocks, what base font sizes should be used, etc. Yet again, this is a bit of a heavy handed approach, because it's conceivable that the "colors" array should be contextual to InnerBlocks too. Imagine a theme with a dark sidebar and a white main column: the colors available to use when a block is in the context of the sidebar might need to be different than those offered when blocks are being used on the main content. Likewise, which colors are shown to the user might also be block contextual. My impression is that almost everything that we generally place as add_theme_support might actually be better expressed as properties of blocks / layouts / templates.
    Related action item in #7553.
    Colors documentation in #7906.
    Alignments in #9481.

  • Widths & Responsiveness. WordPress has historically relied on a global variable called $content_width to allow themes to express their intended content width. This variable has proven to be awkward to use since the early days of responsive web design given its static nature. It's common to see themes write a mixture of checks around this variable to try to contextualize it. This is an area where the first point about editor styles is going to help tremendously, because now the theme can express container widths just through CSS as if it were the theme itself. The ongoing work around responsive images also ties into this.

Action Plan

Apart from introducing the changes in #9008 and refining #8732, I'd love to open the strategy outlined above for general discussion. What do you think? Any other ideas?

@mtias mtias added the Customization label Sep 1, 2018

@pascalknecht

This comment has been minimized.

Show comment
Hide comment
@pascalknecht

pascalknecht Sep 1, 2018

I have another problem with styling: The styles of Gutenberg leak outside the editor. It would be great to prevent this. What do you think about it?

pascalknecht commented Sep 1, 2018

I have another problem with styling: The styles of Gutenberg leak outside the editor. It would be great to prevent this. What do you think about it?

@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Sep 5, 2018

Some of this sounds very similar to what I put in #9555

joyously commented Sep 5, 2018

Some of this sounds very similar to what I put in #9555

@0aveRyan

This comment has been minimized.

Show comment
Hide comment
@0aveRyan

0aveRyan Sep 6, 2018

Member

Related to @pascalknecht leakage callout is the main body.gutenberg-editor-page selector and potential codename deprecation.

As mentioned in #4681 in my recent comment, I'd advocate this string change sooner-than-later if deprecation is the final decision.

Member

0aveRyan commented Sep 6, 2018

Related to @pascalknecht leakage callout is the main body.gutenberg-editor-page selector and potential codename deprecation.

As mentioned in #4681 in my recent comment, I'd advocate this string change sooner-than-later if deprecation is the final decision.

@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Sep 7, 2018

Joen closed my issue about the same stuff, so I'm putting my thoughts here.
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?

joyously commented Sep 7, 2018

Joen closed my issue about the same stuff, so I'm putting my thoughts here.
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?

@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Sep 7, 2018

I think it's important to keep a clean distinction between WP themes and WP plugins. WP themes should not be making blocks or styling admin areas or providing much beyond a stylesheet. The things that are called add_theme_support() are "theming" from an editor viewpoint, but should really happen in plugins.
It is important that the user is not tied to a theme, as in colors specifically loaded on certain pages. The styling should be generic classes that any theme can choose to style or not (since the user can put the style in Additional CSS). That brings up the question of how a user can get his Additional CSS rules into the editor easily.

joyously commented Sep 7, 2018

I think it's important to keep a clean distinction between WP themes and WP plugins. WP themes should not be making blocks or styling admin areas or providing much beyond a stylesheet. The things that are called add_theme_support() are "theming" from an editor viewpoint, but should really happen in plugins.
It is important that the user is not tied to a theme, as in colors specifically loaded on certain pages. The styling should be generic classes that any theme can choose to style or not (since the user can put the style in Additional CSS). That brings up the question of how a user can get his Additional CSS rules into the editor easily.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Sep 7, 2018

Contributor

I think alignment options in general should be context-dependent. There should be no main on/off switch in the theme. Instead, it should be up to the InnerBlocks or post template. Actually, the post template is kind of like one big InnerBlocks, is it not? Wide/full alignments do not make sense in a column, and even left/right float alignments do not always make sense in some contexts.

I agree that having nonessential default block styles is rather weird. Those should be in a Twenty Eighteen theme or something. Styles considered essential should be the only styles, and you should still be able to opt-out or at least fully override (as in no need for higher specificity) those styles. There should definitely be no opt-in nonessential styles.

Contributor

ZebulanStanphill commented Sep 7, 2018

I think alignment options in general should be context-dependent. There should be no main on/off switch in the theme. Instead, it should be up to the InnerBlocks or post template. Actually, the post template is kind of like one big InnerBlocks, is it not? Wide/full alignments do not make sense in a column, and even left/right float alignments do not always make sense in some contexts.

I agree that having nonessential default block styles is rather weird. Those should be in a Twenty Eighteen theme or something. Styles considered essential should be the only styles, and you should still be able to opt-out or at least fully override (as in no need for higher specificity) those styles. There should definitely be no opt-in nonessential styles.

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Sep 8, 2018

Contributor

I just want to highlight that different types of themes have different needs. A highly custom purpose-built theme for an enterprise site has very different needs from a commercial theme distributed in the theme directory. The idea of portability from theme-to-theme is totally unnecessary (and possibly even detrimental) for enterprises, but of critical importance to individual users. I'm not sure how to reconcile those two cases, but it's important to note.

I also think it's clear that, in some ways, Gutenberg is really exposing the limitations of add_theme_support. That's more of a Core problem than a Gutenberg problem, but it definitely is worth considering as we think through the ways you might interact with theme settings.

Contributor

chrisvanpatten commented Sep 8, 2018

I just want to highlight that different types of themes have different needs. A highly custom purpose-built theme for an enterprise site has very different needs from a commercial theme distributed in the theme directory. The idea of portability from theme-to-theme is totally unnecessary (and possibly even detrimental) for enterprises, but of critical importance to individual users. I'm not sure how to reconcile those two cases, but it's important to note.

I also think it's clear that, in some ways, Gutenberg is really exposing the limitations of add_theme_support. That's more of a Core problem than a Gutenberg problem, but it definitely is worth considering as we think through the ways you might interact with theme settings.

@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Sep 9, 2018

different types of themes have different needs.

I think you are mistaking themes and plugins. The theme's job is to present the content for the current page request. Period. Entering content into the editor, and having a library of custom blocks to use is all the job of core and plugins.

Gutenberg is really exposing the limitations of add_theme_support.

I disagree with this. Gutenberg is using it for plugin support, when it is intended for themes. It is just a global variable to hold some values. Nothing else is really needed.

joyously commented Sep 9, 2018

different types of themes have different needs.

I think you are mistaking themes and plugins. The theme's job is to present the content for the current page request. Period. Entering content into the editor, and having a library of custom blocks to use is all the job of core and plugins.

Gutenberg is really exposing the limitations of add_theme_support.

I disagree with this. Gutenberg is using it for plugin support, when it is intended for themes. It is just a global variable to hold some values. Nothing else is really needed.

@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Sep 28, 2018

Aren't the Gberg styles for front end just a function call in PHP?
Does it make sense for this to be a theme decision?
Does it make more sense for this to be a per post decision by the user?
Would it make sense for Gberg to facilitate this instead of push it off on the theme? (and the editor running in non-WP context might not have a theme to do it?)

joyously commented Sep 28, 2018

Aren't the Gberg styles for front end just a function call in PHP?
Does it make sense for this to be a theme decision?
Does it make more sense for this to be a per post decision by the user?
Would it make sense for Gberg to facilitate this instead of push it off on the theme? (and the editor running in non-WP context might not have a theme to do it?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment