 Thank you Leslie. Hello everyone, thanks for being here. Hope you're having a good and gentle work out so far. My talk is about this title Beyond Gutenberg, and I want to go over a bit how the past year has been for the project and also dive a bit into some of the philosophical reasons for how some of the decisions behind how Gutenberg works came about. And in case you haven't become familiar yet with Gutenberg, we have this page in the workers.org website. So first quickly, it was literally a year when we released the first version of the plug-in at Workham Paris last year, and since then we've done 30 releases. We've had more than 200 contributors, and there's been like over 3,000 code merges. So one of the main challenges for approaching Gutenberg and how we could... So the goal was, how can we bring a block-based editing experience to a really significant portion of the web without fragmenting the sort of the fabric of the content that like workers is producing a lot of content for the web, and it was both a responsibility for us as a project to honour that longevity of content and be able to introduce this new notion of how a better experience for editing content could be without losing sight of that responsibility. So I made a post I think last year that was titled Referring to the Paradox of Theseus, which says it's mainly about how an object can be transformed entirely piece by piece and whether the end result is the same object because you don't entirely notice the changes. And this was mainly target towards how we structure Gutenberg content. And one of our principles from the very start has been to optimise as much as possible for the user and to not let data own the content that the user has. What that means is we have to be very conscious that we are building software that has already lasted 15 years and it's going to last many more years in the future hopefully and we have to be very careful about preserving both not locking user scene into a platform and letting them take that content out if they need to. So that's one of the reasons why we took a lot of time to figure out a way to introduce blocks under the same content management system that WordPress has without breaking that. The other thing is that we really needed an incremental development pace. Again, we introduced the first version a year ago. Since then at any point you could install the plugin and if it wasn't ready for you yet you could uninstall it and continue on. In that process we couldn't afford locking the content that you produce while using the plugin. The content should not be a prisoner to these tools. The other thing is a bit more fundamental. WordPress has stood out for the semantic web since it's very inception and that's something that Gutenberg needs to continue and carry forward. The way we have approached how block editing should work is that block editing is a concern of when you're manipulating the content but it's not a concern when the content is output. We're very attached to HTML as the output and as the source. What that means is that what the visitor is going to experience in a way that's what matters the most and we need to figure out how to build tools that can allow you to produce these pages without forcing you to have a very specific data structure for powering them. This also has a connection with the Gutenberg name itself. If you imagine what a printing press produces like the final page you can't recreate the state that was before the page was produced. That is like all the metal types from the page itself but what is preserved through time is the actual page. That's what people are going to interact with. That's what users are going to value the most. What we set out to do was to figure out a way to have the page as the privilege entity that you're dealing with and then figure out a way how to extract and how to infer and how to lift a more meaningful editing experience from it for the author of that page. Imagine if when you print a page you could have invisible marks that tells the machine how to set up the printing press itself to have the metal types rebuilt. That's what these HTML comments came about. They are really invisible markers that tell us that informs us what's the content there for an editing purpose like HTML has its own semantics for consumption. This is marking that content in a way that we can tell very quickly which kind of blog we are dealing with. This is important because we can have blogs that have exactly the same markup but they have different UIs or they should have different UIs in the editing experience. An example could be an image, could have a figure with an image tag and we could have a blog that's about movie posters. It's very specific about just searching the movie database for movie posters but the output is exactly the same. We want to be able to deploy a different editing interface for the movie poster even if the markup is the same. That's one of the main reasons tied to the fact that we want to make this a transparent and gradual adoption for why this came about. The other thing that I wanted to touch on was that the notion of a blog for us is the blog appears when you need to manipulate the content but then it sort of fades away. This is what this nice illustration tries to show is that you have the final page, you can lift up this blog, you can manipulate it in the editing context and then it goes back into the final output that the page produces. In a way, blogs for WordPress are like a slightly higher order HTML. Sometimes, and to not confuse, HTML has its inherent semantics. We're just using an native HTML tool which is the content to sort of declare something that's valuable for us as an editing platform. Another thing about blogs is that on the front end we're actually not rendering the comments at this moment. They are completely invisible in terms of affecting the final output. Another advantage of them is something that travels short codes for a very long time was that if you were in a context where the short code couldn't be interpreted by WordPress, an email client or an RSS reader, you often ended up with just the text representation of the short code which is often a very bad experience. In this case, by the token markers being native to the language of the web, we can make sure that that doesn't leak into the user experience. The other thing is that a blog is a tool we use to manipulate the content but how it stores the data is less relevant to the blog itself. That means that there could be multiple ways in which a blog saves data. In Tami's presentation before, I think there was a question about if blogs could save to meta. That's already possible now. You can build a blog that's actually displaying the page among all the other blogs but the source of the data is in meta attributes. This is very flexible for the developer but it also puts a responsibility when you're figuring out how you should structure a blog, you should think about the user experience first and what's the best way to deal with the user data and what's the best way to fade away? That means what would happen if my plugin disappears? What would happen if the user wants to move away from WordPress and they want to just copy the entire content of their post? Would they have the integrity of their data when they want to do that? There's a responsibility on us all to think about these problems because they are also the sign problems because they deal with the user data. The other thing is that we've talked many times about blogs being static and dynamic. Static blogs are most of the basic formatting blogs we have in Gutenberg and that everyone is used to even from the previous editor. That is text images, quotes, galleries, all of the basic elements. Dynamic blogs are those that need the server to process data before it can be displayed. Probably the clearest example in Gutenberg is the latest post. The latest post blog needs to go and fetch the latest post from the database before being displayed so it can save that as HTML because that's going to get outdated fairly quickly. But there's not a hard distinction between static and dynamic blogs. A static blog can be turned into a dynamic blog just by registering a render callback on the server and you can do that now for any blog that Core comes with. The same way a dynamic blog could have a static fallback. For example, the latest post or the latest categories or latest post from a category, you could define, yes, this is a dynamic blog. I can't save the latest results because they are going to change. But I can actually save a URL to the permalink for the category and that can be the fallback. So if for whatever reason WordPress is not available to process this information, this is still valuable semantic data that the user that can be shown in an email client or an RSS reader. So it's important of thinking not of static and dynamic blogs as two separate entities, but more of a continuum around the user experience. This also relates to the notion of direct content manipulation which has been one of the main topics around Gutenberg. And that is because it's not so much about how the data is stored. We have a lot of flexibility and a lot of options there. But to the user, those options should be as transparent as possible. That means that they should be able to directly interact with the data even if that is being saved. If we have a site title block, of course the site title is going to be saved in the settings options. But the user should be able to manipulate it directly as any other block. So we shouldn't be tying where the data is stored with how the content manipulation happens. I want to do a quick demo if it works. So in the last work in the US we did a quick putting up what Gutenberg was capable at that time. And since then one of the main things that we have added is the columns block. The columns block allows you to have any other block within. So in this case I have two columns with an image that's floated. I can change this. I have a video within the other column. You can do things like drag elements around. Let me grab. You can drag in and outside of the columns. So the column blocks is where we have labeled it as experimental because we have been focusing very hard on the infrastructure around columns. That is allowing any block author to specify what we call inner blocks areas. So that allows you to define any block, define an area where other blocks can live. And that all integrates with this system. So the user will be able to drag and drop things inside your block, reorder inside the column, moving up and down. And we are consuming that API for columns but it's exactly the same API for everyone. The biggest problem with the columns block now is that it's a flat markup structure. So the front-end handling is not super easy or super convenient. So we're going to be iterating on how columns are presented and having wrappers around the columns. By using another tool that we have at our disposal now which are child blocks. And child blocks, what they do is they create a relationship between a parent block and these children. So let me show, see if I can do something quickly. So if I say I'm going to, I created a to-do block and I'm going to... So this is part of the block API and you just define something like parent. I am going to assign this block as a child of the columns block. So now this, this produces a few changes. First it makes the columns block now has this sort of visual representation that there's like a stack of blocks here. So when I add the columns block and I'm within the columns block, this other child block that I register appears only within this context. So I can only add this task item when I'm inside this columns block. And this is, this also to, I think another question was how do we scale the block inserter when we have, I don't know, 20 plugins registering blocks. One way is to have this sort of relationships because you can, you don't have to expose all the blocks in the root folder because some of these blocks are only relevant when they are within other blocks. And this would be useful for, if you have a contact form block, for example. It would be useful to actually have each field as a block because then the user can reorder them. You can have the, I don't know, the contact button or the send button as a separate block. And all of this, like you inherit, like even with this to-do block, like each to-do is its own block. And what that allows you to do is that you get, for free, you get a lot of these interactions that Gutenberg offers, like dragging and drop to reorder the items or even like selecting multiple items at once and reorder them. But the problem was that if you register a field, like an email title, email subject, message content, all the separate blocks, they would just crowd the insertor with all of these mess. So the child block API is meant to sort of give some organization to that. Child blocks and nested blocks also relate to templates. Now you can define templates. The thing we have always shown was for a custom post type. But now nested blocks can be nested within templates. So you can have a, like you can already set up, I'm not sure if I'm using it here. Yes. So here it's, I have defined a column for my template and within the column, these other elements, like you can imagine a full side layout being built through a template and nested blocks because it only takes, it's just a list and we define which blocks belong where. So templates, nested blocks and child blocks, all of these elements were originally planned to be part of the phase two. But we realized that block authors really needed this kind of flexibility to scale and it was a good investment to get the infrastructure right. Even if we have a lot of work to do on our actual use of those blocks, like columns needs a lot of work, but the infrastructure is there and it's very robust and you can already use it for your own blocks. So another thing that we have added is the, the pasting that Matt mentioned. This is, there's been some, a lot of conversations around pasting and what should be the ideal experience. What we want to do is to always try to infer from what is being pasted what's the right block that you should be creating. In this case, if you can write a full post in Markdown and we're going to transform this to all the relevant blocks. Pasting also cleans up the markup source so you don't end up with all these pans and all these elements. At the same time, if you do want to preserve that, you have the ability to create an HTML block and past it into that. So one other thing I wanted to touch on is creating blocks is, well, it all happens in JavaScript. We've been saying, we've been defining all the APIs in JavaScript and it's, for new people, it's not, it might be a daunting task to sort of face all these new APIs and deal with the JavaScript ecosystem which has, in the last few years, has grown a lot in complexity. But I think it's important to realize that we have a spectrum of complexity here. And a block doesn't, a person creating a block doesn't have to be, doesn't have to fall on the higher scale of the complexity. What I mean by this is that say I'm setting up a site for a client and I want to create a simple block for them to reuse in different places. I can, I can just create an HTML block and do my lovely tag, make sure it works well. And then I can say, okay, this HTML, I want to make these that I wrote here as a block. I will use the share blocks functionality for these. And now I, and this is represented with this icon, little icon here. Now this just became a block just like any other block in the share blocks library. So you can, you can set up a client side with 20 of these for things that you want them to be inserting but maybe not edit entirely. And you want them to be reused across their posts. Like we've already created a block very quickly without touching code. So there's a spectrum between setting up a whole build system for writing a complex plugin like Yoast would have to do. All the way down to people like setting up a site for a user and wanting these reusable bits of UI. And the share blocks interface allows you to preview the blocks. So when you hover the different blocks, you can already see what's going to be the output. And I think as a community and as a group, we have to figure out what sort of solutions, how we can sort of tear these solutions so that anyone can get on board and then sort of ramp up towards more complicated use cases. Like share blocks also work with nesting so you could imagine having, I don't know, a lot of different blocks around a section block and make this whole thing reusable. And the opportunities there really scale up and you could be doing a lot of things with that. I'm going to switch back just to quickly here. We're already starting to see a lot of plugins creating blocks, which is pretty cool. And this is a plugin that adds an author block that you can. And again, the principle here should be that everything should be, you should be able to write as much as possible within the block itself. And changing the image, everything should happen within the block itself. And to the user, like another thing we added was this, a way to quickly know what the block is. Because as you imagine, once you have like a hundred blocks, that would become a useful thing to know if you need to. Like if you're editing the post, one thing we try to do is to not show the UI. So when you're writing, we sort of fade away the UI, but once you want to start interacting with the content, it's a useful representation. So we talk about nested templates, nested blocks, templates, layouts and child blocks. These are really the foundational pieces for the Phase 2, but they will be available in 5.0, so you can already start using them as APIs. We really need help testing things like columns so that we can get the experience to be as smooth as possible. And make sure the interface scales for every third party block author to use. So talking a bit more about the future, another important thing that I think it's opening up with all these API tools, is that we can now start creating sort of, they are not templates, but they are not blocks on their own. They are like these small layout units, like an image with a paragraph next to it. So it's things that you can already create by yourself, but packaging them up as these small layout units would be very useful to users so they don't have to sort of build everything through all the steps. And templates, well another thing we added this year is the ability to lock templates down. So that means you can register a template, but disable the ability for moving the blocks around within the template. So it's basically what you lay out in the page is going to remain there, the user won't be able to move it, but they will be able to interact and edit the content itself. And this applies, this can apply to this unit as well, because nested blocks, when I talk about the inner blocks area, you can define templates within those inner blocks area. So the template doesn't apply to the whole page itself, it can also apply to individual areas within blocks. And these are some mockups that Melchoice did around how we can start introducing some of these, which is for example a three columns layout that uses the primitives that Gutenberg provides, but they are just offered as sort of quick shortcuts to get some of these layouts in place. And the other thing, like the next step that we'll have to start looking at within the next few months is right now Gutenberg is focused on the post content. The post title is not even a block, it's just a text field. And we need to turn everything into a block, the post title, the post content. We need to scale out so that the sidebar, the side title, the header, the menu, all of these elements becomes blocks. And this is where we can start to get to a point where the editor can actually be a faithful representation for the front end because we'll have control and we'll know explicitly by the theme, by the layouts, by the templates how the whole page is laid out. And we already have tools that would allow you to lock certain things down. So if you're editing a post, maybe you don't care about the other places, but maybe you want to still see them, but you don't want to be able to move the title, the side title around when you're writing a post. So all of these things are going to start to be prototyped and figured out for the next phases. This is also a mock-up by Mel for how the experience of creating a new page could be looking like. And this would show when you start a new page and you'll be able to either start blank or choose from these already available templates or new templates that a plugin might register. And I think I have some time for questions now. So yeah, that's about it. Thank you. Thank you, Mattias. So we have two microphones on stands here in the aisles if you want to get up. And we do have a couple of microphones that can be run down. I see some folks getting up. Go ahead and start there. Hi. Thanks for the great presentation. I'm Villa from Finland. I have a question about the author blog you had that was made with the blogging. If you were to create a page that queries all the posts made by a certain author, what would be the approach to save the data so that it's queryable from another page? So can you explain again what would you be querying? You want to query the author from another post? I want to create a page that displays all the posts made by an author. Okay. Well, that would be similar to how the latest post works now. So we have the blog latest post and this has some like you could have like an author feel here or maybe even on the blog itself. And this is using the some tools that Gutenberg provides like around our data layer so that you can you don't have to directly query things. The idea is that you would just specify basically declare I want the post from this author and we'll orchestrate all the API requests so that is fulfilled on the client. Does that answer the question? I think so. Okay. Maybe the data is something more dynamic and customized, not something like that is like some idea of some sort. So what would be the data model on the post? Let's say you have an idea of something on the post that is rendered as let's say an author or like a product. So what would be the best way to store the ID to the post itself? So if I'm if I'm understanding correctly, let me show you the latest post here. So here you can you can specify attributes for a block that could be an ID to reference somewhere else. That's actually how shared blocks work. If you look at the source in the HTML for the shared block in the editor, it's actually just a reference ID to the post that exists in another custom post type that's hidden away from the user. So you have that like you can get any attribute into the into the comment and then process that attribute however you want within the editor. So on the post that you create the let's say a product relationship, which you store the ID to the post meta. Yes, and let me see if I can make a post meta query if I want. Yes, that I mean we support by that by default like one of the attribute sources for a block can be a meta attribute. You just need to make sure that the meta attribute is exposed through the rest API so that the meta attribute has to be registered as showing rest. If you do that, the attribute is already being retrieved for you in the editor and it just matches the attribute name. Okay, thanks. Thank you for the question. I do have a question related to metadata. I was wondering in WordPress 5, will we still be able to show meta boxes and things that rely on them like ACF plugin? Yes, you can. I think ACF already has built support for Gutenberg like meta boxes are already being shown if I go to... I don't think I have anyone register now, but if you register a meta box with a context for a site, for example, it will show up in the cyber automatically. As long as what you're doing within the meta box is something we can handle by default, that will happen like that. I mean, I think Tammy talked a little bit about our own plugin API. I have a plugin installed here that's outside of the block interface and it allows me to insert images into the post. This is where we want some of these meta boxes to eventually move towards, but the existing ones we are doing as hard as work as possible to make sure that they continue to work in the new editor. If a meta box is not supported, right now we are doing a fallback into the classic editor, so you get sort of the classic editor experience. But it's going to be, again, like there's a lot of spectrum of what we can do with what we get. If we get a meta box we can handle, we can go to classic editor. If it's a meta box that's simpler, we can handle it in Gutenberg and we'll just either add it to the cyber or below the post. And then if you want to actually work with native Gutenberg APIs, you can create these sort of things that are going to be better integrated with a UI. For example, this cyber icon, we have the notion of pin items, kind of like how Chrome does. All these plugin items are shown here in the ellipsis menu and the user will be able to either pin them if it's something that they use frequently. So it's always in the toolbar or fade them away into the menu. But meta boxes will continue to work as much as possible within the constraints we have. So yeah, if there's something that you have that's broken, please go to the GitHub repository and report the bug so we can see what we can do with it. Okay, thanks a lot. Thank you. I have two quick questions. First is about the block options. Like if you could click to the block there. This one? No, no. Yeah, there are set of options. This set is inputted through some kind of API. It is standardized way how to input or it is handled similar like in widgets. No, this is definitely a different set of APIs and I can quickly show you some of that code. So we have a set of components and in this case, what gets rendered here is we call this the block inspector and that's a component that you get access to. It's actually exposed, I think it's in WP blocks. Yeah, so it's inspector controls. It's exposed in a global WP variable that you can use when you use this, this is what we call a portal. This is if you render things within the inspector controls component is going to be magically render on the cyber, even though you're defining that in your render mechanism for your own block. The same way is that the toolbar itself works that way. So these elements here, like the different width for the image, these are specifies, what we're using is the toolbar component, which I can't find right now. It's just a component that you're using your render method and you can put all the tools inside and those are going to be rendered here. This allows us to do things like show this option here, like the fixed toolbar to top. This just moves all the block controls to the top, but it doesn't require you as a block author to change anything in your code because you're just declaring how your toolbar should appear. And this is just, again, another component that WordPress would offer and it allows you to, you can put whatever you want in a toolbar. Right now we have a set of tools that you can already consume like alignment buttons, but you can put your own buttons there to process your own block attributes. But all of these are not, it's what we call like declarative APIs. So you compose them, you basically have your block element and within that you say these are toolbar, these are block inspectors and you don't concern about where these are going to be displayed in the UI because Gutenberg will handle that. And the idea for that is that once we move into supporting the mobile apps, you don't have to change anything in your code because the mobile apps could interpret inspector controls however it fits to the mobile application. But you have already stated from a block author perspective what should be the intention for the block. Okay, and my second question is will the columns have responsive settings like for breakpoints and push, pull and overlap? It depends on how we implement the wrapper, but yes, for sure. We're considering allowing you to resize in the interface. We'll probably implement the new columns with Flexbox and then it's very simple to make it scale to mobile that way. How much, what should be the interface for doing that for the user to allow the user to configure that? That is going to be something that we have to explore, particularly for the columns block, but I can imagine different ways of approaching the allowing users to configure that. Okay, thank you very much. Thank you. Question from this side and then we'll move over to that. Hi there, so you were talking about child blocks earlier. I was just wondering if there was a way to prevent blocks from being used as a child block. If you wanted to say prevent an image being used but give the use the option to just fill in text. So the inner blocks component which is the one that defines the nested area has a property called allowed blocks. So you can specify which should be the blocks allow for that block. So that's how we're going to build the columns block. It's going to be a columns wrapper. Each individual column is going to be a child block but we're going to make that the columns wrapper only accepts columns block. So you can't add like an image before you add a column and stuff like that. So that's supported through the allowed block types in the inner blocks itself. Okay, great. Hey, this is quite technical. Is there a way for parent blocks to influence child blocks? I have a concrete use case in mind. I want to A B test and this involves having something that's essentially columns but then some dice get rolled and only one of the columns is displayed on the front end. This is bare bones. Right now as far as I understand I can't do that because I would need to have the render function of the A B block decide which of its which tree path of its children to render or not. And that seems impossible right now. Am I understanding things correctly? Let me walk through the example a little bit. So you have you want to display one or another column based on some conditions that the is the parent controlling the condition. Yeah, so I would say insert an A B testing block with the 5050 probability of displaying either this or that variant. Yeah, that seems possible to me. I mean it's you don't have to control the children for that like the children is accessible there. If you want to exclude them you can exclude the whole child tree from being rendered based on that condition on the server. If the A B test attribute is being accessed on the server you can exclude that sort of tree node for the column that you don't want to render. Okay, that's great. That answers my question. I just need to find the code now. Okay, thanks. Thanks for the talk. Also good to hear that the child blocks and columns are being worked on so much because I think I've run into every bug with those. Can you speak a bit about the roadmap for the design principles and the kind of. It's one thing that hasn't been, I haven't seen too much about is how we should be approaching the UI in an ideal world. Like when should something go into the block settings, when should something be a tool bar, that kind of thing. Yeah, so Jo and Tami have worked a lot in setting some of those guidelines. Not all of those have become super visible because there's already, I mean there's already a lot packaged into Gutenberg now. So it's like the next few steps are going to be very much focused on documentation because there's a lot you can do but not all of this is visible or as visible as it should be. In the case of the design that sort of the guiding principle has been that anything that's a primary action should go in the block itself or the block toolbar. And anything that could be considered secondary should go in the sidebar. That's a bit up to interpretation and I think we're going to be seeing what works best and what works that doesn't work that great. Once we get it in front of more users and we're going to be refining that process, I think another example would be the style variations. Style variations, you can do some of those now by just registering an attribute as a class name and offering this in the sidebar. But we're thinking of making this a first class API so you can access them more prominently. And by block styles I mentioned things like the quote here. So this has like two styles right now, you can have this small style here and this other style. This was an experiment to see how we could have alternative styles. We want to make this a first class API so you can register any alternative style for a button, gallery, whatever. And this is something that probably should live within the block itself. It's not a secondary action. So I think there's going to be a process around while we figure out what exactly should go where. I think it's important that we hear back from people building real sites for people, agencies, clients, whatever. So that we can hear what's working and what isn't working well so we can refine those principles. Thank you for the question. Just barely enough time for one final question. Hi there. I have a question regarding theme development. It seems that with all these blocks we are given a lot of possibilities to create beautiful designs. And as a theme developer I'm curious if there are going to be some guidelines or restrictions. And are there already saying if we can create blocks within themes or we can keep them in plugins. If we can create page templates or templates and stuff like that. I think the general sentiment is becoming to be that a theme should not be creating their own blocks. And a plugin should be doing that so that you can switch themes and still preserve the blocks. And the theme should be more concerned with defining templates and this nested structure using already available blocks. I think there's still some, like if you really need a specific use case, I think it's totally fine for a theme to register that block for itself. You can also consume custom blocks in templates of course. So you can sort of mix those things together. But a lot of this is going to sort of become more clear as we move into customization because they are themes. They might get away with just using the core block for a header image but maybe they want to change that slightly or have a slightly different interpretation of that. And we need to figure out if that's sort of extending our core blocks or if the theme should be supplying their own. Thank you very much. You're welcome. Let's get another round of applause for Matias. Thank you. What an exciting evolution for WordPress and constant editors.