In reply to Nick.

Hi Nick,

I’ve been thinking about your observations for the last number of days and as for the inconsistencies you mention, these highlight some of the weakness in the block editor, once you push its abilities beyond simple content creation.

Spacing is a good example. At the moment there is a plethora of third party block solutions, all doing the same thing but from what I can see, engineered in different ways. If any of these plugins gets disabled or abandoned, it seems that there is no logical way for another third party alternative to slot in and take up the mantle.

This point to a major gap in the rational of how the block editor works. From the start a strict set of block types should have been established, those for discrete elements: paragraphs, headings, dividers, etc and then those for structure and layout: sections, containers, rows and columns. To these foundational elements all the styling points, like for spacing should have been added. On simple themes these finer points of styling could be hidden, controlled by the theme. Beyond this, an API or hooks. Could be used by third parties to open up all the styling possibilities, bells and whistles and even allow for page builders to add a better more sophisticated UI.

I add the last point, because, even though currently many page builders are slow to the races in terms of performance, usability is far superior than the block editor.

This may change by the way for one builder in particular. If successful said builder is due for a complete under-the-hood re-engineering, similar to how the block editor delineates itself with comment tags. I understand that this won’t be a full integration with the block editor and I understand why. Looking back up to my point on the block editor not sticking to a strict set of block elements, there is no point doing this.

As it is, with all the different block options offered by third party vendors we may end up in the same Heath Robinson space that the block editor was supposed to avoid.