[wp-trac] [WordPress Trac] #45045: Twenty Seventeen: Update theme to add Gutenberg styles and support

WordPress Trac noreply at wordpress.org
Wed Oct 10 04:28:40 UTC 2018

#45045: Twenty Seventeen: Update theme to add Gutenberg styles and support
 Reporter:  laurelfulford                        |       Owner:
                                                 |  laurelfulford
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.0
Component:  Bundled Theme                        |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-       |     Focuses:
  screenshots                                    |

Comment (by celloexpressions):

 Please upload at least the most general screenshots directly to trac for
 posterity, as any external links tend to become invalid over time. Let's
 also consider that any front-end changes to existing content should be
 kept to an absolute minimum to avoid unexpected changes to live sites when

 We need to carefully consider how theme color options interact with the
 in-content color options in Gutenberg. Many of the bundled themes include
 carefully-designed custom color options. Twenty Seventeen took the
 opinionated strategy of being primarily monochromatic, with subtle
 elements being customized with a custom hue picker. Any theme colors
 defined in the block editor should reflect the user's selected hue, along
 with the other theme colors that default as gray. Most in-content custom
 colors are probably not appropriate with this theme; the broader strategy
 of in-content color selections in Gutenberg needs substantially more
 discussion and documentation before release. What happens to custom colors
 within posts when you switch themes? How do users maintain consistent use
 of colors across their site?

 `editor-blocks.css` in [attachment:"45045.patch"] is deeply concerning.
 Gutenberg should be able to find a way to use the existing `editor-
 style.css` with minor modifications, or even introduce API to facilitate
 pulling styles directly from `style.css`. We shouldn't need to create new
 editor stylesheets for all eight bundled themes, and no theme developer
 should be expected to do this. Duplicating all of this information,
 maintaining two editor styles, and including heavily verbose selectors is
 not an efficiently-designed API. Most importantly, users will suffer if
 this amount of effort is required to implement editor styles, as most
 existing themes will not make this change.

 In general, [attachment:"45045.patch"] exposes fundamental flaws with the
 current theme support API for Gutenberg. We should prioritize user
 experience first, theme and plugin developer experience second, and core
 developer experience third. Let's look at ways to take on more technical
 debt to maximize backwards compatibility in core so that theme developers
 and users can upgrade to the new editing experience more easily. Updating
 the bundled themes to support Gutenberg is a good way to take a fresh look
 at the API changes that it makes. We should expect to make changes to
 Gutenberg through this process so that changes to the themes can be
 minimized. The fewer changes that we can make in adding support to the
 core themes, the more successful the transition will be for everyone.

Ticket URL: <https://core.trac.wordpress.org/ticket/45045#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list