[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
updating.
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