WordPress.org

Make WordPress Core

#45045 closed task (blessed) (fixed)

Twenty Seventeen: Update theme to add Gutenberg styles and support

Reported by: laurelfulford Owned by: laurelfulford
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords: has-patch has-screenshots commit fixed-5.0
Focuses: Cc:
PR Number:

Description

This ticket is to add Gutenberg styles and support for Twenty Seventeen, so it best takes advantage of the new editor.

For default themes, at the very least this would include adding styles for blocks to make sure they match the rest of the theme’s design, adding Gutenberg-specific editor styles for a better WYSIWYG experience, and adding theme support for the editor color palette.

Each default theme’s unique design should be considered for whether it makes sense to add support for wide alignments, and the best approach.

Attachments (19)

45045.patch (26.6 KB) - added by laurelfulford 13 months ago.
editor-alignments-after.png (901.5 KB) - added by laurelfulford 13 months ago.
Editor - Alignments (after)
editor-alignments-before.png (748.8 KB) - added by laurelfulford 13 months ago.
Editor - Alignments (before)
editor-common-blocks-after.png (1.5 MB) - added by laurelfulford 13 months ago.
Editor - Common Blocks (after)
editor-common-blocks-before.png (1.3 MB) - added by laurelfulford 13 months ago.
Editor - Common Blocks (before)
editor-formatting-blocks-after.png (81.7 KB) - added by laurelfulford 13 months ago.
Editor - Formatting Blocks (after)
editor-formatting-blocks-before.png (112.2 KB) - added by laurelfulford 13 months ago.
Editor - Formatting Blocks (before)
editor-widget-blocks-after.png (268.7 KB) - added by laurelfulford 13 months ago.
Editor - Widget Blocks (after)
editor-widget-blocks-before.png (331.9 KB) - added by laurelfulford 13 months ago.
Editor - Widget Blocks (before)
45045.1.diff (30.0 KB) - added by ianbelanger 12 months ago.
Adds some Wide and Full Alignment support, definitely not complete but does add to the original patch
separator-editor.png (22.6 KB) - added by davidakennedy 12 months ago.
Separator in Editor
separator-front-end.png (19.4 KB) - added by davidakennedy 12 months ago.
Separator on Front End
blockquote-editor.png (69.5 KB) - added by davidakennedy 12 months ago.
Blockquote in Editor
blockquote-front-end.png (76.7 KB) - added by davidakennedy 12 months ago.
Blockquote on Front End
cover-image-front-end.png (107.4 KB) - added by davidakennedy 12 months ago.
Cover image on front end.
45045.2.patch (29.1 KB) - added by laurelfulford 12 months ago.
image-margins.png (344.4 KB) - added by crunnells 12 months ago.
Default image margins
image-margins-gutenberg.png (278.6 KB) - added by crunnells 12 months ago.
Gutenberg image margins
45045.3.patch (29.6 KB) - added by laurelfulford 12 months ago.

Change History (59)

#1 @mor10
13 months ago

I suggest starting with Twenty Seventeen as a baseline and figuring out what is the MVP for Gutenberg support, then backporting it to the other themes. Otherwise much time will be spent solving the same problems in seven different ways. With a baseline solution in place it will be easier to evaluate what custom features need to be added to each individual theme.

#2 @laurelfulford
13 months ago

@mor10 I think that's a great idea :) I'm going to start digging into that today/tomorrow and try to have a patch ready to share ASAP.

Twenty Seventeen seems like a good candidate for the wide alignment support, but that seems like something that can be figured out once all the themes have patches with consistent basic support.

#3 @mor10
13 months ago

@laurelfulford IMO the most important part is to get default block styles into all themes. Wide images (and other content) must be decided on a theme-by-theme basis because each is so different. Another thing to look at would be whether the themes should have the full spectrum of custom colors or only colors to correspond with the theme colors.

#4 @ianbelanger
13 months ago

Hi @laurelfulford,

I am also currently working on a patch for Twenty Seventeen which I am hoping to have ready later today. However, I think I disagree that Twenty Seventeen is a good candidate for the Wide alignment though, unless it is only used when there is no sidebar. If there is a wide image used at the top of a post, when there is an active sidebar, it will most certainly overlap the sidebar, but feel free to correct me if I am wrong on this. Thanks

#5 @laurelfulford
13 months ago

IMO the most important part is to get default block styles into all themes. Wide images (and other content) must be decided on a theme-by-theme basis because each is so different.

@mor10 Absolutely, sounds like we're on the same page. :)

I am also currently working on a patch for Twenty Seventeen which I am hoping to have ready later today.

@ianbelanger Oh great! It sounds like you might be ahead of me on getting a patch done. I feel like the work I've done so far has helped me get a better grasp of what needs to be done, which will be good for testing.

However, I think I disagree that Twenty Seventeen is a good candidate for the Wide alignment though, unless it is only used when there is no sidebar.

Fair enough! If we did it, it would definitely have to be an implementation that worked with Twenty Seventeen's different layouts. And it could end up being something that just won't work, or that is too confusing. We can dig into that and discuss more one we have the basic support covered -- I was getting a bit ahead of myself there!

#6 @mor10
13 months ago

Wide and full alignments are an interesting challenge in themes with sidebars. I've had some success with certain layouts, and I think Twenty Seventeen could benefit from the wide / full layouts in several scenarios including the no-sidebar option. Some design mockups would provide quick answers to these questions.

#7 @pratikthink
13 months ago

please fix a small accessibility bug mentioned in #44699

#8 @laurelfulford
13 months ago

I took a first pass at updating Twenty Seventeen to include Gutenberg styles in 45045.patch . This patch:

  • Adds separate stylesheets for the front-end and editor block styles. The order of the stylesheets right now matches the order of the blocks in the editor itself, sorted under the same headers (Common Blocks, Formatting, etc).
  • Enqueues the block styles to the front end, and the editor styles and theme's fonts into the editor.
  • Adds a basic implementation of the editor colours, based on what's used in the theme's default palette.

The styles still need some work, and I'll continue to test and make updates for the next version of this patch. But I wanted to share this sooner than later to make sure the overall approach makes sense for the default themes overall. If anything stands out as confusing or incorrect, or if anyone has suggestions for improvements, please share!

#9 @laurelfulford
13 months ago

  • Keywords has-patch added; needs-patch removed

#10 @ianbelanger
13 months ago

  • Keywords needs-testing added

Hi @laurelfulford,

Beat me to it ;) I'll test out your patch on my local install and see if I can make any improvements to it.

#11 @laurelfulford
13 months ago

Thanks @ianbelanger! I guarantee the styles aren't quite there yet, and I can keep picking away at them, too. But if anything stands out to you as being implemented poorly, or that could be improved before patches are created for the other themes, that would be a huge help! :)

#12 @johnbillion
13 months ago

  • Keywords needs-screenshots added

@laurelfulford Thanks for the patch. Can you provide before and after screenshots for the changes? That way we can see how well the theme works without any changes, and what improvements the changes make.

#13 follow-up: @laurelfulford
13 months ago

That's a good idea, @johnbillion! I took some screenshots, of before and after for some of the test posts I created.

The most dramatic changes are between the before-and-after editor shots, because the patch corrects the fonts. The front-end of the site generally looks good before the patch -- there are a few elements (like buttons) that Gutenberg includes some more opinionated styles for, but not many.

(Doing this was also a good exercise in getting me to notice things that still need work, like the pullquotes. I've added that to my list!).

Edited to move the editor screenshots to Trac.

Last edited 13 months ago by laurelfulford (previous) (diff)

#14 @celloexpressions
13 months ago

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

#15 @celloexpressions
13 months ago

For Twenty Seventeen specifically, we should also think carefully about how the front page content feature interacts with Gutenberg. Especially considering its relationship to the goals of the new editor project. That could be anywhere from deprecating that feature (with a migration path) to ensuring that something similar can be achieved directly in the editor and keeping the feature as shipped with the original theme.

#16 follow-up: @laurelfulford
13 months ago

Please upload at least the most general screenshots directly to trac for posterity, as any external links tend to become invalid over time.

Oh, good point! I’ll move the images and update the links above.

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.

Yes, agreed! The changes are targeting the blocks specifically, to make sure they match the theme’s existing styles. Right now, the only selectors that don’t specifically target a block class (.wp-block-*) are for the colours.

We need to carefully consider how theme color options interact with the in-content color options in Gutenberg.

True. Based on the complexity, I think we should leave the editor colour support out of the MVP for Twenty Seventeen. There’s definitely a lot to consider to make it work in a way that makes sense with the theme’s own custom colours, and a lot of opportunities for clashes.

This would be consistent with Twenty Seventeen’s current editor styles, which don’t change based on the colour options.

editor-blocks.css in 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…

These are good points, but given the timeline of 5.0, will probably fall to later versions to address. I think they’re also part of a wider discussion that extends beyond the default themes and their eye to backwards compatibility, to future Gutenberg theme development overall. There is some discussion in the GitHub repo about smoothing areas of the editor-stylesheet experience (like https://github.com/WordPress/gutenberg/issues/10067). Starting an issue for a broader discussion could help make sure these points don’t get lost as Gutenberg enters Phase 2.

For Twenty Seventeen specifically, we should also think carefully about how the front page content feature interacts with Gutenberg. Especially considering its relationship to the goals of the new editor project. That could be anywhere from deprecating that feature (with a migration path) to ensuring that something similar can be achieved directly in the editor and keeping the feature as shipped with the original theme.

Another good thing to consider. For the latter, that could be part of implementing the “wide” alignment styles in this theme.

@laurelfulford
13 months ago

Editor - Alignments (after)

@laurelfulford
13 months ago

Editor - Alignments (before)

@laurelfulford
13 months ago

Editor - Common Blocks (after)

@laurelfulford
13 months ago

Editor - Common Blocks (before)

@laurelfulford
13 months ago

Editor - Formatting Blocks (after)

@laurelfulford
13 months ago

Editor - Formatting Blocks (before)

@laurelfulford
13 months ago

Editor - Widget Blocks (after)

@laurelfulford
13 months ago

Editor - Widget Blocks (before)

#17 @laurelfulford
13 months ago

  • Keywords needs-screenshots removed

#18 @ianbelanger
13 months ago

  • Keywords has-screenshots added

That could be part of implementing the "wide" alignment styles in this theme.

Considering wide alignments in Twenty Seventeen, there is a body class .has-sidebar added to all pages with a sidebar, but this will only handle the front-end. We still may need to figure out how to limit the wide alignment in the back-end for pages/posts with a sidebar.

@laurelfulford I am still working to update your patch with more styles. I will upload a patch with my progress, probably tomorrow. Thanks for the screenshots :) Loving the progress so far!!

#19 @nielslange
12 months ago

@laurelfulford I'm currently working on #45041 (Twenty Thirteen) and while analysing your patches for #45042 (Twenty Fourteen), #45043 (Twenty Fifteen), #45044 (Twenty Sixteen) and #45045 (Twenty Seventeen) I saw that the patches use add_theme_support( 'wp-block-styles' );, except this patch. Based on @matveb's comment in What’s new in Gutenberg? (5th June) it looks like this declaration is needed. Is that not the case for the Twenty Seventeen theme?

Last edited 12 months ago by nielslange (previous) (diff)

#20 follow-up: @laurelfulford
12 months ago

Thanks @nielslange!

Is that not the case for the Twenty Seventeen theme?

Nope! That was an oversight on my part 🙂 Thanks for catching that!

#21 in reply to: ↑ 20 @nielslange
12 months ago

Replying to laurelfulford:

Thanks @nielslange!

Is that not the case for the Twenty Seventeen theme?

Nope! That was an oversight on my part 🙂 Thanks for catching that!

You're welcome, @laurelfulford! 😉

#22 in reply to: ↑ 16 ; follow-up: @celloexpressions
12 months ago

Replying to laurelfulford:

Please upload at least the most general screenshots directly to trac for posterity, as any external links tend to become invalid over time.

Oh, good point! I’ll move the images and update the links above.

Thanks, this makes it much easier to quickly visualize the changes!

editor-blocks.css in 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…

These are good points, but given the timeline of 5.0, will probably fall to later versions to address. I think they’re also part of a wider discussion that extends beyond the default themes and their eye to backwards compatibility, to future Gutenberg theme development overall. There is some discussion in the GitHub repo about smoothing areas of the editor-stylesheet experience (like https://github.com/WordPress/gutenberg/issues/10067). Starting an issue for a broader discussion could help make sure these points don’t get lost as Gutenberg enters Phase 2.

This is something that should probably be treated as more of a blocker for 5.0 than something that needs to be compromised to hit the current deadline (especially considering that deadlines are not arbitrary). The bundled themes set the example for the rest of the community and represent best practices. If they add Gutenberg support by duplicating existing styles with different selectors, and using unwieldy selectors, other themes will be forced to do the same. This creates a bad developer experience and potentially compounds it by forcing another round of reworking in the future if the plan is to revise this API in a future release.

Completely removing all existing editor styles for all themes is a major regression that will impact the vast majority of users. And unless the API to improve editor styles for Gutenberg is simplified, it is unlikely that many themes will be updated. For tens (hundreds?) of millions of sites, it is not practical to update to a new theme with Gutenberg support (or make an immediate theme change in general). Forcing the technical debt for backwards compatibility into themes instead of into core breaks backwards compatibility and degrades the ability for the new editor to accurately reflect the front end for most users.

@ianbelanger
12 months ago

Adds some Wide and Full Alignment support, definitely not complete but does add to the original patch

#23 @ianbelanger
12 months ago

As requested @laurelfulford, 45045.1.diff is my current patch, definitely not complete but does add to your original patch.

This patch adds to 45045.patch:

  • Wide and Full Alignment support and styles, although not complete, also found and reported a Gutenberg bug with embeds https://github.com/WordPress/gutenberg/issues/10633
  • Theme support for add_theme_support( 'editor-styles' ); and add_theme_support( 'wp-block-styles' );

The Full alignment is causing a horizontal scrollbar. I haven't worked out a solution yet.

#24 in reply to: ↑ 22 @davidakennedy
12 months ago

Replying to celloexpressions:

This is something that should probably be treated as more of a blocker for 5.0 than something that needs to be compromised to hit the current deadline (especially considering that deadlines are not arbitrary). The bundled themes set the example for the rest of the community and represent best practices. If they add Gutenberg support by duplicating existing styles with different selectors, and using unwieldy selectors, other themes will be forced to do the same. This creates a bad developer experience and potentially compounds it by forcing another round of reworking in the future if the plan is to revise this API in a future release.

Completely removing all existing editor styles for all themes is a major regression that will impact the vast majority of users. And unless the API to improve editor styles for Gutenberg is simplified, it is unlikely that many themes will be updated. For tens (hundreds?) of millions of sites, it is not practical to update to a new theme with Gutenberg support (or make an immediate theme change in general). Forcing the technical debt for backwards compatibility into themes instead of into core breaks backwards compatibility and degrades the ability for the new editor to accurately reflect the front end for most users.

Thanks for the continued thoughts and feedback, @celloexpressions! I don't disagree with you, as you raise some great points.

That said, we're racing toward an MVP of Gutenberg support in default themes. So we need to work with what we have in terms of APIs, etc. If you have any suggestions as to how to alter the approach in the current patch to reduce repeated code, just add a comment. There's always a better way.

We’re supporting two experiences (Gutenberg and pre-Gutenberg) in existing themes that add Gutenberg support. No way to avoid that. So we'll have some duplication, it won’t be perfect. But we can try to make as perfect as can be within all the constraints.

@davidakennedy
12 months ago

Separator in Editor

@davidakennedy
12 months ago

Separator on Front End

@davidakennedy
12 months ago

Blockquote in Editor

@davidakennedy
12 months ago

Blockquote on Front End

@davidakennedy
12 months ago

Cover image on front end.

#25 @davidakennedy
12 months ago

I did some testing of the patch by @laurelfulford. Overall, really solid – here's what I found:

  • Separators look different in editor vs. front end (see screenshots).
  • Recent posts grid view with bullets in editor but none on front end.
  • Block quote citation looks different with font sizes (see screenshots).
  • Pull quotes have differences in citations.
  • Citations look off in most places.
  • Cover image blocks look off to me on front end for some reason (see screenshots).

@ianbelanger I didn't test your patch yet because I think we should get the editor/front-end styles nailed first before adding more on. Thank you for your work though!

I encourage anyone who has the time to help test. It's just as valuable as code (if not more so), and I'll gladly give props for thorough testing. :)

#26 @laurelfulford
12 months ago

Thanks @ianbelanger for the updated patch, and @davidakennedy for the feedback!

I can pick this up again first thing tomorrow, and incorporate the feedback as well as any non-wide changes from 45045.1.diff. That patch will then be a good foundation for the wide alignment styles once we're ready for those. :)

#27 @ianbelanger
12 months ago

@davidakennedy, if you had tried my patch, you would've seen that I already fixed the Cover Image issue, the separators and some of the quote styles. While incorporating all of @laurelfulford styles as well. It may be worthwhile to try using my patch to avoid doing work that I have already done. I apologize for not mentioning these things in my last comment. Thanks

Last edited 12 months ago by ianbelanger (previous) (diff)

#28 @laurelfulford
12 months ago

Updated 45045.2.patch with the following:

  • Incorporated non-wide alignment changes from @ianbelanger’s patch; confirmed this takes care of the cover image, separator & blockquote issues listed above. Ran into some additional weirdness with aligned blockquotes that should all be fixed.
  • Removed editor colour palette for now, as per the comment here.
  • Fixed some issues I’d found while making other patches and meant to comment on here, like making sure the Custom HTML block doesn’t inherit styles from pre in the editor
  • Did another quick pass and fixed some minor issues, as well as adjusted some styles for RTL.
  • Removed some styles from the editor-blocks.css that became redundant after adding theme support for editor-styles.

I think we should get the editor/front-end styles nailed first before adding more on.

@davidakennedy That's a good point, it’s probably a good idea to keep things focused at this point. I’d added some wide alignments to Twenty Thirteen as well - does it make sense to take those out for now, too?

#29 @davidakennedy
12 months ago

It may be worthwhile to try using my patch to avoid doing work that I have already done. I apologize for not mentioning these things in my last comment. Thanks

@ianbelanger Dang, sorry about that. Feel free to mention stuff like that in the future. Really appreciate the work! If we have time, we'll double back to the align-wide stuff here.

I’d added some wide alignments to Twenty Thirteen as well - does it make sense to take those out for now, too?

@laurelfulford Good to leave it in there if it's working already.

#30 @ianbelanger
12 months ago

Dang, sorry about that. Feel free to mention stuff like that in the future. Really appreciate the work! If we have time, we'll double back to the align-wide stuff here.

No problem @davidakennedy, I forgot that I had fixed those things when I uploaded the patch. I'll definitely take better notes while working on these in the future. Thanks for reviewing!!

@crunnells
12 months ago

Default image margins

@crunnells
12 months ago

Gutenberg image margins

#31 @crunnells
12 months ago

I took a look, and there's a very minor issue with image margins (see attached screenshots above). Gutenberg includes it's own margins for .alignleft and .alignright, but they don't match the default image margins (which should be 1.5em instead of 1em). Also, the bottom margin for images is 1.5em (inherited from the <p> wrapping the image), but Gutenberg images are wrapped in a <div> then a <figure> tag, neither of which have a bottom-margin by default. Some CSS:

.wp-block-image .alignright {
    margin-left: 1.5em;
}

.wp-block-image .alignleft {
    margin-right: 1.5em;
}

.wp-block-image {
    margin-bottom: 1.5em;
}

#32 @laurelfulford
12 months ago

Thanks @crunnells!

45045.3.patch fixes the margin issue, as well as:

  • Removes bullets from Recent Posts widget in the editor, and fixes margins.
  • Makes sure the citation alignment for the large quote block is the same on the front-end and in the editor.
  • In the function that enqueues the editor styles, swaps get_template_directory_uri() for get_theme_file_uri(), to better match other enqueues in the theme.

#33 @davidakennedy
12 months ago

  • Keywords commit added; needs-testing removed

@laurelfulford This looks good to commit for Beta. Marking it as so in case you can get to it before me today.

#34 @davidakennedy
12 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 43800:

Twenty Seventeen: Add styles and support for the new block-based editor.

This update adds styles and theme support related to the new block-based editor to enhance the experience of using it with Twenty Seventeen.

These are the specific changes made to this theme:

  • Add blocks.css, to style blocks on the front end, to make sure they match the theme’s existing HTML element styles.
  • Add editor-blocks.css to style blocks in the editor, to make sure they match the theme’s existing HTML element styles.
  • Add theme support for editor-styles, to pull the existing editor stylesheet into the new editor.
  • Add theme support for wp-block-styles, to load the default block styles on the front end.

Props laurelfulford, ianbelanger, crunnells.
Fixes #45045.

#35 @ahortin
12 months ago

I've just installed 5.0 Beta 1 and Twenty Seventeen and all the buttons on the Classic Editor toolbar are italicised.

I originally raised this over on Gutenberg Github repo but was told it would be better off mentioning it here.

You can view some screenshots in the Github issue I raised - https://github.com/WordPress/gutenberg/issues/11034

#36 @laurelfulford
12 months ago

Thank you for reporting this, @ahortin! I can recreate this as well.

Since this ticket is closed, I've made a new one capturing this issue: #45188.

#37 @SergeyBiryukov
12 months ago

  • Keywords fixed-5.0 added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for trunk.

#38 in reply to: ↑ 13 @Otto42
11 months ago

  • Keywords changed from has-patch, has-screenshots, commit, fixed-5.0 to has-patch has-screenshots commit fixed-5.0

Replying to laurelfulford:

there are a few elements (like buttons) that Gutenberg includes some more opinionated styles for, but not many.

Is there any explanation for why the buttons were forced into that specific mold? It came up on the forums:

https://wordpress.org/support/topic/wp-5-0-editor-button-styles-lost-broken/

#39 @laurelfulford
11 months ago

Is there any explanation for why the buttons were forced into that specific mold? It came up on the forums:

@Otto42 Oh no! That was an error on my part. The buttons were intended to match Twenty Seventeen's general button styles by default, but they shouldn't be overriding what folks select like this.

I've made a ticket for this here: #45541, and will follow up in the forums (looks like they've moved the report to the Twenty Seventeen forums, as they mentioned: https://wordpress.org/support/topic/button-block-formatting-change-v-18-0/).

I can dig into it more tomorrow. I'll also test the other themes -- I beg the same issue exists in others, since I overlooked it here.

Version 0, edited 11 months ago by laurelfulford (next)

#40 @desrosj
10 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 44148:

Twenty Seventeen: Add styles and support for the new block-based editor.

This update adds styles and theme support related to the new block-based editor to enhance the experience of using it with Twenty Seventeen.

These are the specific changes made to this theme:

  • Add blocks.css, to style blocks on the front end, to make sure they match the theme’s existing HTML element styles.
  • Add editor-blocks.css to style blocks in the editor, to make sure they match the theme’s existing HTML element styles.
  • Add theme support for editor-styles, to pull the existing editor stylesheet into the new editor.
  • Add theme support for wp-block-styles, to load the default block styles on the front end.

Props laurelfulford, ianbelanger, crunnells, davidkennedy.

Merges [43800] to trunk.

Fixes #45045.

Note: See TracTickets for help on using tickets.