Interesting idea but more questions than answers...
The 'block' idea makes sense in the context of WordPress, but WordPress 'blocks' include layout blocks as well as content blocks.
You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
We have embedded content from third-party parties already e.g. a tweet 'block', a YouTube video, an Instragram post, etc. The result is embedded 'blocks' stitched together to make a slow-loading page with a mess of HTML and CSS code (and a host of third-party cookies). How can the block protocol avoid this?
As I said, interesting idea but many questions remaining at this early stage.
> You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
That's part of how blocks are implemented, but we already have higher-level blocks made from HTML elements in the form of Web Components, and various JS libraries.
The protocol is aimed at building on this to standardise how those higher-level blocks communicate with the applications using them.
> Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
This is an area of the spec we need to develop - the goal is a light-touch way of blocks appearing visually consistent with the application around them, while leaving the rest up to the block. The current proposal is some kind of theme variables the application can pass to the block for use, but needs more thinking - https://blockprotocol.org/spec/block-types#styling - and we appreciate any thoughts.
How can the block protocol avoid [issues with current embeds]?
Partly by focusing on standardising how you pass data back and forth between the block and the application: blocks which aren't of the application, and don't need to know about it, but allow users to edit data that lives in the application.
Agree that slow loading is an issue to address, which is easier to deal with when you control all the source code, less so when you're pulling in blocks from elsewhere - the first step in this is for blocks to be able to leave the provision of common libraries to the embedding application, so that each block isn't shipping React (or whatever).
The 'block' idea makes sense in the context of WordPress, but WordPress 'blocks' include layout blocks as well as content blocks.
You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
We have embedded content from third-party parties already e.g. a tweet 'block', a YouTube video, an Instragram post, etc. The result is embedded 'blocks' stitched together to make a slow-loading page with a mess of HTML and CSS code (and a host of third-party cookies). How can the block protocol avoid this?
As I said, interesting idea but many questions remaining at this early stage.