Gutenberg: Themes and front-end

[samikeijonen]

I'd like to open this general issue for tracking how Gutenberg, themes, and front-end work together. I know there has been discussions on this already and this could be starting point for discussing them more openly.

I'll bring my ideas once I slept for a while (I need at least 12 hours :)

[aduth]

Related: #963

[samikeijonen]

Of course there was a ticket already:) We can close this if necessary.

[aduth]

Yeah, I think there's enough overlap that we can consolidate discussion there, and we can choose to split it into more granular issues if necessary. Thanks!

[melchoyce]

I think these are different enough ideas that they can remain separate tickets. The other ticket seems specifically about styling blocks on the front-end, while I see this more related to how everything ties together.

[melchoyce]

lol, nevermind

[aduth]

Sorry for the fast close @melchoyce 😬 I'm still not entirely clear though, since "tying together" seems to be particularly relevant for #963. Can you be more specific?

[melchoyce]

For example...

• What does a Gutenberg-optimized theme look like?
• How can themers start taking advantage of new features and blocks in Gutenberg? Is there any specific support needed? Do the template files need to be changed at all?
• What does this support look like once we start exploring more complicated layout options and page building tools later in the year, as the Customization focus starts to transition into the spotlight?

[brentjett]

Also would there be any legacy CSS that themes traditionally include that might be provided by core now (gallery styling, etc...) and no longer necessarily the job of the theme.

[karmatosed]

Also would there be any legacy CSS that themes traditionally include that might be provided by core now (gallery styling, etc...) and no longer necessarily the job of the theme.

I think it would be more that themes could unhook/ overwrite styles, over not their job? As with anything in WP. Having easy unhooking of defaults is important and saves !important circles.

[mrwweb]

A really basic question I'm confused on. #963 seems to open up the possibility for complex, custom-defined blocks with CSS provided by the theme (or a plugin for that matter). What I'm still confused about (and what #422 I think was trying to get at) is the really simple stuff that editor-style.css has traditionally been used for.

• How to I make sure my theme's typography matches type in the editor?
• How do I make links the same color?
• If my theme has a black-on-white color scheme, can the editor do that?

I know some people have always been luke warm on editor styles (often on developer convenience grounds), but having seen the impact they have on users in person and the degree to which it prevents the need to preview, this feels really important and not necessarily covered by any ticket I can find other than the now-closed #422.

[samikeijonen]

I'm not sure if this is the correct place for these ideas but here we go.

I see two ways how themes, Gutenberg, and front-end work together.

1. Let WordPress Core bring default styles for all blocks in the front-end.
2. Let theme author decide which blocks are even possible in the Gutenberg and provide styles in the front-end.

For option 1. (like Tammie wrote above) I'd need easy way to unhook/overwrite styles in a theme. I'd even go as far as unhooking all the front-end styles provided my Core/Gutenberg and write them all in my theme.

Option 1. is good approach in a sense that "all" themes would be Gutenberg-ready.

Option 2. is good approach for things like full width images. That definition depends so much on theme. Is there a sidebar, how entry-content behaves and so on.

@mrwweb I also feel that basic stuff should look the same in the editor and in the front-end. That's why we have editor-style.css now. But I'm open for other ideas also. I actually don't write editor-style.css at all manually, I just import style.css. Would be nice idea if I don't even have to do that.

[georgeolaru]

If our final goal would be to move the editing experience to the front-end, it makes sense to use the main theme stylesheet file all over the place, without duplicating any code in a separate editor-style.css file. This way, we can be sure that the WYSIWYG experience is consistent as a whole.

I don't think it's possible to have a WordPress Core styling for blocks that are working consistently in any theme, as long as there is no standardization about the theme layout and content structure. If there would be standardization, then not sure what would the theme's purpose be — giving a set of fonts and colors? (that could be included in a plugin too).

A direction might be to approach the new blocks as we currently address core widgets — their functionality is handled by the Wordpress Core (with no styling), and the theme is responsible for styling them according to the supported options.

[samikeijonen]

@georgeolaru I feel the same about the editor-style.css, eventually style.css would be enough.

I don't think it's possible to have a WordPress Core styling for blocks that are working consistently in any theme, as long as there is no standardization about the theme layout and content structure.

That's absolutely true at least for some blocks. For example blocks that are wider than base content. I personally would like to have full control of front-end styling for all blocks. But full control can also mean that I just unhook WP Core styles and add my own.

[westonruter]

If our final goal would be to move the editing experience to the front-end, it makes sense to use the main theme stylesheet file all over the place, without duplicating any code in a separate editor-style.css file. This way, we can be sure that the WYSIWYG experience is consistent as a whole.

I think this is where Customizer comes in. The editor I think should always be the _abstracted_ preview and _structured_ view into the data that comprises a post. When in the Customizer, however, the actual site's styles apply and the blocks can be seen as they would actually appear on the frontend of the site. Note I also envision the “Customzier” mode to expand beyond accessing the current customize.php app, so that if you are on the frontend of your site and you click “Customize” you immediately are dropped into a frontend editing mode without having to go anywhere. In this context, any blocks would have the same _selected_ state as they do in the Gutenberg editor now, but when the blocks are unselected the preview would be actual rendered view as opposed to the abstracted preview.

[davidakennedy]

I'm with @karmatosed here, and similar to the no. 1 option that @samikeijonen mentions. If Core provides a block, it should come with some basic styles that can be easily unhooked and rewritten in a custom way by a theme. I think this is important because it makes "theming" more approachable to people. It's a head start if you want it.

[StaggerLeee]

What is the reason you insist on font-family: "Noto Serif",serif; ?
Whole backend is in font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;.

[mtias]

Closing this as we have mechanisms for both applying block styles on the front end, for themes to overwrite them, and for themes to apply block styles back into the editor.