20、 Obama
B1 中級 1 タグ追加 保存
このエントリーをはてなブックマークに追加
動画の字幕をクリックしてすぐ単語の意味を調べられます！
単語帳読み込み中…
字幕の修正報告
Thank you.
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
I learned PHP and JavaScript.
But not everyone has the time or the patience, or interest to do that, right?
This is a very simplified but a themed template, a WordPress template would look something
like this.
You have some PHP and HTML detection.
But why not let the user directly manipulate those blocks with a graphic user interface?
Why not let the user add it to the whole site?
Why should it be reserved for people who know HTML or for people who want to port?
This gives more power if the to the user, and the theme is reduced to a style sheet.
In fact, it gets rid of PHP entirely for the templates.
So there is a reason we call it Gutenberg, and the Gutenberg's printing press changed
how book-publishing works, we are hoping that this editor changes how web publishing works.
We want publishing on the web to become accessible to everyone.
We want you to be able to break out the walled garden of the internet.
We want you to be able to publish on your own server and to only your data, and I hope
this project can help centralise that again.
WordPress is also translated into over 100 languages, and you can add your own.
It has 38 million active installs, and these 38 million active installs are separate servers,
so they're not owned by one company.
If you have questions, I will be around later, and I'm on Twitter.
If you're interested in all these things, feel free to apply and work with us.
Yes, thanks for coming, and thanks JSConf for having me.
[Applause].
コツ：単語をクリックしてすぐ意味を調べられます！

読み込み中…

B1 中級

Designing a Rich Content Editor for a Third of the Web by Ella van Durpe | JSConf EU 2019

1 タグ追加 保存
このエントリーをはてなブックマークに追加
林宜悉 2020 年 3 月 29 日 に公開

お気に入り

loading

コメント

読み込み中…
お勧め動画

  1. 1. クリック一つで単語を検索

    右側のスプリクトの単語をクリックするだけで即座に意味が検索できます。

  2. 2. リピート機能

    クリックするだけで同じフレーズを何回もリピート可能！

  3. 3. ショートカット

    キーボードショートカットを使うことによって勉強の効率を上げることが出来ます。

  4. 4. 字幕の表示/非表示

    日・英のボタンをクリックすることで自由に字幕のオンオフを切り替えられます。

  5. 5. 動画をブログ等でシェア

    コードを貼り付けてVoiceTubeの動画再生プレーヤーをブログ等でシェアすることが出来ます！

  6. 6. 全画面再生

    左側の矢印をクリックすることで全画面で再生できるようになります。

  1. クイズ付き動画

    リスニングクイズに挑戦！

  1. クリックしてメモを表示

  1. UrbanDictionary 俚語字典整合查詢。一般字典查詢不到你滿意的解譯，不妨使用「俚語字典」，或許會讓你有滿意的答案喔