Suggestion: Text Width in Gutenberg Based on Theme

Hi @slkfsdf8y34ljhsfsdfkuhfkl84hj!

I agree WYSIWYG is the end-goal, and there are a number of efforts underway to make the editor look as much like the frontend as possible.

Already today, a theme can register an editor style that sets the dimensions of blocks in the editor to the same dimensions as you see on the frontend. You can see this in themes like TwentyNineteen, and they’re using this code to make that happen: https://developer.www.ads-software.com/block-editor/developers/themes/theme-support/#editor-styles

Hope that helps.

So it’s optin, rather than available for all?

How can a non-developer help WordPress move faster to that goal?

I mean both Gutenberg and WordPress does make progress, the open source idea, participation and collaboration is all good.

But, here is a big but – there are plenty of page builders and competitors which already have significant share and do have WYSIWYG.

How can we speed up things?

To be honest I am OK for WordPress taking even more drastic measures to push things forword.

> So it’s optin, rather than available for all?

Well it’s a little more nuanced than that. The block editor will eventually be able to edit your entire website in one view — header, sidebar, footer, all of it in one window. In that vein, we can’t easily rely on something like $content-width like the classic editor does. But instead the goal is to load the theme stylesheet _itself_ into the editor, eliminating the need for that variable in the first place.

This has been quite a technical challenge to get to, but it’s actually closer than one might think. For example, an iframe is one step that will help enable it to happen, which is being worked on in https://github.com/WordPress/gutenberg/pull/21102.

Full site editing and WYSIWYG is the priority for this year, so there’s wide agreement with your assessment! If you’d like to help, you can contribute, we’d love that! Some good places to start: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

More on customization: https://make.www.ads-software.com/core/2019/11/02/join-the-gutenberg-customization-conversations/

The closer the better as I am tired of the page builders that offer WYSIWYG but slow down sites considerably. Yet, I would like to see what the end user would see. That is very helpful when you have long form contact and you want to write it the way it would be presented to the user.

Agreed!

I think there should be a toggle:

1) Normal view – the content is matching what the end user sees in terms of font, line height, styling, spacing, width etc.

2) Stretched view – for these with 27″, 32″, 34″ and 38″ monitors which would want to see their content stretched to the size of their window and that way work and scan their article for other types of edits when you have a very long form content. That was possible with the classic editor and helped me in many cases when I had to insert for example 30-40 images and arrange them in a very long form content or other type of build editing of articles in bulk like searching for words, double spaces etc on a large screen. That increases the productivity a lot in many specific case scenarios.

@joen ,

I’ve recorded a 20 minutes journey of an attempt to move an image from a top of a post to the bottom.

It shows various of bugs, glitches and lags that I describe in detail.

If you want, you can use that to help you improve the situation for Gutenberg.

https://www.youtube.com/watch?v=GHiRySSUkd4

Absolutely helpful, thank you. Honestly both the movers and drag and drop deserve an iteration. Watch the Gutenberg issues for a ticket soon.

As you saw I wasn’t able to accomplish a task – moving the image from the top to the bottom on a long form content.

I can logically divide the issues into these:

1) Extreme lag on drag and drop of images on a long form content page with many images.

2) Lack of scroll when moving an image to the bottom of the view page.

3) Lack of scroll with the mouse wheel when you drag an image on browsers other than Safari.

4) Interface movements with pixels which prevents you from clicking up or down multiple times.

5) Lack of “you can drag it” symbol for the average consumer.

6) Cut and Copy of a block image that works 1/20 times and paste that is not working most of the times, when it comes to image blocks.

Kind Regards

@joen ,

If it is not too much to ask and not too much time consuming, please let me know about the URLs so I can keep track and potentially find a way to contribute to these or bookmark to follow them and transit to Gutenberg once resolved. I would understand if you can’t show me the URLs there or if it is too much to ask.

I really think the 6 points summarize + video the issues.

That would help not just me, but everyone that uses Gutenberg as I am sure a lot of people are scratching their head when they see these issues.

Kind Regards

I’ll try and remember to come back to this post when I see it pop up. But I know from core editor chats that the mover control being hidden, and drag and drop being flaky has been discussed a lot, so I’m sure a ticket to revisit this will land soon.

But the place to look is here: https://github.com/WordPress/gutenberg/issues

Can I create issues on GitHub based on these 6 points without proposing a solution? I can record and extract the exact 6 main issues.

You should absolutely be welcome to create issues. However I’d look for existing issues first, I’m almost certain there are tickets for 5 and 6, and there’s possibly for the others.

Thanks for your help!