How it should be done

Hi Lee,

Really enjoyed your demo on the Page Builder Summit yesterday. While I am not a Tailwind CSS user, more a Divi user, I totally agree with the way you have implemented your system from a minimalist point of view, where only the existing blocks in core are extended or, as you have done, reduced to be manipulated with the Tailwind CSS only.

So far I have some niggles with the Gutenberg project which I see as fundamental design flaws in the long run; the fact that they didn’t nail the main layout and structural elements (Sections/containers, rows and columns + better responsiveness on device breakpoints ) and make these, along with all the other blocks, a restricted set which third parties could extend, via an API, with their own UI, bells and whistles.

So far I see many vendors out there making their own implementations of block sets where they are reinventing the wheel. Seems to me that they are perpetuating the age old problem where, if you disable any one of these solutions you potentially lose content, layout or both, whereas, if WordPress had a core foundation of set blocks, turning off or switching to another solution would retain content and maintain layout to some degree. Having this systematic approach would have had more buy-in from page builder vendors and subsequently a better overall direction in the development of the Gutenberg project. It would have also driven better consistency and interoperability between builders.

What you have done makes the whole enterprise of using the block editor “Safer” and in this context third party vendors should only be allowed to override existing blocks in core by plugging in their own UI and features.

• This topic was modified 3 years, 1 month ago by irishetcher.