Add 'has-wide-support' classes and mechanisms

[Luehrsen]

Issue Overview

Support for wide and full sections (images, paragraphs) is a new feature in Gutenberg, that has not existed in vanilla WordPress until now. It is added to the default alignment states (left, center, right), raising the number from three to five. (left, center, right, wide, full)

While the system itself has good UX and acceptance, there are still a few issues in the room.

1. The desire to have finer control when to allow wide blocks More granular control of wide/full block alignment options #4383
2. Problems when switching themes or importing content Properly handle "really wide" blocks when the theme doesn't support them #2595 Content displays incorrectly when switching themes, such as wide or full-width #4342
3. Inconsistencies in alignment handling across blocks Alignment is handled inconsistently across blocks #4010

The desire for this issue is to explore demand, downsides and issues with a system, that streamlines the availability of 'wide-support'.

Base assumptions

Although I believe, that wide-block support will be super trendy upon release of Gutenberg and will become the defacto standard, I would suggest treating the 'has-wide-support' as the exception and assume, that the underlying system does not have support for that.

This is due to the historical context of the alignment system in WordPress and the sheer amount of themes not supporting the system upon launch.

Target

The target is to make certain triggers available throughout the system, that signal the current availability of wide-blocks. This is the first (and probably biggest) departure from the existing implementation of wide-blocks to enable frontend people granular control over where wide-blocks can be available or not. Possible use cases are certain post types and page templates having wide support, while others do not. (e.g. page templates with or without sidebars)

A secondary target is to provide hooks to theme and plugin developers to switch wide-blocks on and off by desire and necessity.

Suggested implementation

Signal class

For frontend (and the editor) it is vitally important to know if wide-support is available or not. So I would suggest adding .has-wide-supprt to the body_class() function, so that .alignwide and .alignfull can be nested in .has-wide-support and simply don't trigger when that class is missing.

Filter

For php we add the has_wide_support filter, that returns false by default and gets switched to true by the theme_support function. That gives devlopers the ability to analyse the current state of the system (e.g. the template to be shown) and manipulate the filter accordingly.

Post Type Support

For post_types we add the wide attribute in the supports array to signal availability.

Page Template Header

For page templates we add the @supports header with has-wide-support or no-wide-support attributes to contradict the global state.

Risks

The risk here is to create a convoluted, complicated system, that no one uses. The intent here is to give finer control to theme devs and simultaneously retain the ability to just switch it on and leave it be. (As it currently is.)

The suggested solutions reach also far into WordPress core and could be too far out for the scope of this project.

What do you think? Does it make sense? Thanks for reading.

[rickalee]

Would love to see wide support being available on a per post type basis.

[azaozz]

See #5650.

We need to add a new PHP var that will hold (default) widths for different contexts, perhaps named $wp_widths.

I would suggest adding .has-wide-supprt to the body_class()...

Instead of making this so elaborate, we can check if wide is set in $wp_widths. It will also control the max-width both in the editor and on the front-end.

[danielbachhuber]

@Luehrsen Do you know if this is still valid?

[Luehrsen]

Yes, we still believe that wide-support as a site-wide option is not practical. Different types of content have different presentations and should be able to react on that.

Examples for that could be a page template with a sidebar (where wide-content is not possible) and a page template without the sidebar (where wide-content is possible). In order to enable the site content I have to do for the whole site.

That leads to the situation, that the user can create wide blocks for the 'with-sidebar' page template, but the wide blocks are shown regularly on the frontend without context why.

[danielbachhuber]

Ok. Flagging as Needs Decision for 5.0

[timhibberd]

@Luehrsen - Could you elaborate further on your comment:

Examples for that could be a page template with a sidebar (where wide-content is not possible) and a page template without the sidebar (where wide-content is possible).

I am a theme designer who has made the assumption that blocks are parent container agnostic and the theme/parent-container will deal with the implementation of wide and full width. So, in my themes, a page with a sidebar is handled fine...the block(s) in the main container can be wide/full width as can the block(s) in the sidebar container. I never assumed that setting alignfull/ alignwide in the block editor was a page-container targeted configuration...only a parent container-targeted configuration.

Thanks in advance. I am championing an issue related to this. If you could spare a moment and have a look and comment that would be fantastic. You seem like someone who knows his stuff. Thanks in advance...much appreciated :-)

[mtias]

I am a theme designer who has made the assumption that blocks are parent container agnostic and the theme/parent-container will deal with the implementation of wide and full width.

This is a fair assumption in the current state of things.

This is the area where phase 1 overlaps with phase 2 elements and comes out lacking. The underlying difficulty is that wide alignments are dependant on a combinations of parents. The same way full-width doesn't make sense as soon as a block is in a nested context like Columns.

Controlling when and where alignments should be exposed is going to become a concern of InnerBlocks but within the context of a template (expressed in blocks) as this would have to dynamically react to the choice of template, etc.

There is not much we can do at this stage since support for wide alignments comes before editor is initialized. You could conditionally register the add_theme_support, which would work in some conditions but not all.

[timhibberd]

Cheers @mtias - I think you misunderstood my comment though...I am actually in agreement with your comment. This appears to me to be a phase 2/3 issue. My comment was asking the issue originator to clarify because, as written, it appears to be a Phase 1 issue that, as a theme designer, I don't have. The one serious issue I do have that I would love your insight on is the related issue #11234. If that one does not get fixed before 5.0 ships legacy themes are going to have a messy time trying to theme the blocks and it's a bell that is seriously hard if not impossible to un-ring after 5.0 ships. Thanks in advance :-)

[strarsis]

Related issue: #19331

[paaljoachim]

Hey @Luehrsen Hendrik!

Is this issue still valid? If not then it can be closed.
Thanks!

[paaljoachim]

Joen @jasmussen I am pinging you to let you know about this issue.

[Luehrsen]

@paaljoachim Thanks for bringing this up again. We have adapted our workflow to work without it, but in the same time we have basically abandoned sidebars. But the issue in itself is still valid in a macro and in a micro sense:

Macro & Micro views

Macro: There are areas in our custom WordPress themes where we would would ideally have the ability to disable wide alignment. On certain, data heavy custom post types for example.

Micro: Sometimes within blocks it makes sense to hide the wide and full view. For example: I have a group block without any alignment. Within that group block I now use a cover block and change its alignment. For the user no visible change is happening, because the parent group block is restricting the width.

How we style alignwide and alignfull

To provide a bit of context I should probably say something about how we're implementing alignwide and alignfull:

As far as we are aware, there are two predominant methods to align blocks in css: The 'minus-margin' method and the max-width method.

The 'minus-margin' method assumes that there is a parent container that has the width of the normal, non aligned content and restricts its children to that width. This is how most themes before Gutenberg were built. To adapt to the (then) new alignwide and alignfull options many developers opted to using negative horizontal margins to break out of the container. (Described by @richtabor here: https://richtabor.com/gutenberg-image-alignments/) The obvious issue is that you suddenly get overlapping elements on alignwide and alignfull where you do not want them.

The 'max-width' method assumes that alignfull is the default state and defines max-width values of every child depending on their alignment. I think this is about how the editor backend is built. The issue here is as described above.

Conclusion & Status Quo

Yes, with three years of experience I still think that the methods described above are needed. But with three years of experience I also think that this method should be implemented on the block level to inform blocks and children if alignfull and alignwide are available in the specific context on the block.

For that second question an ideological question should be answered first: Should a block be able to go 'alignfull' if the parent is only 'alignwide' or not aligned at all and what does 'alignfull' mean in that context?

[youknowriad]

The issues raised here actually fixed now with the new "theme.json" layout system. The implementation is different but the principles are the same.

[mateuswetah]

The issues raised here actually fixed now with the new "theme.json" layout system. The implementation is different but the principles are the same.

@youknowriad, while I agree that the core issue here is solved with theme.json, is there any place where the strategy of a per post type alignwide activation/deactivation is being discussed? I've been searching on the issues and documentation but I am not sure how to do it. Started the investigation here: https://wordpress.org/support/topic/disable-wide-and-full-alignments-for-a-certain-post-type/.

[youknowriad]

@mateuswetah This is something we want to support in block themes (also called FSE themes sometimes), basically these are composed of block templates and each template is a list of blocks, so you can use different "layout" configs for the containers used in each template separately.

[mateuswetah]

Uhmm ok, @youknowriad I can see how this will go in their config files. So for classic themes, there is no official solution so far, right?

The solution proposed to me in the forum did work for removing the alignments options from the insertion. I do this in my after_setup_theme:

$is_post_type_books = $_GET && isset($_GET['post']) && get_post_type($_GET['post']) == 'books';
if (!$is_post_type_books)
	add_theme_support('align-wide');

Then Books are free of the wide alignments. BUT it breaks if I use, for example, a Block Pattern that already counts on wide alignment. Not sure if this is something that I should open an issue for.

[youknowriad]

Yes, I'm not sure this is something we'll be investing a lot of time in for classic blocks, I believe you could filter the block_editor_settings_all and check the context there but it will have similar results as your shared snippet.

For block patterns, the issue exists regardless of the theme (fse or classic), in other words it should be a guideline when creating block patterns: they shouldn't assume existing context, they should be auto-sufficient and work cross context.