The Language of Gutenberg

Language of Gutenberg – Starting with WordPress 5.0, Gutenberg will be the all-encompassing editor of the future. This future offers more than simply a replacement for the existing TinyMCE-powered editor; it also aims to redefine the term “content” beyond the WordPress implementation specifics. In summary, Gutenberg’s ultimate objective is to allow users to modify anything from a post’s text post_content to all of the components aesthetically. Surrounding it on a page, as well as the templates that make up a website.

Language of Gutenberg img1
Above all, an editor for rich content

Gutenberg accomplishes all of this by introducing the block as the fundamental unit of content and customization. Blocks appear to be brand new on the surface. Unsurprisingly, common content types are represent by blocks: a text, a picture, and a button.

History – Language of Gutenberg

WordPress has a long history of rich content that extends far beyond just text. Since the release of the TinyMCE WYSIWYG editor in version 2.0 (2005). There has been a widespread belief that content is solely constrained by HTML. Later versions of the project included widgets (plugin, 2006) and shortcodes (2.5, 2008), which are now standard features of WordPress content management.

Perhaps the thread about post formats is more interesting. In 3.1 (2011), functional support for them was add, allowing themes to utilize them to show content differently—for example, an “image”-type item might be present without a title—and plugin developers to experiment in new ways. WordPress, on the other hand, has set its sights on a higher goal, and in 2013, the project was planning to add a new Post Formats UI in its next version (3.6).

Language of Gutenberg img2
The Post Formats UI in 2013

Despite the obvious Tumblr connections. The goal of this project was to propose a new way of thinking about how the material is generate, rather than just presented, depending on what it is. It would go well with the default WordPress theme of the year. Twenty Thirteen, which was a fantastic example of what post formats might imply for themes. In the end, the UI was never integrate into the core, and post formats never developed into a more robust content semantics solution.

Principles – Language of Gutenberg

Certain guidelines for Gutenberg may be specified from the start. They naturally match with WordPress’s ideology, which emphasizes openness and prioritizing content.

  • Backwards compatibility and graceful degradation: The move to a new editor should never cause one’s previous material to be lost or harmed in any way. The newer technology should be able to interpret the information in its original language, or at the very least leave it alone.
  • Portability: Nothing should be tethered to one’s content. This implies that content shouldn’t be bound to any runtime, whether Gutenberg or WordPress in general, and that a solid interaction with other editors (mobile applications, MarsEdit, and so on) should be established.
  • No commitment when adopting Gutenberg: This is a logical extension of the preceding point. Gutenberg adoption for early testing or curiosity should not be view as an irrevocable change to one’s content. Content shouldn’t be change in an unreasonable way if Gutenberg is disable. Third-party blocks should be treat similarly in the future. In a world of proprietary software and software-as-a-service, there is a strong need to combat lock-in, which is not new but is ubiquitous.
  • Incremental development: Gutenberg intends to radically change WordPress, which will take time given that WordPress powers 30% of the Internet and has millions of users.

HTML is the format

Some HTML analogies arose as a result of these principles:

  • WordPress is the Web, and HTML is the Web’s format.
  • It’s free, portable, and one of the most likely digital forms to endure. In almost all programming environments, it is human-readable and understood.
  • It’s semantic, designed to describe documents in a variety of ways, focusing on content for the user’s benefit.

In terms of expressive capability, HTML has gone a long way. Modern HTML pages may now focus entirely on the user’s content, with presentation details and dynamic behaviors outsourced to more competent complementing technologies like CSS and JavaScript. With a few limitations, this might make HTML the greatest option for the new semantic block-based editor’s format.

Finally, adopting HTML implies that the editor’s final artefact, like a painting or a sculpture, is the content’s canonical format, not a consequence.

HTML Comments

Put your HTML comments here. These are, in fact, HTML’s native invisible markings, which are recognize by all browsers and other user agents but are ignore by default.

Language of Gutenberg img3
HTML comments

With their introduction, the content recognition problem may be divide into two parts. The first stage of this layered method is to determine what is what at a glance. HTML comments come in handy here: a paragraph here, a display of a site’s most recent entries there. Any work that goes beyond this basic recognition is assign to stage two, block-specific analysis.

Furthermore, the structure of the material is never harm when HTML comments are use. In contrast, any block markup would have to be wrap in <div> tags or limited to a single top-level aggregator element in the previous situation. As long as the structure is acceptable HTML, comment-demarcated blocks choose their own structure.

Blocks: Higher-order than HTML

I mentioned an HTML caveat before. HTML is semantic, but its expressive capacity is restricts. It can convey broad structure — body, sections, and paragraphs — but it can’t distinguish between citations and pull quotes. HTML5 includes the idea of figure and its companion caption, which is a welcome addition to the standard. Ultimately, no generic HTML, or any other domain-specific language, will be sufficient to communicate the subtlety between a film poster and an actor’s image.

Blocks have a wide range of meanings – poster, portrait, haiku, and koan — and therefore improve HTML. Because HTML comments reify blocks, they may be thought of as meta-HTML. In the end, they are rendered as pure HTML for the page visitor, and the demarcations vanish (they are currently stripped out by the WordPress server); different blocks may produce the same markup — as in the case of the film poster and actor portrait blocks — but the content editor and the presentation engine both understand the unique nature of each block.

Block Attributes – Language of Gutenberg

Content sources – Language of Gutenberg

Attributes enhance the fundamental meaning of a block. For example, a poster’s characteristics may include its image source, the film it represents, and whether or not it is a featured work, in which case it will be shown more prominently (through larger alignment and/or being the featured picture of a post). As a result, content, metadata, and presentation preferences are all included in the concept of the attribute.

Attributes can come from a variety of places. To make things easier, one of the sources is the content of the block: in the example of a paragraph block, the attribute text would be the markup inside the block’s
element. Another source is the block’s opening HTML comment, which may be use to encode data that is difficult to obtain from content: for example, in the instance of a paragraph block, the property drop-cap is a Boolean that indicates whether the displayed paragraph should be head by a drop cap. A comprehensive list of attribute sources may be found in the Gutenberg manual.

Toggling the drop cap attribute

Comment attributes are store as a JSON object:

<!-- wp:paragraph {"dropCap":true} -->
<p class="has-drop-cap">Si quelqu'un se propose comme problème …</p>
<!-- /wp:paragraph -->

There is information duplication and the material bears the mark of the drop cap setting (class=”has-drop-cap“). When the attribute is toggle, the editor changes the text of the paragraph block, allowing for a visual change. The ability to reliably migrate to a different content format (e.g., adopting a different class name or converting to a hypothetical new HTML construct like <p drop-cap>…</p>) by first reading the comment data and then verifying the content is an advantage of comment attributes.

Dynamic blocks – Language of Gutenberg

When you look at the figure in HTML Comments again, you’ll see that there’s a block in the middle that stands out since it appears to have no content:

<!-- wp:latest-posts {"categories":"1","postsToShow":3,"layout":"grid"} /-->

The Latest Entries block is dynamic in nature, presenting the most recent posts on a site when a page is request. Its attributes determine which categories to display (categories), how many to display (postsToShow), and whether to display the posts as a list or a grid (layout). It should be self-evident that it does not require static material to function inside its confines.

In this case, a seasoned WordPress artisan would note that the block is quite similar to a shortcode:

[latestposts categories="1" postsToShow="3" layout="grid"]

The primary distinction is that dynamic blocks are completely equivalent to any other block in terms of editing and storage (whereas stock shortcodes do not have a rich-editing mode). The only difference is that dynamic blocks provide a render_callback. Whose output the server will utilize as block content during front-end page rendering. This equivalence has the intriguing side effect of allowing dynamic blocks to contain static content:

<!-- wp:latest-posts {"categories":"1","postsToShow":3,"layout":"grid"} -->
<!-- /wp:latest-posts -->

The content of this iteration of Latest Posts is the URL for the corresponding category view’s RSS feed, as specified in the attributes. When is this going to be useful? In any situation when post_content rendering is inconvenient or undesirable. For example, newsletters are offline communication methods for which a soon-to-be-outdate list of recent postings would not make sense. Shortcodes, on the other hand, don’t have this technique and are infamous for making their way into newsletters undigested.

Beyond the content

The aforementioned attribute sources aren’t the only ones that may be use in blocks. Attributes, for example, may be obtained from post meta, allowing blocks to work automatically inside the context of the post they’re put into. Authors will need meta support to migrate from the present age of WordPress, which is built on Custom Post Types, custom fields, and meta boxes, to a completely block-based paradigm.

Other sources may be add to Gutenberg, either directly or by extensions. Site options will be a source in 2018, opening the way for blocks like Site Title and full-page customization.

The logic flow of the editor 


Finally, what is refer to regard as the Gutenberg language formed a conceptual foundation for the editor very early on?

The parsing stack is layer as well, with block recognition performed by a parser defined by a formal grammar and attribute sourcing performed later according to each block type’s specification; the editing logic is then based on the block-filled application state derived from serialization; and so on.

More curiously, the foundation has shown to be resilient enough to support circumstances that were either not anticipated or would have been postponed to a later stage of the project, far after WordPress 5.0. Block nesting, content validation, hybrid (static + dynamic) blocks, reusable blocks across articles, and the flexibility to grow with HTML standards are all examples of features. This is in addition to the initial aims of backward compatibility and the ability to test and uninstall Gutenberg without losing material.

Built as a separate component, there’s also flexibility for hot-swapping — for example, switching to a different parser or changing the persistent mechanism entirely if necessary.

That’s all for this article if you have any queries please contact us through our website or email us at [email protected]

Leave a Comment