Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#45045 closed task (blessed) (fixed)

Twenty Seventeen: Update theme to add Gutenberg styles and support

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

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 5 years ago.
editor-alignments-after.png (901.5 KB) - added by laurelfulford 5 years ago.
Editor - Alignments (after)
editor-alignments-before.png (748.8 KB) - added by laurelfulford 5 years ago.
Editor - Alignments (before)
editor-common-blocks-after.png (1.5 MB) - added by laurelfulford 5 years ago.
Editor - Common Blocks (after)
editor-common-blocks-before.png (1.3 MB) - added by laurelfulford 5 years ago.
Editor - Common Blocks (before)
editor-formatting-blocks-after.png (81.7 KB) - added by laurelfulford 5 years ago.
Editor - Formatting Blocks (after)
editor-formatting-blocks-before.png (112.2 KB) - added by laurelfulford 5 years ago.
Editor - Formatting Blocks (before)
editor-widget-blocks-after.png (268.7 KB) - added by laurelfulford 5 years ago.
Editor - Widget Blocks (after)
editor-widget-blocks-before.png (331.9 KB) - added by laurelfulford 5 years ago.
Editor - Widget Blocks (before)
45045.1.diff (30.0 KB) - added by ianbelanger 5 years 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 5 years ago.
Separator in Editor
separator-front-end.png (19.4 KB) - added by davidakennedy 5 years ago.
Separator on Front End
blockquote-editor.png (69.5 KB) - added by davidakennedy 5 years ago.
Blockquote in Editor
blockquote-front-end.png (76.7 KB) - added by davidakennedy 5 years ago.
Blockquote on Front End
cover-image-front-end.png (107.4 KB) - added by davidakennedy 5 years ago.
Cover image on front end.
45045.2.patch (29.1 KB) - added by laurelfulford 5 years ago.
image-margins.png (344.4 KB) - added by crunnells 5 years ago.
Default image margins
image-margins-gutenberg.png (278.6 KB) - added by crunnells 5 years ago.
Gutenberg image margins
45045.3.patch (29.6 KB) - added by laurelfulford 5 years ago.

Change History (59)

#1 @mor10
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years ago

please fix a small accessibility bug mentioned in #44699

@laurelfulford
5 years ago

#8 @laurelfulford
5 years 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
5 years ago

  • Keywords has-patch added; needs-patch removed

#10 @ianbelanger
5 years 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
5 years 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
5 years 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
5 years 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 5 years ago by laurelfulford (previous) (diff)

#14 @celloexpressions
5 years 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
5 years 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
5 years 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
5 years ago

Editor - Alignments (after)

@laurelfulford
5 years ago

Editor - Alignments (before)

@laurelfulford
5 years ago

Editor - Common Blocks (after)

@laurelfulford
5 years ago

Editor - Common Blocks (before)

@laurelfulford
5 years ago

Editor - Formatting Blocks (after)

@laurelfulford
5 years ago

Editor - Formatting Blocks (before)

@laurelfulford
5 years ago

Editor - Widget Blocks (after)

@laurelfulford
5 years ago

Editor - Widget Blocks (before)

#17 @laurelfulford
5 years ago

  • Keywords needs-screenshots removed

#18 @ianbelanger
5 years 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
5 years 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 5 years ago by nielslange (previous) (diff)

#20 follow-up: @laurelfulford
5 years 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
5 years 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
5 years 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
5 years ago

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

#23 @ianbelanger
5 years 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
5 years 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
5 years ago

Separator in Editor

@davidakennedy
5 years ago

Separator on Front End

@davidakennedy
5 years ago

Blockquote in Editor

@davidakennedy
5 years ago

Blockquote on Front End

@davidakennedy
5 years ago

Cover image on front end.

#25 @davidakennedy
5 years 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
5 years 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
5 years 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 5 years ago by ianbelanger (previous) (diff)

#28 @laurelfulford
5 years 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
5 years 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
5 years 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
5 years ago

Default image margins

@crunnells
5 years ago

Gutenberg image margins

#31 @crunnells
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years ago

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

Reopening for trunk.

#38 in reply to: ↑ 13 @Otto42
5 years 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
5 years 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 bet the same issue exists in others, since I overlooked it here.

Last edited 5 years ago by laurelfulford (previous) (diff)

#40 @desrosj
5 years 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.