Proposal for opening the editor interface to more extensibility

[fabiankaegy]

Proposal:

At the moment the interface of the editor has a very limited set of slots and filters exposed to make modifications to how the interface works. And I think that is very much on purpose and has its reasons. We can see in the standard WordPress admin how cluttered and overwhelming it can get by notices and panels that get injected everywhere. (I'm taking these concerns around opening up the interface to more slots from conversations like the one in #17198)

However, I believe that the restriction of the available slots and filters is holding back experimentation. At the moment the only way to explore new features for the editor is by essentially forking it and manipulating the core code directly. Which is a huge commitment to be taking on and therefore not something that everybody will do. If it would be possible to make these kinds of experimentations in feature plugins this could spark a whole new wave of experimentation and opportunities to get contributions.

Examples:

Posts without a title present on the page:

A good example of what I am talking about is the exploration in #27093. The ability to not have a title visible in the post editor but still be able to modify the title and permalink is something that would be very cool to be able to test in a feature plugin/custom build of a project and iterate on with actual users to then be able to report back the findings to make a solution for core better.

Custom settings that semantically should live next to core settings in a settings panel

Another example is needing to add custom settings to a page like maybe a toggle to hide the sharing options on a specific post. It would be a much nicer user experience for the editor when this setting could be placed inside the "Page Attributes" sidebar panel. Instead of having to add jet another custom sidebar panel which only houses one singular setting.
(Related issue: #31888)

Greater control over the placement within slots

And even for slots that already are available like the slot to insert something at the end of the "Status & visibility" panel would really benefit from the ability to have more control over where a setting should get inserted.

The BlockControls component recently gained that ability by allowing developers to control the group they belong into. These kinds of controls allow developers to insert new functionality into the semantically correct places within the editor and therefore create a much better UX than needing to have custom panels for everything.

In this last example, being able to define which group the custom setting should be slotted could look something like this:

<PluginPostStatusInfo group="visibility">
    { // insert custom setting here }
</PluginPostStatusInfo>

Closing Thoughts:

Through the data API, all the data already is accessible and can be modified from anywhere. If we would now also have more slots to place custom settings in the main toolbar or all of the sidebar panels that would be a huge win.

At the end that is how Gutenberg itself and so many other features in WordPress work. The software itself is flexible enough so that feature plugins can experiment and improve the main software by sharing experiments that worked.

I don't have all the answers here of how we could achieve this and also ensure that plugins don't overwhelm the editorial experience by misusing these slots to clutter the interface. And I would love to hear others' thoughts around this. From my perspective, I would love to be able to experiment more on actual builds with real-world feedback to then inform the approaches in core better.

[ndiego]

I completely agree, especially when it comes to Slots. They are very easy to add and theoretically could be added to every core sidebar panel. Ordering slotted content is quite tricky, but at least adding the Slots themselves would be a massive improvement.

[youknowriad]

While on principle I'd like for the editor to be as extensible as possible, I think it's important that we stick with the guiding principle we set from the start for the block editor: Only add semantic extensibility. The rare exceptions we made to this rule came back to bite us very quickly. Let me explain.

It's important to keep in mind that:

• The UI of the editor will keep evolving and won't be stuck as it is.
• Blocks and block editor concepts will continue to grow and absorb more complexity: Like we moved from post editor to site editor and template editor, we'll need to absorb complexities like collaborative editing, multi-lingual, frontend rendering, cross platform blocks...
• We need to continue making the editor and our code performant over time.

Introducing filters and extensibility randomly often contradicts or affects one of the three goals above.

• If we introduced a slot for instance to the previous implementation of the color palette on the inspector sidebar, we would probably be stuck today with the incomplete design and not be able to introduce elements like we did (background, text, link...)
• If we introduced Slots on the initial version of the inserter, introducing patterns and reusables and the "explore patterns" modal... would have been almost impossible because of the backward compatibility for slots.
• The filter we have for The BlockListBlock component is one of the exception I regret, it's too low level and prevent us from making some important performance optimization in the editor.

So while I'm not against adding extensibility APIs, I think we should always ask yourself the question about what exactly this API is for, is it semantic enough, is it something that evolves as the UI evolves, is it something that will prevent us from evolving and optimizing the code.

Unfortunately, the answer to this last question is in 99% yes, it's going to hurt us and that is why seemingly, the block editor has less extensibility.

I think I'd prefer us in general to have "registration like" APIs:

• Add/remove a block style
• Add/remove a block variation
• Add/remove a document setting
• Add/Remove a pattern

...

It's different than, I want to tweak this part of the UI but it's more solid over time.

[fabiankaegy]

Thank you @youknowriad for these detailed thoughts. I very much value your perspective here. And your points are very valid. I'm still wondering though how even keeping these constraints in mind we could open the door for more pluggable areas.

The main issue I see with keeping it super closed is that we shut off exploration everywhere except for within the Gutenberg repository itself. And that is something that I very much believe is holding back experimentation and real world iteration. Gutenberg itself is only possible because WordPress allows for modification. Where plugins can try out new approaches and if they work out they can be brought over to core.

I do think that if we are purely talking about the slot fill system there can be more places in the UI that could expose slots in a semantic manner. The slots should not be tied to a specific implementation but rather the semantically tied to already existing settings. I really like the approach that was taken in the early explorations @gziolo shared in his comment here: #37448 (comment)

I can see that the approach of the @wordpress/hooks package may not be the best fit as it makes dev tools less usable and leads to performance issues. So I am not talking about a technical implementation here currently. I mostly want to reboot the conversation for us to evaluate whether there are ways in which we can allow more slots for example or some other system to allow for more experimentation outside of core itself :)

[gziolo]

Thank you, @fabiankaegy, for starting this more general discussion about extensibility. We have many individual feature requests filed over time as issues. Still, now that the block theme becomes part of the WordPress core, we should revisit the Gutenberg extensibility defined in #3330 and #1352.

Can we use this discussion also to collect more ideas that people would solve in the past with filters? The more we know about use cases, the easier it becomes to cluster them and think more broadly about evolving the UI to accommodate those needs.

[fabiankaegy]

Thanks for sharing these two threads :) Very interesting! And of course that is what I was hoping for in starting this as a discussion 👍

[gziolo]

I stumbled upon the PR that proposes making the Preview Menu extensible using Slot & Fill pattern: #31984. Relates issue: #25430.

[gziolo]

There is also an open PR that proposes adding Slot & Fill in the header of the editor: #16988.

[gziolo]

Another proposal for making the top toolbar extensible in #30901.

[jessynd]

Thank you for starting this important discussion, @fabiankaegy! I have another example to share!

Extending the colour contrast warning to include contrast ratio and compliance level

I work with clients in Ontario, Canada, which has strict laws around what level of WCAG guidelines companies must comply with depending on their size,etc.. The majority of my clients have to comply with AA guidelines. Some organizations here need to comply with AAA guidelines because they're very costly to meet in many cases for smaller orgs. Failing to comply with these guidelines in Ontario can cost a company up to $50,000 in fines per day.

When I deliver a website to a client that must comply with WCAG guidelines, I often share with them the website https://contrast-ratio.com which enables them to add a background and text colour and find out what the exact contrast ratio is, and which guidelines that ratio meets and at what font size.

Contrast Ratio Screenshot

In the Block Editor, users are prompted with a warning when the contrast between their background and text colours is not high enough but it doesn't provide any information about which level of accessbility guidelines it complies with and also doesn't seem to be affected by font-size.

Block Editor Warning Screenshot

It would be so great if the colour contrast warning in the sidebar could be extended to be able to show the exact numerical ratio of the contrast between the selected colours as well as which level of compliance it would meet. For regular users this might be confusing but for organizations that have strict laws to follow, it would be a very helpful message.

[aristath]

I just made a PR related to this: #41363, I hope that helps somewhat.