Blockers for launching "Try Gutenberg" callout in core

[danielbachhuber]

Following up on my original assessment eight weeks ago, I did another review of the entire issue and PR backlog yesterday. There are still some, but not too many, issues I think we need to resolve before launching the "Try Gutenberg" callout in core.

Notably, this list is subject to interpretation and open to debate. My qualifier for "Try Gutenberg blocker" is that the issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled). There's no sense in users experiencing this pain if we're already aware of it.

To recap the issues:

• Problem: Gutenberg <-> Classic Visual Editor don't work together well re: paragraph handling, notably:
  • Opening Gutenberg post in Classic Visual editor adds unwanted <p>&nbsp;</p> content.
  • Gutenberg breaks "classic" posts w/ shortcodes by carelessly wrapping shortcodes into <p> tags.
  • Unexpected content changes toggling Classic editor from Text to Visual to Text. Superseded by Create warning user experience around editing Gutenberg post in Classic Editor #8213
  • Resolution: This seems like a hot mess that I'm still wrapping my head around. Maybe there's a silver bullet?
• Problem: Block conversion can behave unexpectedly, notably:
  • Converting a table in a classic block to a table block removes all inline styles. Superseded by Table block: flesh out editor features #6923
  • Modifying a block's HTML can cause an unexpected "This block appears to have been modified externally." error Also related Code Editor needs WARNING!. Superseded by Block Validation, Deprecation and Migration Experience #7604
  • Converting To Blocks Loses Existing Anchor Tag Parameters.
  • Converting blocks lose anchor tags
  • Use of loop and autostart in <audio> causes unknown error
  • CSS classes are removed during conversion to blocks.
  • Convert to blocks breaks images with Captions
  • Resolution: Independent of permitting arbitrary HTML attributes / values for Gutenberg blocks, we need to: 1) improve the UX around "appears modified externally", 2) process more common HTML attributes by default.
• Problem: New lines in shortcode content are ignored
  • Resolution: We should properly convert multi-line shortcodes, and support multiline shortcodes in the Shortcode Block. This work is started in Blocks: Shortcode: Support multi-line shortcodes #4942.
• Problem: Drag and drop uploading doesn't respect multisite max upload size
  • Resolution: This is a problem in the REST API controller itself (the limit isn't enforced). We need to make sure the limit is enforced both server-side and client side.

Two other sets of issues that seem like they could impact a large number of users, but aren't necessarily blockers, are:

• <table> support (e.g. Table block: flesh out editor features #6923 Add additional formatting options to the Table block inspector sidebar #7008 Add text alignment controls to Table block toolbar #6699 Table cells shouldn't use fixed pixel widths #4027 Table cell widths don't resize properly after inserting column #4026 Can't tab between cells in table block #4025 Table block markup in the front-end #2904 Tables: no method to define row or column header cells (th) #1470)
• Galleries (e.g. Gallery block Full/None alignment bug #7099 Gallery Random images display missing #6259 Gallery Block doesn't apply the 'post_gallery' filter, causing incompatibility with WP Gallery Custom Links #5972 Gallery: Support for ID-less shortcode #3852 "Attachment Page" link setting doesn't work for Gallery Block #6896 Images → Gallery transform fails for ID-less images #3698 Gallery: choosing thumbnail size #1450)

[ZebulanStanphill]

Is the Columns block planned for WordPress 5.0? I think the Columns block is currently too limited to be useful, and it should be either improved to have responsive functionality and non-equal-width columns, replaced with something better, or removed before the "Try Gutenberg" callout goes out. See also:

• Add support for non-equal width columns #4902
• the Layout block mockups in Grid empty space issue in Columns block #5351
• Add container divs for each column in the Columns block #5935
• Support for Responsive Columns #6048
• Add Block: Responsive #6650
• New Block Layouts #6993

Additionally, the Text Columns block is also still a thing even though it is even more useless than the current Columns block and made obsolete by it. See #6506.

For optimal content conversion from the Classic Editor, I think #6520 needs to be merged before the callout, so that blockquotes with more complicated content will be preserved better.

#5941 and #5970 should also be resolved before the callout. There needs to be a decision made: is the Classic block supposed to exist purely as a legacy fallback? Or should its use be encouraged for those who want an editing experience with mixed content and various inline formatting options? I think the recommended way to have a lot of this stuff would be to use plugins that do things like add text color buttons to all the core blocks or add a "Freeform text" block that acts similar to the Classic block while being more adapted to Gutenberg design. Recommending use of the Classic block for anything other than legacy content seems like a bad idea to me.

The callout will likely increase the amount of plugins developed for Gutenberg, so the Gutenberg API should be mostly stable by then. I think #2751 needs to be resolved before a callout, as that is the last big API change (that I am aware of) that has not happened yet. See also: #6733.

[brianhogg]

Are we okay with the masses trying this out with all the accessibility issues remaining (ie. #179)? This affects a large number of users.

[danielbachhuber]

Hi @SuperGeniusZeb / @brianhogg,

Thanks for the feedback. There's certainly a ton of work to be done before WordPress 5.0 ships. I think the issues you've mentioned are good candidates for 5.0. For "Try Gutenberg", I'd like us to focus on blockers exclusively first, where "blocker" is defined as "causes some amount of data transformation that would be non-trivial to recover from at scale". Time-permitting, we can also work to address high priority issues that aren't necessarily blockers.

[GlennMartin1]

I agree with @supergeniuszeb - the Columns are a necessary thing to get perfected. I don't think that can be overstated.

The folks that get introduced to Gutenberg because of the callout are not the adventuresome folks like many who are following the beta project now. Hence, I suggest a fairly polished version prior to introducing it to novices.

Of the 680 open issues in Git, over 200 are tagged as "[Type]Bug". Perhaps those should be focused on at some point prior to the callout. No one wants tons of duplicate issues being raised.

Most importantly, first-impressions are critical, and a poor first-impression could deter 1000s of folks from upgrading when WP 5.0 is released. Gutenberg has a great start, but please wait long enough for the callout to give the new audience a stellar first-impression.

[ZebulanStanphill]

Since my previous comment, several Gutenberg releases have happened and a bunch of stuff has been resolved. In addition to what is mentioned in the main post, here is what I think still needs to be resolved:

• The lack of non-equal width and responsive columns in the Columns block. (Support for Responsive Columns #6048)
• Updating the Quote block to use nested blocks for optimum content conversion from the Classic Editor. (Use nested blocks for quotes #6520)
• Adding a Container block. This feels like such a basic thing, and it has a lot of potential uses, yet for some reason there is not even an initial implementation. (Add Block: Section #4900)
• Resolving the whole issue with how attributes should be defined on the server/client and other server/client-side issues that require API changes. The API should be almost entirely stable when the callout happens. (Block API: Server-side awareness of block types #2751)
• Inspector controls should be easy to extend/modify/remove, and should have a whole lot more documentation. (Allow for core block Inspector Controls to be extended and removed #6023)
• The Text Columns block should be removed. (Remove Text Columns block and convert existing ones to Columns + nested Paragraph blocks #6506)

Elaborating on that last one, I think it would be a good idea to remove it before the callout for the following reasons:

• It does nothing that cannot be accomplished by the Columns block better
• Its name may imply to some that it wraps text into columns like a newspaper, which is actually something you can do with CSS, but is not at all what the block does. This could cause unneeded confusion.
• It existing alongside the Columns block may also cause confusion.

[lkraav]

Elaborating on that last one, I think it would be a good idea to remove it before the callout for the following reasons:

On top of that, merging "Container" block idea into "Columns, where single-column === container" might be a good optimization, too.

[ZebulanStanphill]

@lkraav Just to be clear, right now each column in a Columns block is actually a separate block: a Column block.

Given that a Column is usually expected to have different settings from a Container (like its width compared to other Column blocks in the same Columns block), I am not sure that is a good idea. Column blocks do not have any settings right now, though, so this depends somewhat on how the Columns block develops.

Some questions that should be answered first:

• Will column-specific settings be put on each individual Column block? They might be put there and exposed through the inspector for each Column, or they could be exposed through the settings being moved up to the parent Columns block.
• Does it make sense for a Column to control its own relative width, or is that something the parent Columns block should manage?

Maybe you are right. Having Container blocks nested directly in Columns blocks would certainly be a a good optimization in having fewer <div>s (and blocks) being used for content structure. But I would wait and see how the Columns block develops before merging the Column block into the Container block. Starting with two separate blocks and then possibly merging later seems like the right approach to me. I think converting existing Column blocks into Container blocks would be much easier to do in code than converting only Container blocks which are directly nested in Columns blocks into Column blocks if it is discovered that the two concepts should be separate.

On a related note, I have been looking into Oxygen lately, and I am really impressed by its flexbox-based layout system. I think perhaps a flexbox-based layout block could be a good addition to Gutenberg in the future. It could act as a nice alternative to the Columns block, or maybe even a full replacement depending on how powerful it becomes.

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

[ZebulanStanphill]

I think #6102 is something that may be desirable to get fixed before the callout, simply because it may be a common source of frustration and duplicate issues. I know I certainly do not like my <abbr> and <code> tags being stripped out upon conversion even though the Paragraph block supports those tags.

[danielbachhuber]

My qualifier for "Try Gutenberg blocker" is that the issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled).

I'm pretty happy with where things are at now... 🚢 🚢 🚢

[ZebulanStanphill]

@danielbachhuber Are you sure about that? There are still some issues with conversions from the Classic block. See the latest comment in #6102.

[danielbachhuber]

Are you sure about that?

Yes.

There are still some issues with conversions from the Classic block.

I agree this is important to address in some way, but I don't think it needs to or can happen in the next few days. I'll comment on that issue directly.