The biggest user-facing difference between WordPress’s current editor – the classic editor – and the new Gutenberg editor is the block interface. Gutenberg is a block-based editor. But what is a block? How are blocks different to the classic editor’s familiar editing interface? Why were blocks chosen instead of some other content editing abstraction?
WordPress users don’t often interact directly with a post’s HTML. It is possible to write content in HTML, wrapping it in the required tags, but it’s inconvenient for everyone and challenging for users who don’t know HTML. The classic editor is an abstraction from the HTML that makes it easier to write and publish content.
The user writes their post, adds images, and applies formatting. WordPress takes care of translating the representation the user sees into the HTML that it and browsers can work with, and back again for further editing. It’s surprisingly difficult to get this right — the organizations that build web browsers spend millions of dollars to hire the smartest developers to work on HTML parsing. There are many ways to cause issues when transitioning between representations.
That’s one of the reasons the text in the editor doesn’t always behave as you might expect it to. Occasionally, users are forced to edit the HTML directly because of formatting glitches, incorrect addition of white spacing, and other difficulties.
The classic editor is a leaky abstraction. Its job is to abstract away the complexities of the underlying HTML, but those complexities are not hidden as well as they might be. The editing experience is affected and constrained by the HTML representation.
The leakiness of the abstraction becomes even more apparent where shortcodes are concerned. Shortcodes are snippets of code that add functionality or content to the page, but they bear little relation to an ideal editing experience. They provide no clue about what they do. There is no obvious visual representation of their functionality.
Blocks Are a More Watertight Abstraction
The classic editor gives users the abstraction of a post, which has an occasionally uncertain relationship with the HTML that WordPress relies on. In Gutenberg, we have the block instead.
A block is a unit of content that provides an intuitive user experience. What the users see in the interface is everything that they should need to know about a block. There is no HTML lurking behind it to cause problems. Blocks encapsulate their functionality and its presentation, allowing users to focus on the content while WordPress takes care of the hidden complexity.
As the Gutenberg Handbook puts it:
“The main point is to let the machines work at what they are good at, and optimize for the user and the document.”
In Gutenberg, everything is a block that lives in the framework of the post or page. There are simple rules for adding new blocks, moving blocks around in relation to each other, and configuring their behavior.
But that point isn’t while the user is interacting with them. While they are being edited, posts with blocks are kept in memory as a complex tree-like data structure containing content and configurations. When stored to disk, the data is serialized as the HTML that WordPress and plugins expect. There is a back-and-forth translation between the block data structure and HTML, but it is not something the WordPress user needs to think about.
There are trade-offs in any significant change, and some WordPress users regret that Gutenberg’s editing interface is several steps removed from the final HTML output, but for most WordPress users, Gutenberg is a long-awaited improvement.