Show allowed heading options only

[fredck]

We have implemented the heading feature just like anyone else out there. We just show a dumb list of options and let the user select any of them. We need more awesomeness in this feature.

I would propose showing in the list just the options that the user can use, based on the context:

• If no headers were user before the current block: Heading 1
• Heading 1 used before: Heading 1, Heading 2
• Heading 2 used before: Heading 1, Heading 2, Heading 3
• Heading 3 used before: Heading 1, Heading 2, Heading 3, Heading 4
• ... and so on

In other words, we just list the previews levels plus the next level. In this way we help users creating better content by not even allowing them creating improper heading nesting.

Additionally, we could provide some visual clue, like an icon for every option in the list. For example:

• H··, H·: Previous levels
• H: Current level
• ·H: Next level
• ¶: Paragraph

[Reinmar]

Interesting ideas. There's some danger in limiting the user to the "perfect usage" scenario, tough. First of all, you'll always be able to create a heading in one place and move it to the other place. Second, you might've just written a long piece of text and you want to start formatting it. First, you find subsections and add H2 to them, then the main title... but you won't be able to do that now. You'll have to first set H1 and only then you'll be able to set H2s.

So, this could be a quite frustrating feature. I'm really unsure whether it makes sense.

[fredck]

First of all, you'll always be able to create a heading in one place and move it to the other place.

Yes, we'll not be able to guarantee that the user will not mess things up. We can just help.

Second, you might've just written a long piece of text and you want to start formatting it. First, you find subsections and add H2 to them, then the main title... but you won't be able to do that now. You'll have to first set H1 and only then you'll be able to set H2s.

Kind of a weird way of thinking, so I would not make it a common case. Anyway, it may happen and it may cause frustration in such situation.

Another idea could be so using the visual clues only then. We could still list all heading options, but use the icons to let the user know what options fit best. We can then show ⚠ in the options that don't fit in the current document structure.

[Reinmar]

Kind of a weird way of thinking, so I would not make it a common case.

Well, that's how I'm writing articles very often. I don't see anything weird in that :|.

[fredck]

Maybe I see the case now... you say that "Title" is a heading, which in the CKEditor common use cases is not true. In those cases the title is a separate thing.

[Reinmar]

Yep, wrong wording. I meant a higher level heading than what I've just set.

But, in fact, it may be common that you'd like to have a post title directly in the editor. This happens if you're editing the whole document in the editor (like in Google Docs). For such cases, <h1> should be the first block which you can create in the editor, but you shouldn't be able to create more <h1> later on, so you'd have a special rule for that I guess.

Anyway, my point is that when creating limits we may, by mistake, block some valid use cases. So I like the idea with some indicators of recommended headings more :).

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).