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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Themes and front-end #1315

Closed
samikeijonen opened this Issue Jun 20, 2017 · 17 comments

Comments

Projects
None yet
@samikeijonen
Contributor

samikeijonen commented Jun 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Jun 20, 2017

Member

Related: #963

Member

aduth commented Jun 20, 2017

Related: #963

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Jun 20, 2017

Contributor

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

Contributor

samikeijonen commented Jun 20, 2017

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

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Jun 20, 2017

Member

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!

Member

aduth commented Jun 20, 2017

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!

@aduth aduth closed this Jun 20, 2017

@melchoyce

This comment has been minimized.

Show comment
Hide comment
@melchoyce

melchoyce Jun 20, 2017

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 commented Jun 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@melchoyce

melchoyce Jun 20, 2017

lol, nevermind

melchoyce commented Jun 20, 2017

lol, nevermind

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Jun 20, 2017

Member

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?

Member

aduth commented Jun 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@melchoyce

melchoyce Jun 20, 2017

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?

melchoyce commented Jun 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@brentjett

brentjett Jun 20, 2017

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.

brentjett commented Jun 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Jun 21, 2017

Member

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.

Member

karmatosed commented Jun 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mrwweb

mrwweb Jun 23, 2017

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.

mrwweb commented Jun 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Jun 24, 2017

Contributor

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.

Contributor

samikeijonen commented Jun 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@georgeolaru

georgeolaru Jun 24, 2017

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.

georgeolaru commented Jun 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Jun 24, 2017

Contributor

@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.

Contributor

samikeijonen commented Jun 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jul 9, 2017

Member

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.

Member

westonruter commented Jul 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@davidakennedy

davidakennedy Jul 12, 2017

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.

davidakennedy commented Jul 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@StaggerLeee

StaggerLeee Aug 8, 2017

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;.

StaggerLeee commented Aug 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Aug 31, 2017

Contributor

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.

Contributor

mtias commented Aug 31, 2017

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.

@mtias mtias closed this Aug 31, 2017

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