Summary

Gutenberg has a native feature to integrate frontend style to the Gutenberg editor without modification and without risk to impact other parts of the editor.

This inserts any given css file by prepending its rules with a namespace .editor-styles-wrapper. The basic usage is to declare the theme support add_theme_support('editor-styles') and add stylesheets with add_editor_style( $this->theme_dir . '/assets/build/style.min.css' ) for example.

Switzerland is using it already, although generating a different file not including all layout and block styles.

Pros & cons

Pros

• Native solution
• No risk of applying our styles to other parts of the editor
• Adapted (and already applicable) to child-themes

Cons

• Some work required to re-adapt our css rules, with a review of all our blocks
• Default styles can't be removed, and have to be overridden

How it works

Rules are modified on the fly during editor loading and inserted in the editor:

• useEditorStyles()
• transformStyles()

Root tags (body|html|:root) are replaced by the namespace .editor-styles-wrapper, the rest is encapsulated.

Exploratory tasks

• Editor width has to match our .page-template. I've copied page-template rules to wp-block, maybe we can find a more clever way.
• body.scss rule overflow-y: hidden and overflow-x preventing scrolling in the editor. Are these rules really needed in our styleguide?
• H1 heading is not an H1 in the editor, additional css rule/selector are needed.
• Some rules are too specific to work in this context (ie: div.page-template > ul, margins of some blocks) and need rework.
• Default editor-styles-wrapper styles have to be unset/overriden.
• Blocks vertical spacing declaration has to be reviewed to match both frontend and editor

Current issues

• Cannot remove default Editor Normalization Styles
• Allow themes to dynamically add CSS class names to the editor wrapper
• Block Editor: "editor-styles-wrapper" requires custom classes