-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate commands for each heading #2435
Comments
That's possible now – just create your own buttons for this single command which we have now and bind them accordingly. Not a problem at all. If we split the command into multiple ones, then the implementation of this feature will become more complicated, because it's now creating a single drop down, which label would need to be inherited from multiple commands' state. So the current implementation is just simpler. If that was the entire picture, I'd say we shouldn't touch it. Either creating your separate buttons is a bit more complicated or creating a doprdown is a bit more complicated. The feature should not implement both at the same time and the only option would be to have two features. However, we've been talking about simple buttons -> dropdown transformation, based on a simple toolbar config. This means that we'll need utils which allow you to convert separate commands (or rather buttons, if that's to be a UI-oriented feature) into a dropdown anyway, hence, it makes more senses to split the heading command. The problem is that we don't have the toolbar configuration designed yet, so it's a bit risky that we'd have to work on this twice. So before we start, I'd like to see some design (aka feasibility study) for that. |
Setting buttons to be active or not is not a problem, but if we would like to disable a single heading level it's not doable right now. Such feature might be useful to implement #2426 or maybe even #2418. But I agree that it's not essential for the heading feature (to be honest I'm not sure if we need something like #2426).
I believe such feature should be provided as a part of this package because it's very common scenario and it's very simple code. I can even image the editor which has both: big top toolbar with a dropdown and a small contextual toolbar with buttons. |
Feature: Split "heading" command into independent commands. Closes #53. Closes #56. Closes #52. BREAKING CHANGE: The "heading" command is no longer available. Replaced by "heading1", "heading2", "heading3" and "paragraph". BREAKING CHANGE: `Heading` plugin requires `Paragraph` to work properly (`ParagraphCommand` registered as "paragraph" in `editor.commands`). BREAKING CHANGE: `config.heading.options` format has changed. The valid `HeadingOption` syntax is now `{ modelElement: 'heading1', viewElement: 'h1', title: 'Heading 1' }`.
It's more and more popular to have separate buttons for headers:
Slack post editor:
medium.com:
paper.dropbox.com:
It made me think about another way of implementing headers. Consider this:
Each header (P, H1, H2) have it's own command, which can be active or not or can enabled or disabled.
Each header provides the dropdown item connected to that command. It could also provide, ready to use, buttons added to
componentFactory
.Then, on top of it, the dropdown can combine these commands/items: it is enabled if any command is enabled and display the active option. Note that such dropdown menu could be used for any collection of commands in the future.
What we get is flexibility. The developer decides how the toolbar will look like: if he wants to have separated icons, he can. If he wants to group some options in the dropdown, he can as well.
Also, it will be possible to disable a single header level, what is needed for https://github.com/ckeditor/ckeditor5-heading/issues/39.
The text was updated successfully, but these errors were encountered: