Improve schema-related vocabulary and Schema API

[scofalik]

📝 Provide a description of the improvement

Related to: #12430.

I feel there is confusion regarding naming when it comes to schema. It's about "block" word.

We have two categories of elements, that are "blocks":

• non-object block elements, which hold inline content (mostly text), such as paragraph or heading,
• object block elements, such as image or table.

These two are totally different, they behave differently, etc. It is a problem when providing descriptions or explaining, because you always have to mention the other category or specify whether you are talking about object-block or non-object-block. Finally, some blocks break schema rules. In Schema guide it is said that blocks cannot contain blocks. But table can be inside a table. I think this rule make sense only for non-object-blocks.

It is also a problem when writing features. When it comes to Schema API, we have .isBlock() but it is not enough. We always have to use && schema.isObject( ... ) (or negation).

I don't have a good proposition for names because images or tables feel like something that can be called "block". And also, we are used to calling paragraphs "blocks". My main problem is that calling .isBlock() doesn't give me enough information. And saying that something is "block" is not enough.

Additionally, we should start thinking in behavior categories. I can identify these categories:

• container (block quote, section),
• limit-container (some custom feature? maybe templates?),
• block object (non-inline image, table), ("object"?)
• block element (paragraph, heading), ("block"?)
• inline (text, inline image).

All elements from given category should behave the same (maybe inline elements are a bit different than text when it comes to selection handling). Apart from inline objects, I think that other categories are exclusive (i.e. you can't have something that is container and block at the same time, etc.).

A lot of time we wonder how an element should behave regarding things like: enter key, selection handling, auto-paragraphing, automatic schema-checks, insertContent(), track changes feature, revision history feature. This gets complicated with features like GHS or with custom elements introduced in 3rd party features. This is why I'd like to focus on these five categories and assume that any model element will always fit into one of these (unless a new category emerges).