Block width (content width) needs to be resizeable

[maddisondesigns]

WordPress has a $content_width variable that allows you to set the maximum allowed width for any content in the theme. Although this is mainly used on the front-end, in the back-end TinyMCE editor, you can use the following css in your editor-style.css file so that you can set the editor width to match the front-end content width.

html .mceContentBody {
	max-width: 900px;
}

The editable area in the Gutenberg blocks are currently only 608px wide, which, when used on a large monitor, are pretty tiny. It would be good to see the editor make use of the $content_width variable so that we can accomplish the same as the current editor.

[afercia]

Just to add some references, and note there was some discussion about the $content_width in the past: see the main conversation on this Trac ticket:
https://core.trac.wordpress.org/ticket/21256#comment:25

Also, other minor references:
https://core.trac.wordpress.org/ticket/23863#comment:10
Automattic/_s#100 (comment)

[jasmussen]

Good ticket.

Let's explore a hypothetical for a moment, though — pure speculation and daydreaming. What if there was no editor stylesheet (custom-editor-style.css). What if we simply loaded the pure theme stylesheet (style.css) as the editor style? Would we need a separate max-width variable at all? Wouldn't it be up to the stylesheet to define this behavior?

[jwold]

From a readability point of view, once you go too wide (although there is discussion on what is too wide: https://www.paulolyslager.com/optimal-text-layout-line-length/) it can get harder to read the lines of text. Right now I'm seeing that the box has 65 characters (the lowercase x) which is considered pretty optimal (although there are variables of course)

There are a few approaches you could take:

1. Leave it as is and force this width of content area regardless of screen size
2. Start with a default and allow the user to make the content area wider (adding a setting for content width in the post settings panel)
3. Grow the content area as the screen grows, but cap it out at something like 100 characters per line, just so it doesn't get too wide and becomes really challenging to read the lines
4. Grow the content as the screen grows and don't cap it. Allow it to grow as wide as your screen.

I think option 2. makes the most sense. Agreed/disagreed?

Edit: Another option could be to allow for increasing the font as you increase the width of the content area. From this article: http://mikeyanderson.com/optimal_characters_per_line. From this article: "I’m sick and tired of cramped websites that have tiny type and don’t use the whole screen well."

[maddisondesigns]

As I mentioned above, I'd prefer to see it use the $content_width variable (or some other similar variable, if appropriate). The whole idea of being able to set the width of the (existing) TinyMCE edit area is so that you can get a feel for how your content will display on the front-end, while you're actually adding it.

I very rarely see themes displaying extremely long lines of text, for the exact reason you mention. They're too hard to read. Using the same width on the edit screens, as is being displayed on the front-end, keeps a consistency between the two.

[jwold]

Using the same width on the edit screens, as is being displayed on the front-end, keeps a consistency between the two.

Ah I missed that! I think that's a great idea for the editor to use the same size as the frontend. It would help if the fonts were the same too.. I know WordPress uses the default system font, and a theme could use any font.

If the fonts stay different then it won't be a perfect comparison. Is that a concern?

[maddisondesigns]

@jwold Ideally, a theme should make use of the editor-style.css file so that you can use the same styles in the editor, as you do on the front-end (including fonts). Admittedly though, there's an awful lot of themes out there that don't both doing this so you end up using a different font and slightly different styles in each area. I don't think think this is a big deal personally. I would love the size/width to match the front-end though, even if the fonts don't match perfectly.

[jwold]

I would love the size/width to match the front-end though, even if the fonts don't match perfectly.

I think this makes sense. Do you think there's value in defaulting to the width of the frontend and then giving you the ability to change it for writing your posts? That way if I prefer it wider or shorter I can just focus on writing and not worry about the final output.

[maddisondesigns]

Do you think there's value in defaulting to the width of the frontend and then giving you the ability to change it for writing your posts?

I think that would be great. You get the best of both worlds then. Having it default to the front-end width but also the option to change it if you prefer. Sounds perfect! 👍🏼

[georgeolaru]

Let's explore a hypothetical for a moment, though — pure speculation and daydreaming. What if there was no editor style sheet (custom-editor-style.css). What if we simply loaded the pure theme stylesheet (style.css) as the editor style?

That would be the "grand finale" moment when the content creating experience will be consistent all over the place: while editing and on the front end preview. I highly support this approach, even if we provide some core styling for blocks that are automatically loaded into the front end until the theme adds support for them.

These days of dynamic and responsive design, I cannot imagine a static defined $content_variable when you can have a customization option named exactly Content Width. So, loading the theme style.css (or at least a part of it), would solve this and many other issues.

[jasmussen]

See also #2420

[jeffpaul]

@maddisondesigns, this was reviewed during a Gutenberg bug scrub today and the following came from the discussion:

The theme will change the width of the container via CSS, which is already possible. The enhancement will come once/if we implement the grid layout from PR #4314. With that in place, the theme will be able to define the grid and all blocks would accommodate.

[maddisondesigns]

@jeffpaul Thanks for the update. Is this grid going to be applied to the markup produced on the front-end as well? It doesn't mention that in #4314. The whole point is to be able to have the back-end match the front-end (in terms of content-width, that is).

[jasmussen]

As per a recent refactor, the Gutenberg variables stylesheet now includes a single $content-width variable: https://github.com/WordPress/gutenberg/blob/master/edit-post/assets/stylesheets/_variables.scss#L35

This variable is currently used in 11 places:

Although we are in a responsive and mobile first world, probably themes or even blocks will probably always, for flexibility reasons, need to know what the width of the main column is. JavaScript and mixins could probably reduce this dependency further.

Noting this as context for anyone who might want to take a stab at connecting the $content-width SASS variable with the $content_width PHP variable.

[burnuser]

I think the existing fixation of content width in Gutenberg is - according to a lot of Gutenberg reviews - a really big problem for a lot of people. So this should be addressed in the Gutenberg core before going live with WP 5.0!

Let me collect the arguments to change something:
1.) Fixed width breaks WYSIWYG for a lot of WP Themes on regular screens. (Created webpage looks different in editor and in regular browser view.)
2.) Working with larger amounts of text/content is painful and confusing on a small editor (creates much more linebreaks and show less content without scrolling)
3.) Working with columns is a terrible pain on a small editor interface (each column has very short lines!) - and native columns are advertised as big advantage of all new Gutenberg!
4.) People (including existing and new WP users) are used to work with long lines. MS Office, LibreOffice, Google Docs and each texteditor in the world works with full screen width! Forcing them to a super small editor interface would not make Gutenberg more accepted. In fact it is a foreseeable breaking point for refusing to work with Gutenberg at all.
5.) Even when shorter lines are more readable for some people, you should not make it a dogma. It's much better to make it an option (for example in the post/page options menu)!
Let people make their own decision, if they want the editor interface: super small (existing Gutenberg standard), controlled by theme (classic TinyMCE Standard - with a fixed fallback if no values given) or custom width.
I can not imagine that such a selection is so complicated to set up that no one from the Gutenberg development team can handle it.
And offering it would not only resolve a lot of existing complaints, it will also avoid much more future ones after going live with WP 5.0!

[zackify]

At the very least could the editor default to 100% width so it can mimic a real page? It's really weird dragging something inside a column block when it's so narrow, but will actually render full screen.

[jasmussen]

One way you can change the width of the main column today is the following.

Paste this in your functions.php:

/**
 * Enqueue editor style in Gutenberg
 */
function mytheme_gutenberg_styles() {
	 wp_enqueue_style( 'mytheme-gutenberg', get_theme_file_uri( '/style-editor.css' ), false, '1.0', 'all' );
}
add_action( 'enqueue_block_editor_assets', 'mytheme_gutenberg_styles' );

Now create a new CSS file in your theme directory, style-editor.css that contains the following:

/**
 * Editor style
 */

body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block {
    max-width: 900px;
}

You can set any max-width here, in px, percent or whatever unit you prefer.

[maddisondesigns]

@jasmussen Adding that one style makes a mess of the layout. Check out the following samples:

Standard Gutenberg layout:

Layout after adding your one style:

There's a number of issues:

• The Title field isn't increased to match the rest of the content
• All Wide aligned content (i.e. images, tables etc) changes to be the same width as the images with no alignment
• All Full aligned content (i.e. images, tables etc) become left aligned and no longer full width

These are the styles that I've found to work properly:

.edit-post-visual-editor .editor-post-title { max-width: XXXpx }
.edit-post-visual-editor .editor-block-list__block { max-width: XXXpx }
.edit-post-visual-editor .editor-block-list__block[data-align="wide"] { max-width: XXXpx }

*Obviously XXXpx is whatever width you want to use.

This is what the page looks like after using my styles. I've calculated the max-width for each section based on a customizer setting which allows the user to specify the width of their content on the front-end.

[jasmussen]

Nice, thanks for updating those styles.

Do you think an editor style like yours could be part of the solution here? It feels like it might get us closer.

[maddisondesigns]

I've found those styles seem to be working ok so far. One of the issues I've found though in trying to get the editor width to match the width of the front-end content, is having to allow for all the extra padding and margin on the containers in the editor.

As an example, I mentioned above that in the theme I've edited, I'm calculating the max-width based on a Customizer control. I have a control in the theme that allows the user to specify the width of the main content area on the front-end. e.g. 1200px for example.

If I simply set those editor classes all to 1200px pixels, then it still wont match the front-end due to markup used in the editor. So, get the editor blocks to match the same width on the front end, I've had to take into account the various margin and padding of all your block containers. And of course, because this final max-width value is calculated based on a Customizer setting, I obviously can't add the value to a static stylesheet, so this is my full code that's injected into admin_head on editor pages:

function ephemeris_child_dashboard_editor_css_styles() {
	global $pagenow;
	$defaults = ephemeris_generate_defaults();
	$styles = '';

	if ( ( !$pagenow == 'post.php' ) && ( !get_post_type() == 'post') ) {
		return;
	}

	// Increase width of Title
	$styles .= '.edit-post-visual-editor .editor-post-title {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 98 ) . 'px;}';

	// Increase width of all Blocks
	$styles .= '.edit-post-visual-editor .editor-block-list__block {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 28 ) . 'px;}';

	// Increase width of Wide blocks
	$styles .= '.edit-post-visual-editor .editor-block-list__block[data-align="wide"] {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 28 + 400 ) . 'px;}';

	echo '<style type="text/css">' . $styles . '</style>';
}
add_action( 'admin_head', 'ephemeris_child_dashboard_editor_css_styles' );

Obviously, if we could simply set a $content_width variable or two, it would make all this considerably easier than using this work around. We'd need to be able to set the width of the main blocks, and also a separate width for wide blocks.

On a side note, if there was a hook that I could use other than admin_head that was specifically for gutenberg editor pages, this would be even better. I don't know if one exists at the moment or not. You may be able to answer that for me.

[jasmussen]

One of the issues I've found though in trying to get the editor width to match the width of the front-end content, is having to allow for all the extra padding and margin on the containers in the editor.

Interesting, I thought I had solved that, at least for non-nested blocks (with an incoming fix for nested blocks in #6408). But I can see that there's a 2x14px discrepancy left and right of blocks, that matches the left and right padding. I'll take a look in a bit.

On a side note, if there was a hook that I could use other than admin_head that was specifically for gutenberg editor pages, this would be even better. I don't know if one exists at the moment or not. You may be able to answer that for me.

Can add_action( 'enqueue_block_editor_assets', 'mytheme_gutenberg_styles' ); work for you?

[maddisondesigns]

Can add_action( 'enqueue_block_editor_assets', 'mytheme_gutenberg_styles' ); work for you?

With a couple of small tweaks, yep, that works. Thanks!

admin_head is obviously called later than enqueue_block_editor_assets. Using admin_head the styles were output after all the default WordPress/Gutenberg styles. Using enqueue_block_editor_assets the styles appear above the default WordPress/Gutenberg styles in the <head>.

This not a big deal, but it does mean I've had to add a bit more specificity to the styles, like you had in your original example.

There's a couple of things I had to do...
First, I added body.gutenberg-editor-page to the front of the exsiting styles that I had.
Second, because of that extra specificity, the style that increased the width of all blocks also ended up affecting the full width blocks. That's not too big of a deal though. I've just added an extra style for the full width block now as well.

On the plus side, using the enqueue_block_editor_assets hook, now means that I can get rid of that hacky code that I had that was making sure it only added the css to Editor pages.

Here's my updated code:

function ephemeris_child_dashboard_editor_css_styles() {
	$defaults = ephemeris_generate_defaults();
	$styles = '';

	// Increase width of Title
	$styles .= 'body.gutenberg-editor-page .edit-post-visual-editor .editor-post-title {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 98 ) . 'px;}';

	// Increase width of all Blocks
	$styles .= 'body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 28 ) . 'px;}';

	// Increase width of Wide blocks
	$styles .= 'body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block[data-align="wide"] {max-width: ' . esc_attr( get_theme_mod( 'ephemeris_layout_width', $defaults['ephemeris_layout_width'] ) + 28 + 400 ) . 'px;}';

	// Remove max-width on Full blocks
	$styles .= 'body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block[data-align="full"] {max-width: none;}';

	echo '<style type="text/css">' . $styles . '</style>';
}
add_action( 'enqueue_block_editor_assets', 'ephemeris_child_dashboard_editor_css_styles' );

Or to simplify things, these are the styles to now set...

body.gutenberg-editor-page .edit-post-visual-editor .editor-post-title { max-width: XXXpx }
body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block { max-width: XXXpx }
body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block[data-align="wide"] { max-width: XXXpx }
body.gutenberg-editor-page .edit-post-visual-editor .editor-block-list__block[data-align="full"] {max-width: none;}

[jasmussen]

With a couple of small tweaks, yep, that works. Thanks!

🎉

Very cool work, thank you.

I would imagine we can continue to refine aspects of this, to improve the hooks, and to make styling the editor more easy — I'm also doing some work on that in #6406. The ultimate goal would be to make it possible to load in your theme style itself, with no changes, so you didn't have to create a separate editor style, but it's likely going to be a while before we can get there. Baby steps.

[maddisondesigns]

Being able to enqueue the same stylsheet on both front-end and back-end sounds great in theory, but not sure how practical it would end up being. At least for the foreseeable few years, our themes on .org will now have to accommodate both the Gutenberg editor and the Classic editor. This means that its not as easy as simply having a separate style sheet for both. For example, there's obviously a lot of common styles that need to be used when using either editor (font styles for example). There's also a considerable amount of styles that aren't compatible with each other, and also styles that we now have to override due to the default styles output by Gutenberg.

So yeah, while it sounds like it would be a great idea, I'm a bit doubtful that it would actually work in practice for the majority theme developers, unless you're specifically developing a theme purely for use with Gutenberg only.

[jasmussen]

So, given your improved styles in #1483 (comment), could this ticket be closed with some improvements to documentation? I.e. if I wrote some new documentation that showed how to change the theme-width per your code, would that essentially address this ticket?

[maddisondesigns]

Yep, that's fine. Thanks. Having a content width variable would be nice, but those above styles work fine and there's only really 4 styles that need to be set, so it's not a big deal to set them if needed. Having the doco updated for other devs would be great too.

Thanks for your help with that.

[jasmussen]

Created #6531 to update the documentation.

[azaozz]

Being able to enqueue the same stylsheet on both front-end and back-end sounds great in theory, but not sure how practical it would end up being.

I agree. The editor HTML has very little in common with what the content will look like on the front-end. Loading the whole theme CSS will certainly "bleed" in many places where it shouldn't.

Ideally there should be few variables that hold the different widths, and can be reused on the front. These variables can also go in the $content_width PHP global (or some new way to set them from PHP), see #5650.