ciaranmn

6 ms·

1.
by ciaranmn 5y ago
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 say &
2.
by ciaranmn 5y ago
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 specifying
3.
by ciaranmn 5y ago
> 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 securely forwarding
4.
by ciaranmn 5y ago
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 done programmatically
5.
by ciaranmn 5y ago
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 mentioned here ht
6.
by ciaranmn 5y ago
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 on the to-do li
7.
by ciaranmn 5y ago
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://blockprotoco
8.
by ciaranmn 5y ago
> 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 implemen
9.
by ciaranmn 5y ago
> 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 we&#
10.
by ciaranmn 5y ago
> 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 implem
11.
by ciaranmn 5y ago
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 state?: blocks can have t
12.
by ciaranmn 5y ago
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.
13.
by ciaranmn 5y ago
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 are they i
14.
by ciaranmn 5y ago
We had some teething issues earlier, apologies - if you try again now it should work.
15.
by ciaranmn 5y ago
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 operations are avai
16.
by ciaranmn 5y ago
We have a lot of work to go on implementation detail, but this hopefully helps: https://blockprotocol.org/spec/implementation-approaches#web...
17.
by ciaranmn 5y ago
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