Guest Essay

Costs Of WordPress Joining The Block Protocol

What are the costs, drawbacks and red flags of WordPress joining the Block Protocol?

different lego type building blocks side by side

WordPress founder Matt Mullenweg has shown his interest in having WordPress join the Block Protocol, a recently-launched specification to allow JavaScript blocks be reusable across applications. As the WordPress editor, aka Gutenberg, is already attempting to create bridges across applications with its blocks, joining the Block Protocol could play a role in making Gutenberg blocks also available outside of the WordPress domain. 

Upon learning about Matt’s interest, I wrote Implications Of WordPress Joining The Block Protocol, in which I examined the potential benefits for the WordPress community, and for the open web in general, if WordPress indeed satisfied the Block Protocol for the Gutenberg blocks. 

Certainly a great idea comes with costs attached. Sometimes the costs are negligible, sometimes they are high enough to kill the project. As I had not yet explored these costs by my previous article, I shared only the potential benefits of the proposal, but not its negative elements. 

In this new article, I will explore the adverse aspects of the idea, attempting to answer: What are the costs, drawbacks and red flags of WordPress joining the Block Protocol? Having this information we can then decide: Would WordPress be better off by joining the Block Protocol, or would its downsides make it not worth it?

It’s not clear how block styles will be handled

The goal of the Block Protocol is for any compliant application to be able to embed any compliant block. As a result, there can be no hard-wirings between application and block, and all information is injected via props. In other words, the block must itself be a black box, whose inner workings are hidden from view, and the application can only manipulate the block by operating its API. This is a problem concerning styling. If the application doesn’t know what’s the inner configuration of a block (if it uses a <div> or a <p> or a <section> or an <article> or what else, and what classes in defines on each HTML element), then how can it reliably apply some intended style to the block?

The current solution is based on defining a fixed set of CSS properties (or variables) in the specification, whose values can be passed from application to block via props:

Embedding applications SHOULD provide a styleVariables object passed to the block alongside other fields, containing any of the theme variables listed in Appendix A which they have a preferred value for.

The variables for the chosen properties currently are:

  • primaryColor: a primary theme color for main action elements and fills
  • secondaryColor: a secondary color for highlights and variations
  • borderColor: a color to use for borders for tables, boxes, etc
  • borderRadius: the radius of borders for tables, boxes, buttons, etc
  • backgroundColor: a color to use as the background for elements
  • fontColor: the default text color
  • fontFamily: the default font

Clearly, these properties are not enough to give a custom and unique personality to our blocks. For instance, basic properties such as paddings and margins are not mentioned.

These limitations have been recognized in the specification, and the community has been invited to provide feedback via a GitHub discussion. An entry suggests to expand the list of CSS properties, to also include:

  • tertiaryColor
  • secondaryBackgroundColor
  • baseFontSize
  • typeScale
  • baseSpaceSize
  • spacingScale
  • borderWeight
  • iconSize
  • boxBorderRadius
  • buttonRadius

But even then, will these extra CSS properties be enough? I don’t believe so: there will most likely be some CSS property that we need, which the Block Protocol does not support. When that happens, we may very well end-up checking the source code of the block, identify its inner workings, and create some custom CSS code just for it, indeed defeating the goal of the Block Protocol.

As the Block Protocol would inherently be restricting our options for styling with its predefined set of CSS properties that we can use for our blocks (that is, unless it supported passing all CSS properties as props!), we will never attain the peace of mind of knowing that we can customize a block with the personality that we intend to, and be able to succeed.

Generic blocks can easily become bloated (or risk being underwhelming)

Blocks can ship with functionality attached to them. For instance, the table block in the Hub not only displays the information on the table, but also provides tools to sort and filter the data:

The table block

As blocks are generic, to be used by any application, block developers may be tempted to embed within plenty of extra functionalities, to make the block more attractive. As a result, the block will very likely contain functionality that the application does not need, becoming bloated. 

If we don’t need this extra functionality, we can certainly hide it (the block should provide a way to do that via props), but its code will still be within the block. This extra code will also be transmitted over the Internet, making the load of the webpage slower, the parsing and execution of the JavaScript also slower, and unnecessarily consuming more energy.

Generic blocks will not be as good as native blocks

Using a block from the Block Hub will make sense as long as there is no equivalent block in the WordPress editor already, or offered by some third-party WordPress plugin. The reason is that generic blocks can never match native blocks in their integration with the underlying engine, in this case with Gutenberg.

In Gutenberg, we can use a combination of inline-editing and two controls, the block toolbar and settings sidebar, for editing and configuring the block:

  1. Inline-editing to input content to the block as a WYSIWYG
  2. Block toolbar to provide simple/generic block configuration (eg: make text bold/italic, align paragraph to left/center/right, add links, etc)
  3. Settings sidebar to provide more complex/customized block configuration (eg: adding class names, setting margins/paddings with a visual component, or other custom functionality)

Items 2. and 3. are rendered by the application, so they directly depend on the WordPress block editor API. For instance, to display the “alignment” properties in the Block toolbar, we must add Gutenberg component BlockControls (plusnested components) to the block:

    value={ attributes.alignment }
    onChange={ onChangeAlignment }
</BlockControls>Code language: HTML, XML (xml)

To specify controls in the Settings sidebar is similarly done by adding Gutenberg’s InspectorControls component (plus nested components) to the block:

<InspectorControls key="setting">
  <div id="gutenpride-controls">
      <legend className="blocks-base-control__label">
        { __( 'Background color', 'gutenpride' ) }
      <ColorPalette // Element Tag for Gutenberg standard colour selector
        onChange={ onChangeBGColor } // onChange event callback
      <legend className="blocks-base-control__label">
        { __( 'Text color', 'gutenpride' ) }
      <ColorPalette // Element Tag for Gutenberg standard colour selector
        onChange={ onChangeTextColor } // onChange event callback
</InspectorControls>Code language: HTML, XML (xml)

As native blocks have access to the Gutenberg API, they can make full use of the possibilities offered by the application. Additionally, they can support opinionated features not normally expected from a generic block. That’s the case, for instance, with the duotone filters available to the image blocks:

Controls in the Post Featured Image block

A generic block could be “compiled” for Gutenberg, and offer the same controls offered by native blocks. But in this situation, those same controls may also need be defined in the generic block (not necessarily the implementation, but at least their definition), because just knowing the type of some field in the block is not enough to be able to decide what controls to show on it. 

For instance, fields of type string can behave differently: 

  • “Hello world”: HTML content property, can add italic, bold, alignment, etc
  • “display: flex;”: Plain-text property to store some extra CSS classname or property, no controls are needed

 The same situation can happen for fields of type integer: 

  • A price: it can have a slider to increase/decrease the value
  • A post ID: it can show a dropdown with all existing posts

 In addition, what controls to show can depend on the purpose of the field, or on some intended style or presentation. For instance, the content of the blog post can be formatted using HTML controls, but not the excerpt. 

If generic blocks still intended to have feature-parity with native blocks, possibly by mapping all their features and satisfy them somehow (whether automatically by feeding some configuration to a script, or manually by the block developer), then they would be pretty-much chasing after Gutenberg, treating it as its “upstream” of block design, and the idea of a block that works everywhere, irrespective of the application, would not be true anymore. If that’s the case, why even bother with it? We’d rather just go straight to Gutenberg.

Adapting the JSON schema would produce breaking changes or additional complexity

At the heart of a block (whether a Gutenberg block or a Block Protocol block) is a JSON schema, a piece of configuration defining the properties contained in the block, and their type (string, int, array, etc.). For Gutenberg and the Block Protocol to communicate smoothly, their JSON schemas must be compatible. 

Which is not the case nowadays. Gutenberg requires the file block.json (starting from WordPress 5.8), and the Block Protocol requires the files block-metadata.json and block-schema.json (the name of the first one is mandatory, the second one is custom). These files are similar in concept, but yet different, hence the two systems are currently not compatible. 

To make them compatible, there are two options: 

  1. Have Gutenberg completely adopt the Block Protocol: ditch block.json and use block-metadata.json and block-schema.json instead, with their specified format and data requirements.
  2. Run a script that takes block.json as input, and produces block-metadata.json and block-schema.json as output.

 The first solution would produce a breaking change. Then, WordPress core would need to implement a new version of the JSON schema, and also keep maintaining the current implementation for backwards compatibility. 

The second solution involves incorporating an intermediate step to bridge between the two systems. Then, the Gutenberg JSON schema would be the single source of truth, but it would need to be “compiled” to work with the Block Protocol using some schema-transformation tool. This would add complexity, as we’d need to test that two different block formats work as expected.

It would limit the development of custom features for Gutenberg

Due to the nature of Gutenberg and WordPress, there are features that may particularly make sense within their context, but possibly not in a general context. As such, these features would not be supported within the context of generic blocks. 

For instance, in an ongoing discussion on the Gutenberg repo, there is a proposal to introduce “dynamic tokens” to the block. A token would enable to replace a predefined static value within the block, such as “<!– token:author-name /–>”, with a value fetched dynamically from the queried entity, such as “Leonardo”. 

The recommended approach proposes the introduction of a new tokenSupport entry in block.json:

  "attributes": {
    "url": {
      "type": "string",
      "source": "attribute",
      "selector": "img",
      "attribute": "src"
  "tokenSupport": {
    "core/featured-image": {
      "selector": "img",
      "attribute": "src"
}Code language: JSON / JSON with Comments (json)

As there is no equivalent for tokenSupport in the Block Protocol, or even for defining custom block properties just within the context of a specific application (since that would pretty much defeat the goal of the Block Protocol), then the Block Protocol would not allow Gutenberg to support this proposed feature.

There is no example of a Block Protocol app yet

While the Block Protocol has similarities with GraphQL in that they are both specifications, there are differences on how and when are the organizations who created them released them into the wider world. 

GraphQL was created by Facebook in order to power their own website. By the time the first version of the spec was released, Facebook had been working on it for three years, and was already using it in production. The fact that this new specification was already powering provided enough reassurance for several other companies (including Shopify and GitHub) to decide to embrace it. 

The Block Protocol, instead, has been launched before having any fully-functional implementation of a compliant application. HASH, the company that created the protocol, is developing an application on the Block Protocol and making it available as open source, but it is currently a work in progress:

This app is not yet ready for production use. For now it is intended to be used as a test-harness for developers building Block Protocol-compliant blocks. It is currently not secure, not optimized, and missing key features.

As such, there is no example application yet to guide us on integrating the Block Protocol into our applications. 

There is no ecosystem of Block Protocol apps yet

One of the potential benefits of the Block Protocol is that Gutenberg blocks will be used outside of the WordPress realm. This is a lofty idea, but it cannot be backed by any fact out there, because there are no Block Protocol apps yet, and we don’t know if there will be.

Of course, one of the reasons of WordPress joining the Block Protocol is to give credibility to this project, aiming to give confidence to the overall community for them to embrace it. But this is a bet, so we can’t rely upon it, and it may very well be that the Block Protocol never becomes widely adopted. 

The Block Protocol is still a draft

To compound the previous two sections, the Block Protocol is itself still a work in progress. This can be currently considered a red flag for a few reasons. 

For one, if the specification were to be adapted based on real life use cases, since there are no applications using it yet, the protocol may very well be subjected to substantial modifications once applications start making use of it sometime in the future. Then, any integration carried out nowadays may need to be redone. 

For another, several known sections are currently incomplete: 

And finally, unknown sections may also need be incorporated into the spec, waiting to be found out once an application discovers its lack thereof. For instance, there is no “configuration” section in the protocol, which could enable the embedding application to decide what additional controls to display on the block (such as a “content” field indicating it accepts HTML, and an “excerpt” field only receiving plain text). 

As explained earlier on, the lack of definition for styling could in particular prove to be a serious blocker, since if not dealt with properly it could render the Block Protocol unreliable and, as such, impractical. 


WordPress joining the Block Protocol undoubtedly sounds like a terrific idea (at least to me). But as with anything that is good in life, it unfortunately doesn’t come for free. How bad is the cost? Can we afford it? Or is it not worth it? 

In my previous article, I had analyzed the benefits of WordPress joining the Block Protocol. In this new article I complement that information, by also analyzing the negative aspects. Having all this information, we can then answer the inevitable question: Would WordPress be better off by joining the Block Protocol? 

What do you think? Join the conversation on Twitter.

Author Profile Image

Leonardo Losoviz is an open source developer and technical writer, working on integrating innovative paradigms (including Serverless PHP, server-side components, and GraphQL) into WordPress.

Subscribe & Share

If you liked this article, join the conversation on Twitter and subscribe to our free weekly newsletter for more 🙂

MasterWP contains no affiliate links. We’re entirely funded by the sponsors highlighted on each article. In addition to MasterWP, we own EveryAlt, WP Wallet, Understrap and Howard Development & Consulting.

Latest Posts