> 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 content sizes (for auto-resizing the frame), events, and styling information across the frame boundary.
That is one approach - what we've experimented with is having applications load their own thin 'block handler' code in an iframe, which then renders the block and does the message passing with the parent window. This way blocks don't have to know whether they're framed or not, and applications can choose not to frame blocks, e.g. because they're all trusted and they don't want the additional overhead.
As David says, very interested in any and all thoughts on this subject, as it's important to get right. Like many aspects of the spec, the thinness of the current material is more a reflection of the early stage of the project than a view that it is unimportant / doesn't need further work.
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), and swap them around depending on what the user wants to do (display x, edit y).
The goal is that blocks can be dropped into applications to provide the functionality to display x or edit y, without requiring configuration, because the operations they will use to work with data, and the ways in which constraints/valid data are described, are common across all blocks and supporting applications.
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 'display' but assume these can all 'edit' the same data):
- an 'Organization' block that displays an org name, logo, HQ location, etc (for displaying info on teams)
- a 'Table' block that takes any dataset and can allow you to sort, filter, the data in it (for displaying stats)
- an 'EventCalendar' block that takes a list of fixture dates and details, maybe allows you to view it as a list or on a calendar
these blocks wouldn't care that you were using them for football specifically - just that you were providing them data in the structure they can work with. We're not claiming that these generic blocks would do everything you wanted - but they'd get you a lot of the way there.
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 https://blockprotocol.org/docs/faq#what-about-non-web-contex...
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 list?
It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API when actually loading a block).
2) What's going on with the type signatures here?
The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.
The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.
> 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'd be delighted with a big improvement in component standardisation/typing, and for now we're focusing on building on existing ways of representing semantic information in order to achieve that. I agree that there's a lot of scope beyond that for improvements.
> How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
We may be indulging in cake-and-eat-it-ism, but we think the Block Protocol can allow for both.
The proposal is for the structure of entities to be represented in JSON Schema. As JSON Schema is just a set of constraints, you can take a blob of data and calculate 'does this data meet this set of constraints' (i.e. structural/duck typing). So if a Block has a schema which says that it requires a single field 'age: number', it doesn't matter what class the data you have belongs to, you can throw it into the block if it has that field. We have an API that will accept data objects and respond with blocks which have a schema the data is consistent with (not necessarily matches).
This doesn't preclude limiting certain operations/blocks to _only_ data which is linked/belongs to a specific schema/type (i.e. nominal typing), rather than simply satisfying its constraints. And there are circumstances in which not dealing with additional fields that a type might have is an issue, although for presentational or editing blocks that don't claim to be a 1:1 map onto a specific type, I think it's fine and useful for them to be able to present/edit a subset of fields from various types.
> 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 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 their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application (the standardisation of what these operations are and what they do is a key part of the spec).
Where is the UI code?: I might've misunderstood this question, but - a block should have a package which contains code for rendering its UI and dealing with data to/from the application embedding it. The application can then either pull that code at runtime (e.g. from a CDN) when a user requests to use a certain block, or include it as a library and ship it with the application.
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 are they implemented' won't be (https://blockprotocol.org/docs/faq#what-about-non-web-contex...)
The comment above you is right that 'handling blocks implemented in different ways' (in a web context) is one of the mushier parts of the spec, and it's something we need to do more prototyping and refinement of.
That is one approach - what we've experimented with is having applications load their own thin 'block handler' code in an iframe, which then renders the block and does the message passing with the parent window. This way blocks don't have to know whether they're framed or not, and applications can choose not to frame blocks, e.g. because they're all trusted and they don't want the additional overhead.
As David says, very interested in any and all thoughts on this subject, as it's important to get right. Like many aspects of the spec, the thinness of the current material is more a reflection of the early stage of the project than a view that it is unimportant / doesn't need further work.