For the case of a football website, you could have blocks which display or edit data which doesn't need to be tied to football specifically, but can be used to build/display the football website, e.g. (I'm just going to…
I appreciate that you can use whatever JS you want when constructing custom elements. To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out…
> iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like…
The idea is more that you build your website out of blocks which allow the display or editing of defined data structures - so you search for blocks which are compatible with the data you want to work with (which can be…
We're focusing on the browser context at first, but expect the principles of the interface between a block and application (if not the implementation details) should be applicable to other environments - very briefly…
1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it…
Thank you! If you have any learning from your own work you'd care to share, or thoughts on ours, please drop by the repo (https://github.com/blockprotocol/blockprotocol) or Discord (https://blockprotocol.org/discord)
> If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page. As it stands we're reluctant to dictate the internal…
> Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business). 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…
The parties to the protocol (in this early form, with a web focus) are: 1) an application which is generating a web page, and 2) a block of functionality which is part of that page. Or the authors of each. Where is…
We will be providing these, yes - we want to minimise the amount of work embedding applications have to do in setting themselves up to render blocks, as well as making it easier for block authors to write them.
At the moment, yes - we want to figure out the principles of application/block interaction in a web context first, and then move on to other environments. The principles should be transferable, although some of the 'how…
We had some teething issues earlier, apologies - if you try again now it should work.
This is correct: it's the standardization of the interface between blocks and things using them, which includes structure in the data being passed back and forth, and the structure of the interface itself (e.g. what…
We have a lot of work to go on implementation detail, but this hopefully helps: https://blockprotocol.org/spec/implementation-approaches#web...
We want to fit into the existing semantic web tech rather than reinvent it - there's a FAQ here which hopefully helps to clarify: https://blockprotocol.org/docs/faq
For the case of a football website, you could have blocks which display or edit data which doesn't need to be tied to football specifically, but can be used to build/display the football website, e.g. (I'm just going to…
I appreciate that you can use whatever JS you want when constructing custom elements. To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out…
> iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like…
The idea is more that you build your website out of blocks which allow the display or editing of defined data structures - so you search for blocks which are compatible with the data you want to work with (which can be…
We're focusing on the browser context at first, but expect the principles of the interface between a block and application (if not the implementation details) should be applicable to other environments - very briefly…
1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it…
Thank you! If you have any learning from your own work you'd care to share, or thoughts on ours, please drop by the repo (https://github.com/blockprotocol/blockprotocol) or Discord (https://blockprotocol.org/discord)
> If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page. As it stands we're reluctant to dictate the internal…
> Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business). 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…
The parties to the protocol (in this early form, with a web focus) are: 1) an application which is generating a web page, and 2) a block of functionality which is part of that page. Or the authors of each. Where is…
We will be providing these, yes - we want to minimise the amount of work embedding applications have to do in setting themselves up to render blocks, as well as making it easier for block authors to write them.
At the moment, yes - we want to figure out the principles of application/block interaction in a web context first, and then move on to other environments. The principles should be transferable, although some of the 'how…
We had some teething issues earlier, apologies - if you try again now it should work.
This is correct: it's the standardization of the interface between blocks and things using them, which includes structure in the data being passed back and forth, and the structure of the interface itself (e.g. what…
We have a lot of work to go on implementation detail, but this hopefully helps: https://blockprotocol.org/spec/implementation-approaches#web...
We want to fit into the existing semantic web tech rather than reinvent it - there's a FAQ here which hopefully helps to clarify: https://blockprotocol.org/docs/faq