Good morning.

My name is Ella.

I would like to talk to you about publishing on the web.

Imagine publishing on the web, right, when the web was born.

A web page would look something like this.

You could you would have a title, some links, a side bar with functionality, breadcrumbs,

but you would have to rewrite this all the time.

All of this would you like to put on every page and write it all the time.

What if you liked to change something on every page of the site?

This is why we have content management systems, right?

Thanks.

So a web page would look something like this: titles, links, side bar, a search functionality,

and all of this you would like to have on every page.

And it's quite easy to rewrite it all the time.

This is why we have content management systems, right?

They simplify web publishing quite a lot.

So, title of, breadcrumbs, they are generated for you.

When WordPress was born 16 years ago, out of this satire to simplify publishing on the

web, they also had a function called ... because I tried to rewrite every single paragraph

deck in this content, but I just - sorry.

So, I would automatic ly wrap every line of text separated by two line breaks with paragraph

text.

This was before any visual editors exist odd the web.

It was even before markdown was born.

And I see this a bit as the first step towards visual editing.

So this simplified web publishing a little bit, but you would still have to write other

HTML, like links, images, auto formatting.

So it is not easy to read this text, and it still looks a bit like code.

A year later, style MC was born and WordPress including it into the CMS, and it would look

like this.

Everything was well, at least for a while.

So how did this visual editor work?

It used the browser API calls.

It is really cool.

You can just add attributes to any HTML deck and it would make everything editable inside

it.

You could put it on the body elements and your whole page becomes editable.

You can literally put anything inside it.

It's really magic.

But the API had no specification, and it was later taken over by other browsers.

Every browser implemented it differently, so everyone had their own opinions about how

it should work.

Should enter create a line break or a paragraph tag?

A gif tag?

Should it depend on the context string?

Should backspace delete a second image or delete an entire figure deck?

What should happen with the caption?

What happens if you press the ...? Should it insert inline styles, create a B tag or

strong tag?

Any visual representation of your content has an infinite all the of DOM forms, so there

will be invisible spin tags, invisible characters, like non-breaking spaces, method elements.

You can even split a tag into multiple pieces and you wouldn't see it.

So you literally don't see what you're doing, and this DOM content becomes your source of

truth.

So selection has the same problem.

Let me quickly show you.

So if I selected text, did I select a paragraph contents, or did I select a whole paragraph,

or did I select the entire blog post?

The visual representation is very ambiguous.

And here we have a link.

If you have an insertion point, you cannot really tell if the insertion point is inside

or outside the link.

You have no choice where to insert.

And finally, when you have non-editable areas inside editable areas, it's buggy across the

browser as well, and this is complex for more building stones.

I think we can agree that content is like black magic.

You can put anything inside it, and you don't know what will happen.

It's a bit of a black box.

And what will come out is HTML soup.

So we don't want to build an editor on to such complex foundations.

Slowly writing on the web more chaotic, and content was not the only thing to blame.

The WordPress editor also have some design problems.

Brief plugins would try to build things ... autoplugins were creating shortfalls more and more complex

things, creating for more calls and even more problems.

Some plugins would give up on the visual editor entirely and put custom boxes outside the

editor.

They would do it all differently, so different coloured buttons, different types of models.

Each more bigger and bigger to grab your attention.

So I would call it spaghetti UI.

In comes Gutenberg.

It took us quite a while to build it because we had to take all these plugins into consideration.

With Gutenberg, we wanted to create an editor from the ground up.

We wanted publishing on the web to become effortless, and we wanted to end the constant

editable mess.

We wanted to create consistency in the UI.

This was also an opportunity for WordPress to introduce JavaScript more seriously into

the community.

So how did we do this?

Everything becomes a block, so paragraphs, images, headings embed, and this might sound

a bit simple, but it's important to think about a writing experience as something fluid,

so it's not immediately obvious in terms of UI and in terms of an extension mechanism.

HTML has block-level elements and we would like this underlying structure to shine through.

So first let's have a look at how we save this content.

Even though the editor state is an object tree, a tree of blocks we don't want to save

it as JSON or short calls or custom markup, we want to save it as HTML.

Saving at HTML ensures that the data is portable.

It works everywhere.

And we don't want to the user to be locked into our system.

Also HTML is a bit of the - also, it doesn't need any logic to render the page, so if a

plugin disappears, the content will still be there.

The page can still render.

HTML is quite a pit of a lower language of the web but we need the markup to carry more

meaning.

Think about a table, for example,.

It can be used for a plain table, and a plain table block or a calendar block.

So we decided to use HTML comments to describe and to separate these blocks.

They are syntactically very different from HTML, so our blog parser doesn't need to know

HTML.

And our side of this block added to context, these comments will just disappear.

It also makes it possible to have - here is an example of a block.

It makes it possible to create dynamic blocks, so blocks that rely on external data to render,

like advertisement, or photo album.

WordPress really values backwards compatibility, and we want to respect existing content.

So content outside of these blocks delimiters are put in a fall back block, and a fallback

block is the old editor inside the block.

If you do not wish to use the new editor, or you just want to keep on writing in HTML,

it's possible.

You can just use this one block.

This shows how robust the block system is.

Each block is an isolated container.

The block parser can recover from any invalid HTML because it doesn't need to parse it.

HTML parsing errors are added on the block level.

The theme for JavaScript errors, so we use React error boundaries to catch the errors,

and to display them inside the blocks, so, if any plugin creates an error, it's no problem

for the entire editor.

And finally, since we don't use the entire block lift, we don't have to worry about the

browser messing the markup up.

So now, some new things about the editor.

We have placeholders, be so, if you're writing a text, you can just insert the image placeholder

and keep on writing and fill in the blanks later.

Also, together, these placeholders can form templates, so, if a user doesn't really know

how to create the more complex layout, they can rely on templates created by themes or

plugins to insert on, and then fill in the blanks.

For example, here, that's from Amnesty International.

If you would like to reuse a piece of content, you can make a block reusable and use it on

every other page.

So any update to this block will reflect on all the other pages.

So, in the background, this is actually a dynamic block.

So, the editor is quite simple to extend people have created drawing blocks, form blogs.

You can even put a editor inside the editor, and here you can see it's a blog that someone

created in 17 lines of JavaScript.

Finally, it is much easier to discover features.

Before people would know how to paste a YouTube URL, that pasting would embed the video.

Now this is part of the block list, so it is easier to discover and also searchable.

In the future, we would like to have a plugin directory, and so if you search for a block

and it's not installed locally, you will get some suggestions to install plugins, and you

can install it right in the editor.

This is to eliminate some end-user experience.

Now what about rich text?

We still want to write inside these blocks, right?

So quickly to kick-start development, we put tiny MC inside components side React but we

knew that eventually we wanted something lighter and something more integrated.

So, because we had, like, React UI and it needs to handle things like paste and block-level

interactions, on top of that, we also wanted some custom features, for example, format

boundaries, so here you can see that you have a link, and with a left and right arrow keys,

you can navigate inside and outside of a link.

This makes it easier if you want to search on the inside or the outside, and you can

try this on the other editor.

It's not really possible.

So, we decided to build our own rich text component, and guess what you use for that?.

It gives you a lot of stuff for free.

It just works in other languages like Arabic, Japanese out of the box.

It's accessible, it resizes, and native UI just works.

For example, if you shake your phone to undo what you've written, or if you want to use

the formatting button on a touch bar of a Mac book.

So it is quite good at text-level editing, just not at anything else.

So, our components - so, in our components, we want to control the state, and we separated

text and format.

This makes it much easier to manipulate the data instead of having a three or four formatting

- a tree of formatting elements.

You have the string methods that you can use, and you have some extra formatting really

that functions.

So how does this work?

For example, if you have an editor, you have a universal keys like enter, delete, arrows

keys, so we create a new object from the previous old objects with the helper functions, and

then update it with the algorithm, pretty much like React works, but for inputs, we

have to look at the DOM, create an object, take the concern out of there that we need

and update the DOM and if the browser does anything strange in there.

Checks components are also extensible so it is possible to run transformations through

on input.

Here, if you type ... it can transform to a port tech.

It is possible to add custom formats, things like autocomplete, annotations.

You can even do checking like analysis, or spell checking.

It is easy to implement.

The blocks are tied together, the rechecks are tied together.

This is to ensure a good writing flow.

If you want to split the blocks, you can use enter, you can use lead, because it should

not feel too blocky, right?

The differences is that these block interactions are done by us, not by the browser.

To this editor rebuild is super versatile.

You can use it for documentation.

Even people who get the editor - like Drupal, and I've made this whole slide show in Gutenberg

as well.

I will quickly show you and exit the page.

So here you can see that every slide is a block, and there are blocks not entitled slide,

so adding paragraphs, how you can also add things like images.

Upload an image.

You can resize it.

You can move it.

You can easily move around.

You don't have to copy and paste.

And you can also, we have some rich text and extensions work, for example.

If I want to make something appear on the next key stroke for my slides, I can create

the slide fragments.

Then go back to the presentation.

So you can make slides with it, and we're actually also using this editor now to edit

the full site.

So editing themes is actually how I got involved, how I got involved into WordPress and how