Add document-level controls and instant preview #16641
Labels
[Feature] Extensibility
The ability to extend blocks or the editing experience
Needs Technical Feedback
Needs testing from a developer perspective.
[Type] Enhancement
A suggestion for improvement.
Comments
|
The specific example to add a CSS class to the document wrapper relates to:
I know that doesn't cover the full scope of the issue but I wanted to share some extra context. |
swissspidy
added
[Type] Enhancement
|
This is largely the scope of the styling project at #20331 — it should allow most of these interactions but one crucial difference is it doesn't rely on wrapper class names (classes being an implementation detail) to ensure the system can work across platforms, including native mobile. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature request
Provide an API / method for manipulating document-level elements and providing instant preview of these manipulations within the block editor and eventually in whatever space document-level controls will live.
Rationale
Theme authors may want to provide the author with document-level controls like color palettes that apply to entire posts/pages/views on an individual basis. This scenario is already relevant (see BinaryMoon/jarvis#11) and will become more relevant as blocks migrate beyond the block editor to the full view.
Example scenario
A theme provides a post/page palette option in the document-level controls. When selected, a new class is appended to a top-level element (
.editor-styles-wrapperelement in the editor,<body>or other element on the front end) and CSS kicks in to restyle whatever content exists below that element in the DOM tree.Current challenges
While adding controls for this type of feature can be done using metaboxes or the new SlotFills, and data from such controls can be captured in post meta and used on the front-end, there is (to my knowledge) no straight-forward way to get an instant preview of such DOM manipulations within the block editor. The workaround is to use an EventListener to target elements on setting change, but this is hacky and prone to error.
Proposed solution
Having a similar framework to how blocks are instantly previewed on setting change would be great. Providing one cohesive model for creating controls, capturing their data, and previewing the result in the editor context ensures developers don't come up with a myriad of different hacky ways of doing this which stand in the way of document-level manipulations in the future.
Related
BinaryMoon/jarvis#11 (comment)
https://developer.wordpress.org/block-editor/tutorials/plugin-sidebar-0/
The text was updated successfully, but these errors were encountered: