Description
What problem does this address?
When you use supports.layout
you also opt-in to the style overrides provided by Gutenberg. This is great when you're using one of the supported layouts, but if you want to supply a custom one, you'll may need to override the runtime styles with something more specific since they aren't related to the layout you're creating.
As a specific example, we would like to use the 'default'
and 'grid'
layout types. We also need a carousel type but that isn't one of the supported layout types.
What is your proposed solution?
What if we add server and client filters so that developers can create their own custom layout styles?
- Client
packages/block-editor/src/layouts/index.js
needs a filter to get new layout types in. Since these objects have the controls as well as the style generation they're pretty much a one-stop shop.packages/block-editor/src/layouts/definitions.js
also needs a filter for the base styles. (I'm kind of confused why there's two files in the first place!)
- Server
gutenberg_get_layout_definitions()
is a great place for a filter that can return a custom layout type.gutenberg_render_layout_support_flag()
needs a filter to return styles from the custom layout.
This lets us use supports.layout
where we need to but deviate from it without having to deal with the difficulties of mixing supported and unsupported layout types.
Activity