Open simison opened 2 months ago
Thank you for summarizing the needs here so well :) This would really go a long way!
Another example from core itself could be the Style Book—rendering on the canvas as a target. The cases where we render a pattern or a template part in isolation also seem relevant since elements like resize handlers could be part of the API.
Another example from core itself could be the Style Book—rendering on the canvas as a target. The cases where we render a pattern or a template part in isolation also seem relevant since elements like resize handlers could be part of the API.
Interesting use cases. It makes me wonder whether we need to replicate the same SlotFill behavior we have for the sidebar. It feels like it would make perfect sense and could become an interesting option for extenders. I'm surprised we don't change the URL or store the visit to the Style Book in the browser history. Going back in the history 7-8 years, that was most likely the primary concern for opening the canvas for extenders.
Some additional contexts to extend the preview window:
https://github.com/WordPress/gutenberg/issues/33578 https://github.com/WordPress/gutenberg/issues/27837 https://github.com/WordPress/gutenberg/issues/34655
A request to be able to remove the filter window if you wish - https://github.com/WordPress/gutenberg/issues/23126
This is great! I'm a huge fan of "Allow extending the editor canvas"- some additional use cases:
What problem does this address?
In https://github.com/WordPress/gutenberg/pull/64644 we allowed extending the "preview dropdown" in a simple, fairly restrictive manner:
This is great for gathering feedback from real usage.
Extending the preview menu and canvas allow variety of publishing flows and tools, some examples:
An example of more complex preview capabilities from Substack done directly in the canvas:
https://github.com/WordPress/gutenberg/assets/87168/f5004855-fb42-4fe9-8fd0-e143a07e0191
Another simpler example from Jetpack Social, opening a modal for previewing:
What is your proposed solution?
Allow extending pre-defined device sizes list
Extending existing devices list is simplest step, as the API could be purely declarative (size, icon, label) and hook into existing functionality:
Examples might be slideshow presentations, TV screens, watches and other more exotic devices. WP is used to build not just websites.
Allow extending preview dropdown menu with multi-selection items
Selections would work in conjunction with existing device-size selectors, and work well with allowing extending editor canvas:
In above scenario you can preview post as a "free" or "paid" subscriber in various device sizes.
Some concerns come from having multiple plugins extend the menu in their own way, and how the menu should then look like. Do we force each plugin onto their own sub-menu or section? Should selections from one plugin clear selections from others? What are the defaults? How do we allow branding show up?
Allow adding multiple sections to preview dropdown menu
Expanding on above example, one could also introduce multiple devices/platforms that are separate from device sizes, such as "email" and "website":
Allow extending the editor canvas
Extending canvas could be done in multiple ways. We could allow:
Allowing replacing the canvas brings up questions like do users expect to always be able edit what they see in the canvas, or can canvas work purely for "previewing" too?