search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.52k stars 4.2k forks source link

Blocks and Theme Styling Overview #5360

Closed mtias closed 6 years ago

mtias commented 6 years ago

This is an overview of theme related considerations for Gutenberg as gathered after several months of testing and feedback.

WordPress Block Styles vs Theme Styles

During the evolution of Gutenberg we have introduced several blocks with somewhat opinionated styles (quote, pullquote, separator, etc). We have seen how some themes really don't want these — they might conflict with their base styles — while other themes really want to build on top of them (particularly new themes). We have opted to disable the opinionated styles for some of the blocks that map to HTML primitives, like blockquote, because almost every theme defines those for themselves and would be tough to accommodate all conflicts. This has meant we have prevented new themes from reusing the styles that appear on the editor for all these elements. We are seeing some vanilla themes that do want these styles and would rather just customize on top of them.

This means we are looking at a split between themes that don't want any visual style (not considering structural ones here, like columns, galleries, etc) coming from core blocks and themes that do want these styles as their base. It seems we should figure out a way to accommodate both needs.

Anatomy of a Block's Style

Currently we define block styles in two stylesheets: "style" and "edit". The main problem is that if we want to supply visual styles to some themes, we cannot split them from structural styles that should come for all themes easily. So I am proposing we look at establishing three separations for block styles:

With these separations we can always include the base styles for all themes, but make theme styles optional. A theme would have to do something like add_theme_support( 'wp_block_styles ' ) to load these if they want to. (Bonus points if through the structure of theme.scss we could find easier ways for a theme to supply their own styles to the editor. Imagine having a blocks folder under your theme where you can add a css/scss file per block which is used to concatenate into the editor, but I digress.) During build, we should include the visual styles in a separate stylesheet.

Previous: https://github.com/WordPress/gutenberg/issues/2905

Classes vs Inline Styles

A similar split exists between basic and advanced customization options. We have a couple blocks that have a fair degree of styling possibilities around colors and font sizes. We allow themes to disable custom colors and to register their own already. We are also looking at providing an array of font sizes that would map to classes is-small-text, is-regular-text, is-large-text, etc, so themes can dynamically set these values. The ability to set custom values is still welcomed for various contexts, so it's looking like the best separation is:

For basic we avoid all saved inline styles, and advanced is something that could be disabled by a theme or plugin if necessary.

Colors

Would be registered assigning a name to each color value. The name would be used to construct a .has-color-{name} class as well as show a tooltip for accessibility.

$colors = array(
    'Blue' => '#00B1D4',
    'Violet' => '#934ED4'
);

Applying one of these colors won't generate any inline style. See https://github.com/WordPress/gutenberg/pull/5273

Fonts

In the case of fonts, there'll be a set of predefined sizes that would map to classes. The set would be provided as an array of values which would be used to generate the value in the editor, while the only thing saved would be the corresponding class (i.e is-small-text, is-regular-text, is-large-text, is-larger-text).

The UI would be close to this proposal:

image

See https://github.com/WordPress/gutenberg/pull/5269

This issue will be updated with further details as they come by.

StaggerLeee commented 6 years ago

Please don't forget what value it is in GUI, for font-size: em, px, pt, percent.

bordoni commented 6 years ago

It would be incredibly useful for plugins too, having the information if a given theme chose to style the blocks, in one method from WP core.

karmatosed commented 6 years ago

I really like the three separations (style, edit, theme) for style files. This feels like a robust pattern going forward.

On the font UI, lets iterate a little on styling with the reset being the same, but that's a minor issue.

aristath commented 6 years ago

About the font-sizes controls: I've seen a number of tickets here that all use a numeric field (slider etc) for font-size. However that assumes that the user wants to use pixels... and that's just wrong. I haven't used pixels for typography sizes in years, I prefer using em or rem depending on the use-case. Others prefer using % values, WCAG uses pt for its calculations so in some sites it's more convenient to use that unit and so on. There are many valid scenarios for each CSS unit, px is only good for a subset of those scenarios. We should not restrict our users to using px.

mtias commented 6 years ago

The value doesn't currently have a unit on purpose.

samikeijonen commented 6 years ago

Seems like a great approach! Will ask questions later on.

delucks1 commented 6 years ago

Hi, I just found your discussion on editor / block styles (typo and color) and wonder, if and when you plan to roll out the function in the plugin. Else is there a possibility for me as a beginner in theme development to try that already?

kanishkdudeja commented 6 years ago

I've been thinking about this and had a few questions:

mtias commented 6 years ago

These opinionated visual styles will only apply to the front-end or the editor as well?

Both. An example is the quote style, that has a left border and some color choices. This currently don't apply on the front-end equally.

will those theme-supplied styles only augment block styles supplied by WordPress core?

Probably should be generic enough to apply to any block.

Or will those theme-supplied styles be the only source of truth (meaning block styles supplied by WordPress will be discarded) ?

If the theme doesn't opt in into having the default block styles, these won't be loaded. Shouldn't matter what we do with theme-supplied styles in that case.

mapk commented 6 years ago

I like the separation of stylesheets. My only suggestion would be changing the name of edit.scss to editor.scss. The first sounds like a verb while the second is the noun.

A theme would have to do something like add_theme_support( 'wp_block_styles ' ) to load these if they want to.

This makes sense, but my concern is that when G merges into Core, there will be a lot of themes that don't initially inject their styles into the Editor. This will be a big disconnect for users, I think. Is it too difficult to inject the theme styles automatically? I'm sure there's already discussion around this, I'll look for it.

davidakennedy commented 6 years ago

I wanted to drop some thoughts here since I've been thinking about this lately, and testing some themes with Gutenberg in mind...

The separated approach laid out by @mtias seems like a nice balanced way ahead. Theme authors will have the choice as to whether to opt in, or go their own way. That's very WordPress-friendly, in terms of what everyone is used to having. It also lets both the type of themes exist: custom ones, and ones that build on existing Gutenberg structure, styles, etc.

I'd also +1 the font and color approach mentioned. It strikes and good balance and gives authors a lot of flexibility.

jjchrisdiehl commented 6 years ago

I agree that conflict can happen between default styling and plugins/themes that do not quite account for the styling.

For instance, I am using the Gutenberg starter theme (and also tried with Fashion Blog theme by Automattic) and noticed that a custom 'spacer' block by Array Themes has this weird gray styling on the front end:

https://cloudup.com/cnJovnhpegf

It seems like they use hr's to create these spacers, then dynamically adjust the height of the hr. In theory, this works great, but in practice, the default hr gray styling is applied and creates this odd gray bar.

So as @davidakennedy mentioned, allowing a plugin or theme to override these default stylings could be preferable to avoid these conflicts.

BinaryMoon commented 6 years ago

I’m really pleased that this is being looked at. Thanks to @karmatosed for pointing the ticket out to me.

I think that splitting the styles into more files is a good approach that would alleviate a lot of my concerns with the defaults overriding already existing styles.

Thinking further - is there was a way for the proposed theme.css to work in both editor AND the on the front end? If this were possible then perhaps the theme.css could be filtered within the theme (or as a property in add_theme_support), which would provide a simple way for themes to add their custom styles to the editor.

I appreciate that there would probably be specificity issues here so don’t know if it would be possible to do with a single stylesheet. Otherwise using SASS a second stylesheet could be made quite easily that achieves the same thing.

Regarding the fonts - I really like this as well. It’d be great for themes to be able to select font sizes that fit their modular scale. I love a bit of consistency.

I would suggest removing the number and slider. In the demo the number shows 24 - which means 24 pixels. It was mentioned that the numbers are unitless but if you made something 24 rems it would be obscenely large. This could potentially cause issues when switching between themes that use different units.

Again, regarding the numbers, users may learn to use a specific number scale (24, 36, 48 for example) with their current theme, and then get confused when they switch to a theme that uses percentages/ rems where the scales are wildly different. If we hide the numbers and stick to the buttons then it will be a simple interface that is more easily transferable between themes.

Regarding sizes, I would suggest having a fixed number of sizes. I don’t know what the plan is here, but if you allowed themers to define the number of sizes (eg one theme may define s, m, and l, and another may define x, s, m , l, xl ) then we will have the same issues with theme transferability.

As an aside - is there a way to just subscribe to theme related tickets here?

mrwweb commented 6 years ago

I was about to leave this comment on #5947 and then realized it was probably more appropriate here. It is still useful for context and use-cases though.

I've thought a lot about block styles, particularly in light of my previous approaches to allowing users to style content in TinyMCE. Here are two scenarios from the aforementioned ticket about alternate quote styles in particular:

It seems that most customization focus has largely been on creating new blocks (possibly using other blocks as a template), but that seems like it could quickly become unsustainable (18 types of quote blocks!) and also overkill for implementing simple, alternate presentations of existing blocks.

Therefore: It seems there should be a way of adding custom styles for blocks that either apply different markup patterns or custom CSS classes. Focusing first on CSS classes would actually be quite powerful and possibly sufficient. In fact, whether custom markup is required vs. just CSS classes might be a good distinction for when to create a new block style vs new block.

It's really easy to come up with tons of examples of how [CSS-driven] custom block styles would be useful and defend against the number of blocks ballooning.

Nearly every example above is the same or similar to something I've implemented for editors on a site in the past, so these aren't just hypotheticals.

This ticket highlights the Advanced sidebar section CSS Classes text box, but I think it would be much more powerful and user-friendly if developers could create/add a dropdown of styles somewhere that trigger classes for specific blocks. Similarly, while it might be possible to achieve the same visual result by, for example, applying a button background color, bold, and XL font size, standardizing that combination of three changes with one semantic name (and single CSS class!) allows a better user experience AND guarantees the style remain consistent and editable site-wide in the future.

This is a tried-and-true approach I've used with TinyMCE's styleselect feature for years. Additionally, the few sites where I've tried to help users manage and maintain a documented list of CSS classes for adding to a "CSS Classes" text box to trigger styles have not worked well at all.

Pseudo-code to show how it might work:

// basic idea
register_gutenberg_block_styles( $block_type string, $options array );
// basic example
register_gutenberg_block_styles( 'paragraph', array(
  array(
    'label' => 'Footnote',
    'class' => 'prefix-footnote',
  ),
  array(
    'label' => 'Story Lede',
    'class' => '{prefix}-lede',
  ),
);

I tried to raise this in #783 (also looking at quotes) and #773 (TinyMCE styleselect), and I hope this further explanation can again call attention to the need for supporting simple alternate styles for existing blocks. When thinking about custom block styles, it both means the UI needs to be able to accommodate many options and that the presentation likely can't be identified simply by an icon (too generic) or an elaborate preview (too large). (Presumably selecting the style would immediately style the block, serving as a preview.)

Another advantage: [Prefixed] Custom CSS classes have a nice fallback of no styles should the user change themes. I could imagine that if a style stops being supported, its classes just gets moved into the Advanced CSS Classes textbox.

hvianna commented 6 years ago

I would like to suggest having the front-end body classes (for the post/page being edited) available somewhere in Gutenberg's structure, like we have in the classic editor, so we can adjust the editor CSS to different page templates.

mrwweb commented 6 years ago

Following up on my prior comment in light of the current resolution of #5790 (keeping the "Subheading" block which is implemented as a paragraph), it seems worth noting that the semantic confusion of a "Subheading" block would be greatly decreased if it were a "Style" of paragraph block (or Heading block?) rather than its own separate block type. Further, it falls into the category of styles that could be achieved by applying multiple font customizations but instead can be semantically grouped into a single unit and applied via a single CSS class.

brandonpayton commented 6 years ago

I am working on implementing this separation of theme styles and base styles. In thinking through this, a few questions keep coming up:

  1. Will the proposed opt-in approach be sufficient for existing themes? It seems sub-optimal for block-based content to look unstyled by default in today's themes.
  2. Do we need more granularity where a theme can adopt some default styles while completely overriding others?
  3. Should we provide a solution for doing the same things for opinionated third party styles? I am quite new to WordPress, but it seems like themes might like to provide custom styles for popular third-party block libraries.

I am working on a PR with my take on these questions. We may need to scrap it, but at least it will give us something to discuss.

Regarding implementation, you mention .scss files, but I had been thinking in terms of .css. Is there some kind of built-in support for .scss that is present or planned?

karmatosed commented 6 years ago

Thanks for working on the PR, a few questions @brandonpayton come to mind.

Will the proposed opt-in approach be sufficient for existing themes? It seems sub-optimal for block-based content to look unstyled by default in today's themes.

It's tricky but loudly we are hearing that themes want to decide. I have my own feelings there but I think in version one we should see with opt-in.

Do we need more granularity where a theme can adopt some default styles while completely overriding others?

I think this seems sensible. I can imagine it being less attractive to use otherwise.

Should we provide a solution for doing the same things for opinionated third party styles? I am quite new to WordPress, but it seems like themes might like to provide custom styles for popular third-party block libraries.

I would say leave that to one side as the theme can just declare a separate style for that. Let's focus on Gutenberg itself for now.

I am working on a PR with my take on these questions. We may need to scrap it, but at least it will give us something to discuss.

What is your take?

brandonpayton commented 6 years ago

Thanks, @karmatosed, that helps.

What is your take?

Initial take

My initial take was to use an opt-out approach and allow themes to override or add to styles for specific blocks. Here's how I thought it would work:

Ideally, this would work for fully overriding or augmenting any block's theme styles.

But there is a problem with this approach today because core block styles are built into single CSS files, one style.css, editor.css, and soon to be theme.css for all core blocks. If a theme provides a core/quote.css file, there is not currently a way for us to omit only core/quote styles. Maybe we can devise a way as part of this work.

Today's take

After beginning on the above approach and realizing the approach may not be realistic, I wanted to get something out there to discuss. I plan to implement a simpler first iteration that:

I am not sure what the behavior should be for this between child and parent themes. If both contain styles for the same block, should both be loaded or only the child theme's?

Question

Do you have any other thoughts after reading my take?

karmatosed commented 6 years ago

Thanks for expanding on your take @brandonpayton. I do have some thoughts after reading, mostly agreeing that today's take seems better than previous one.

I am not sure what the behavior should be for this between child and parent themes. If both contain styles for the same block, should both be loaded or only the child theme's?

I think just the child makes sense to win in that case.

I agree getting something out there to discuss is good, so simpler is better.

BinaryMoon commented 6 years ago

It seems sub-optimal for block-based content to look unstyled by default in today's themes.

Most well built themes will have styles that cover most of the default blocks without changes (if your theme s doesn't have styles for blockquots and hr's then what are you doing?). The only styles I want to include from Gutenberg are the structural (unopinionated) styles for things like the cover image that are not already styled by my theme.

I have tested Gutenberg in my existing themes that have no Gutenberg support (apart from dequeuing the default styles) and, apart from things like the cover image that have a specific layout, they look fine.

Do we need more granularity where a theme can adopt some default styles while completely overriding others?

I don't think that's needed. If the styles are separated as described in the original ticket then I would be happy. I can ignore the theme.scss and use the other two. Job done.

I imagine some people might like more granularity but personally I think I'd wait and see what people ask for after the initial release.

My gut suggests that theme creators (who are more often designers rather than developers) won't use anything if it's too complex; hence the pushback on things like the Customizer, and lack of usage of the REST API in themes, and even the negative reactions to Gutenberg.

brandonpayton commented 6 years ago

Thanks, @BinaryMoon. That's helpful perspective.

mor10 commented 6 years ago

I'm working on a theme right now. My main takeaway is Gutenberg must supply basic styling for elements that are new or changed. The minimal viable product should ensure what happens in Gutenberg on the back end is reflected on the front end even if the theme being used is 3 years old and has no Gutenberg support.

Off the top of my head, blockquotes, columns, galleries, and figures with caption come to mind as blocks that are either new or behave differently than previous iterations.

Shipping these styles by default, and allowing theme developers to manually override, ensures two things:

  1. A user with a theme that does not have Gutenberg support is served with a consistent experience from back- to front-end.
  2. A developer can build on top of the supplied CSS to either augment or replace these styles.

The latter point is important to ensure when developers start playing around with block styles, they have one unified source of practical standards to work from.

To ensure theme (and plugin) developers can augment / override the existing styles while leaving them in place, the styles must be enqueued early on to stay high in the stack.

tl;dr:

  1. Base styles should must be supplied by default to avoid a sub-optimal end-user experience.
  2. Theme developers need the ability to override and/or replace supplied styles.
felixarntz commented 6 years ago

This here is my favorite Gutenberg ticket, I just wanted to start with that. 🙌

I agree with what has been argued before:

There are two other items that relate to blocks and theme styling that I would like to discuss (maybe in another issue since this one seems to have been narrowed down to the block CSS override topic):

1. General styles for the block editor

I think it should be easier to provide general styles for the block editor (global font, margin, padding, ...). With the current editor, you can simply call add_editor_style() (with an optional path, if yours isn't /editor-style.css), done. It's much more involved with Gutenberg. Also, since Gutenberg doesn't load in an editor iframe, we need to have a clear guide for what selector you need to wrap your default styles in. Maybe we could add support for a /block-editor-style.css file in the theme directory.

2. Block variants

Theme styling is not limited to CSS and markup that Gutenberg offers: For example, some themes provide buttons in certain variants, like a "regular" button, a "primary" button with highlight color, and a button that looks like a "link" with button spacing. A similar problem is what was mentioned before with the different blockquote styles. I suggest we give theme developers a means to register custom variants for blocks that affect the styling. For each block with variant support, a theme developer could register a map of CSS classes and their labels. For example, I could call the following:

add_theme_support(
    'block-variants',
    array(
        'wp:button' => array(
            'wp-block-button-primary' => __( 'Primary', 'textdomain' ),
            'wp-block-button-link'        => __( 'Link', 'textdomain' ),
        )
    )
);

The above code would then cause Gutenberg to display a "Variants" dropdown for the wp:button block with the two options I specified (plus a third default one). When selecting an option other than the default, that class would be applied to the outer block element. The theme could then appropriately style these variants.

-- As I mentioned, those two areas are additional related topics and may be better suited as separate issues. Let me know your thoughts and how to best proceed.

rchipka commented 6 years ago

Related to #6651

The addition of configurable CSS attributes should be standardized as a special prop on each component so that Gutenberg can take care of injecting the styles/classes in an automated, consistent, and maintainable way.

I think that any (non-default) block styling configurations for a particular post/page should be directly injected into the post/page content instead of being separately compiled and enqueued.

The rendered styles/classes should be tightly coupled to the actual raw content in order to avoid issues with enqueuing, server-side rendering, ajax, etc.

Also, please see the notes about how we should be doing class names and class injection to properly support extensibility.

mtias commented 6 years ago

I suggest though that the directory path is specified via theme support ...

I like this idea!

With the current editor, you can simply call add_editor_style() (with an optional path, if yours isn't /editor-style.css), done. It's much more involved with Gutenberg.

Our current function for supplying editor styles is:

add_action( 'enqueue_block_editor_assets', 'mytheme_block_editor_styles' );

We could definitely hook into add_editor_style() but that might break multiple existing themes that operate under the iframe assumption. We could go with a new one add_block_editor_style() performing the same but with a more explicit contract that it's for the new block editor. Is this something you'd like to help with?

Also, since Gutenberg doesn't load in an editor iframe, we need to have a clear guide for what selector you need to wrap your default styles in.

This is one of the bigger problems we have. Scoped styles or shadow dom was the best solution, but the support is not ubiquitous yet. I think the proper way would happen once the "site" or "post" is itself a block — with properties for fonts, colors, etc — that can be declaratively supplied by a theme, and it'd be up to gutenberg to map to the correct selectors.

Ideally you should never have to write a selector that is not wp-block-{name} to style the editor, and you shouldn't have to fight specificity. But this is complicated without having an iframe.

I suggest we give theme developers a means to register custom variants for blocks that affect the styling.

I agree as well. We have a spectrum between creating new blocks entirely and registering a style variant. In general, new blocks are a better UX because the tools are more flexible and purposeful (transformations are supported natively, the inserter works as the main entry point, etc), but in some cases style variations make sense as part of a block.

To support this we would need to introduce a first-class block API so that we don't run into validation issues (say a plugin registering an extra style variant for a "Button" block which is then deactivated). From a design point of view, it has not been super clear what the best UI for this is (the "Quote" example was a bit of a failed experiment, in my opinion, given the obscurity of using icons for the style variants). Few people notice it's even there vs them noticing the separate "Pullquote" block.

I think this might have to be developed for the next phase (customization) unless something is found that just clicks. cc @karmatosed @jasmussen @melchoyce @ianstewart @shaunandrews for previous chats about this. One idea was to have visual representations of the block variants rendered in the sidebar so the user can choose visually.

My main takeaway is Gutenberg must supply basic styling for elements that are new or changed.

@mor10 this was the original approach, but we quickly ran into themes not expecting WordPress to supply styles for items like blockquotes, meaning they don't reset properties like border, meaning the visual design for any theme not updated for gutenberg could break. Making this opt-in — if you are creating a new theme with the new editor in mind, you'd just add_theme_support( 'wp_block_styles' ); — ensures we don't cause headaches for users who might not know why suddenly their themes have these visual glitches.

felixarntz commented 6 years ago

@mtias

We could go with a new one add_block_editor_style() performing the same but with a more explicit contract that it's for the new block editor. Is this something you'd like to help with?

I'd have suggested something along those lines, and yes I'd absolutely be willing to help!

We have a spectrum between creating new blocks entirely and registering a style variant. In general, new blocks are a better UX because the tools are more flexible and purposeful (transformations are supported natively, the inserter works as the main entry point, etc), but in some cases style variations make sense as part of a block.

I generally agree that blocks are a more useful choice, but the concept of a variant as I envision it would just be a more user-friendly way of the current "Additional CSS Class" field (not as a replacement of course, just as user-friendly alternative that essentially does something similar). Many folks do not know what CSS is and means, but if they see a dropdown of variants with human-readable labels, they will likely understand. I would think of variants as a similar thing like the CSS class field in that it would be available for every block, however only displayed if there actually are different variants registered for that block.

say a plugin registering an extra style variant for a "Button" block which is then deactivated

I would expect style variants for a block to be registered by themes only, that then also take care of styling. If the theme is deactivated, the CSS class may still be in the content, but it wouldn't be styled anymore, and the dropdown with variants would no longer display - so nothing would break, the block would simply be back to using its regular style variant then.

I think this might have to be developed for the next phase (customization) unless something is found that just clicks.

Having provided a more detailed description of my understanding of block variants, I feel like you view this feature in a different way than me. If it's simply a map of "class to apply to the block" / "label" pairs that themes can register, it shouldn't be too complex. That may be a short-sighted statement from me of course. :) But if it's actually decided to be what's worth pursuing, I would expect this to be a manageable task for v1. If not, I'd also be happy to experiment with an addon plugin for Gutenberg, given that it provides the necessary integration points.

mrwweb commented 6 years ago

@felixarntz Thanks for restarting the discussion of block variants. I completely agree with everything you said including the importance of this being a v1 feature and the relative simplicity of what might be needed.

maybe in another issue since this one seems to have been narrowed down

783 ("Create unified UI for block variants") could be a candidate for re-opening as a place to continue this discussion.

I would expect style variants for a block to be registered by themes only,

I think we could expect plugins to register these as well. See below for examples/details.

so nothing would break, the block would simply be back to using its regular style variant then.

Exactly! There's very little harm in adding (hopefully prefixed) styles.

@mtias:

We have a spectrum between creating new blocks entirely and registering a style variant. In general, new blocks are a better UX because the tools are more flexible and purposeful (transformations are supported natively, the inserter works as the main entry point, etc), but in some cases style variations make sense as part of a block.

What @felixarntz says is exactly right. This would really just be a more user-friendly version of the "Additional CSS Classes" box. Here's the definition of Block Variants that I think we're both proposing:

A means of applying one or more CSS classes to a specific type of block's wrapper element by selecting a user-friendly name for that class(es). Themes or plugins could register the display name and class(es) with a simple API. No markup changes would be involved.

There is already an API in WordPress for almost exactly this via the styleselect feature in TinyMCE.

By coming out with an easy-to-use block variant API/interface, I think that could cut-off a flood of blocks from themes and plugins (think something like Shortcode Ultimate but for gutenblocks) that don't really need to be blocks. I will include my list of examples of CSS-class-only block variants here again as a useful example of things that would otherwise have to be blocks and create clutter in the block selector:

  • An alternate Heading block style with a fancy underline called "Section Title"
  • An Image Block with options to add a sepia filter ("Old Timey") or a border radius ("Rounded Corners")
  • A paragraph could be turned into a "Callout Box", "Footnote", or "Intro Text" (see #5790)
  • An ordered list block style to use alpha or greek characters
  • An unordered list block style that doesn't use visible bullets ("No Bullet List") or displays a list in multiple columns (Multi-Column List)
  • A button block with special styles for "Donation Button", "Volunteering Button", or "Secondary Call to Action".

In the vein of "if everything is important than nothing is important", it feels like there needs to be something in between Blocks (styles, markup, other baked in magic) and block styles (inline styles, one-off CSS classes). Blocks have much too much overhead for a simple alternate heading style and people are prone to doing things like making every first paragraph of a blog post have XL text that's purple and italic. What if they could just select "Intro Paragraph" from a drop-down menu of Paragraph block variants instead? (WordPress could even suggest a common set of block variant classes to support, making styles even more portable between themes!)

I think the #5790 discussion of the "Subheading" block is enlightening here. The introduction of block variants would solve two big issues:

  1. "Subheading" would become a Block Variant of the paragraph block, reducing the ambiguity over the semantic markup of the block.
  2. A less-prominent way of selecting Block Variants would mean core could actually include more styles by default without overwhelming people with niche blocks. This type of "progressive disclosure" is a great way to make interfaces both simple and powerful!

tl;dr:

  1. Let's formally scope the idea of Block Variants to one or more CSS classes applied to a specific block type's wrapper element with no markup changes. This hopefully gets it into v1.
  2. Block variants are a way to avoid having 18 blockquote blocks or 15 button blocks. Currently there is no other option for minor block variations except the user-unfriendly Additional CSS Classes textbox.
samikeijonen commented 6 years ago

+100 for everything what @mrwweb and @felixarntz said.

karmatosed commented 6 years ago

Such a lot of awesome thinking on this issue, let me dive in with some comments myself.

The above code would then cause Gutenberg to display a "Variants" dropdown for the wp:button block with the two options I specified (plus a third default one). When selecting an option other than the default, that class would be applied to the outer block element. The theme could then appropriately style these variants.

This seems overly complicated and possibly open to conflicting style issues with the same being used for multiple elements (maybe?). I would caution against this interface. Whilst, I totally understand what you are suggesting, I am not totally sure this is user friendly, for example, a long drop down list isn't for example. The concept of 'block variants' could be explored in a plugin and tested outside, that's how we can explore and iterate the interface.

I would +1 again to sticking with what is being planned for version one and having any bigger changed for version two. Let's focus a little on the simplest, easiest here and build up once we have that in.

I think this might have to be developed for the next phase (customization) unless something is found that just clicks. cc @karmatosed @jasmussen @melchoyce @ianstewart @shaunandrews for previous chats about this. One idea was to have visual representations of the block variants rendered in the sidebar so the user can choose visually.

I really think visual representations is the way forward over names/drop-downs and other interfaces.

BinaryMoon commented 6 years ago

@karmatosed @mtias I think the ideas being presented here (specifically offering/ selecting block variants) are really nice and will be very helpful however I would be interested in looking back at the original ticket and finding out if that is something that's going to happen?

I'd really like to be able to dequeue the opinionated styles in both the editor and the front end. That would fix everything I need as a themer. All the rest is icing on the cake.

karmatosed commented 6 years ago

@BinaryMoon to be clear my points are regarding the interface and implementation not the concept. There are some interesting ideas in this issue: https://github.com/WordPress/gutenberg/issues/5947. @melchoyce would love to see your insights here from your work looking at other systems.

It's worth noting a few more points, we have to be really cautious overloading the sidebar. Whilst it seems like a good place to put things, just like we have to be careful with overloading the toolbar we have to consider what we put there. Are there other options beyond a drop-down? What other implementations are there out there we can learn from?

Regarding time, my encouragement here is to explore and get what we have to get in. Then we can iterate and move beyond.

BinaryMoon commented 6 years ago

@karmatosed Hey Tammie - I have no problem with the things you're saying. They make total sense.

I just want to be able to separate the styles so I can introduce my own without having to do all sorts of weird work arounds/ super strict css rules.

I'll take a look at that other ticket too. From a super quick look it seems that the other ticket could be resolved quite easily with the ideas being presented within this one.

felixarntz commented 6 years ago

@karmatosed

This seems overly complicated and possibly open to conflicting style issues with the same being used for multiple elements (maybe?).

I don't think that is technically overly complicated as it's de-facto exactly the same what the existing "CSS Class" text input field does.

I really think visual representations is the way forward over names/drop-downs and other interfaces.

I do agree with this concern - dropdowns are certainly more user-friendly than an input field for a CSS class, but what you're outlining would still be a lot better. Investigating an approach for block variants in a plugin first appears like a good solution to me.

melchoyce commented 6 years ago

I'm having some trouble visualizing this approach — @mrwweb @felixarntz could either of you sketch out what you're thinking?

chrisvanpatten commented 6 years ago

A little late to the issue but I agree with a lot of the above commentary. Block transforms feel appropriate for semantic changes, not simple visual changes. The transform API also requires you to know exactly which blocks a block can be transformed into, which is putting a huge burden on plugin developers to test and develop interop with other plugins for something that might just be a simple visual tweak.

I also haven't fully tested it, but I imagine there will be additional issues if I have Third Party Quote Block Plugin used on a few posts, but then delete the plugin — does Gutenberg still know how to transform the instances of the Third Party Quote Block in my post_content? Or do I get an error message? Or is it transformed to a generic paragraph or classic block? None of those experiences are really ideal.

(And none of this is factoring in block overload… what happens when third party plugins and themes start supporting Gutenberg en masse? Block discoverability is going to be a major issue as more blocks become available, and asking users to keep track of all the variants of a block type in the inserter is just a nightmare.)

The sidebar may not be the best place for this, but here's one idea:

columns_sketch

Themes could register their own "block designs", which consists of a name, a CSS class, and a preview image.

karmatosed commented 6 years ago

@chrisvanpatten thanks for that visual, this really plays to my bigger concern of that being in the sidebar. If you think of scale that easily breaks. What other options are there? Are there any applications doing something like this right now we can learn from?

chrisvanpatten commented 6 years ago

@karmatosed I'm not sure where else to put it, but I'm certainly open to ideas.

chrisvanpatten commented 6 years ago

(To elaborate, I think there will be an issue of scale anywhere it goes — and that's applicable to any point in the UI where plugins can add additional options. I'm not sure if putting it behind a toolbar button is better or worse but I'm certainly open to experimenting with that!)

chrisvanpatten commented 6 years ago

Here's an interesting example from Squarespace, on how you can select alternate layouts for their Instagram block.

ig_block

For them, they place the options behind a separate Design tab.

Another interesting take, in Excel of all places… alternate table designs in a dropdown:

cond_format5_2010_001

melchoyce commented 6 years ago

Thanks @chrisvanpatten, that visualization helps.

Some more examples from other sources:

Slideshow block in Weebly

screen shot 2018-05-29 at 12 19 00 pm

Layout blocks in Weebly

ezgif com-video-to-gif 1

Section Designs in Wix ADI

screen shot 2018-05-29 at 12 24 33 pm screen shot 2018-05-29 at 12 25 24 pm

More design settings in Squarespace

screen shot 2018-05-29 at 12 26 01 pm
chrisvanpatten commented 6 years ago

Here's another take, from Pages:

untitled_pages

mrwweb commented 6 years ago

As promised, here's a couple concepts. I think I like this first one best, placing the drop down with the block definition in the sidebar. It's kind of subtle and prominent at the same time:

No Style Selected A dropdown below the "Paragraph" block definition in the sidebar. No selection made. Says "Select a style..."

Select an option Drop down from previous image is active with two options.

Class added Green Drop Shadow Box selected in new styles select menu. Selected paragraph now had green background, padding, border, and drop-shadow.

I also think this is a great example of how powerful something like this can be! It applies 4 styles (background, padding, border, box-shadow) that would be hard to apply any other way but also way overkill for creating unique blocks for. Any interface that allowed setting padding and creating box shadows wouldn't be easy to replicate like this and would be both tedious to use and likely to be used inconsistently from page to page.

Another option would be to put the variant selection menu in the inline toolbar:

Drop down after the block select. Says "No Style..."

mtias commented 6 years ago

I think the ideas being presented here (specifically offering/ selecting block variants) are really nice and will be very helpful however I would be interested in looking back at the original ticket and finding out if that is something that's going to happen?

@BinaryMoon yes, the original intention of the issue is unrelated to variants and is being worked on — initial implementation should land for 3.0. @mrwweb let's reopen #783 for this conversation, as it's getting a bit away from the purpose of the current issue, and make out a plan before deciding if we can make it into 5.0 or not.

but the concept of a variant as I envision it would just be a more user-friendly way of the current "Additional CSS Class" field (not as a replacement of course, just as user-friendly alternative that essentially does something similar)

To be clear, I totally agree with this, and I think it's something we should pursue. :) I'm not entirely sure how we would present it — perhaps starting by having the dropdown within the "Advanced" panel is a safe start. One of the problems is that a design principle has been to allow as much as possible to happen in the block directly, with the sidebar being more about sophisticated attributes.

This poses a problem for how we deal with variants. Where should they fall? If they are considered useful user-friendly additions (and I'd tend to agree with this) then we should see how they could be incorporated to the block body/toolbar instead of the sidebar. But a dropdown list with the names in the block toolbar doesn't scale too well and can complicate the UI. (Issues with mobile, not immediately visual, etc.)

Also, even if technically this is trivial to do, we should look at how we could facilitate the usage of it longer term, because I think it's a good feature to have.

@chrisvanpatten I totally agree on the semantic distinction being relevant here. I'd actually use that to make the case that "subheading" should be a separate block, because it's not a purely visual change, it has semantic value to the user.

samikeijonen commented 6 years ago

Quick note about theme.css. It would make sense that themers could dequeue or opt out theme.css also from the editor.

I tried it with wp_dequeue_style( 'wp-core-blocks-theme' ); with hooks enqueue_block_editor_assets and enqueue_block_assets but no luck. Could be something to do with depencies.

mtias commented 6 years ago

@brandonpayton when you have a moment could you look at the above? Thanks!

BinaryMoon commented 6 years ago

I agree with @samikeijonen - I want to include my styles in the editor but I'm having a hard time overriding the default ones.

brandonpayton commented 6 years ago

I tried it with wp_dequeue_style( 'wp-core-blocks-theme' ); with hooks enqueue_block_editor_assets and enqueue_block_assets but no luck. Could be something to do with depencies.

Hi @samikeijonen, you're right that it has to do with dependencies. The 'wp-edit-blocks' styles depend on the 'wp-core-blocks-theme' styles. Because of this, we cannot simply dequeue the theme styles, but we can replace them for 'wp-core-blocks-theme' by using wp_deregister_style and wp_register_style. enqueue_block_editor_assets looks like the right hook to use for this. Does that help?

@mtias do you want us to do anything more to support overriding theme CSS in the editor?

samikeijonen commented 6 years ago

Thanks @brandonpayton! I opened new issue in #7776 just in case. I feel like replacing the original theme.css with empty one is not the best practise.