Implement block indentation feature

[Reinmar]

Is this a bug report or feature request? (choose one)

🆕 Feature request

📃 Other details that might be useful

A popular feature of CKEditor 4 that we still don't have in CKEditor 5 is Indent Block.

This feature applies margin-left/right (depending on the content language) or a class (like indent-1/2/3) to the current block (e.g. a <p>).

It exposes indent/outdent buttons. It does not block the Tab key which people need to be able to leave the editor. However, it could use different keystrokes to allow indenting/outdenting the current block.

One more important aspect is that the indent/outdent buttons allow indenting/outdenting list items too. This is a bit tricky architecturally because the list feature is completely independent from this feature. This could be done by the list feature checking if there are indentBlock/outdentBlock commands and overriding their behaviour when the selection is in a list item.

Related features

There are two slightly similar feature requests, but which actually describe different features:

• Enable tab key in the editor
• Text-indent style

[jodator]

One more important aspect is that the indent/outdent buttons allow indenting/outdenting list items too. This is a bit tricky architecturally because the list feature is completely independent from this feature. This could be done by the list feature checking if there are indentBlock/outdentBlock commands and overriding their behaviour when the selection is in a list item.

I've been thinking about this part a bit and I've came to a conclusion that new API would be nice here but nothing more then building blocks ATM as I don't see scenarios for general API.

By building blocks I mean is to define a multi command that could aggregate many commands in order to expose single point for buttons.

The idea is to rename indentList and outdentList to indent and outdent (or add an alias for them).
Make them interact with indent command (the enabled state & execute).

The building blocks would be as follows:

const indentListCommand = new IndentListCommand();
editor.commands.add( 'indentList', indentListCommand );

const indentCommand = editor.commands.get( 'indent' );

indentCommand.registerChildCommand( indentListCommand );

Similarly the indentBlock command would be added to the 'indent' command.

The idea was that indent/outdent commands would be added by the core and either list or indent block feature could add their commands to that general one.

The MultiCommand would just glue them together so there would be only one button in the toolbar.

• it will be enabled if any of commands is enabled
• it will execute first command that is enabled
• basically the two commands should not be enabled for the same selection

The small addition to this could be an API that would allow adding commands to some alias:

// list feature
editor.commands.add( 'indentList', new IndentListCommand() );
editor.commands.addMulti( 'indent', 'indentList' );

// block indent feature
editor.commands.add( 'indentBlock', new IndentBlockCommand() );
editor.commands.addMulti( 'indent', 'indentBlock' );

The creation of MultiCommand would be done by commands collection.

---

The other idea that came to my mind is aggregating commands in buttons itself but I don't have an idea for that API and from what I've seen that I features are defined as factories and you can have multiple instances of them in toolbar(s). So the multi command API looks like better suited for this case.

---

As @msamsel pointed out similar feature might be background color that will aggragate fontBackgroundColor and non-yet existing (if ever) tableCellBackgroundColor command.

// cc @pjasiun

[jodator]

The POC in action:

[pjasiun]

I am not sure that we need "building blocks", at the moment. List + indent block looks, for more like an exception than a common pattern. I do not think we should do it for background color/table cell background too, notice that for MS Word these are separate features:

This is why, I think, it should be a simple "if" in the block indent plugin which checks if the selection is in the list and if the list plugin as enabled, or the other way: list plugin can overwrite indent command execution, as @Reinmar suggested. Fortunately, the execute method of command is decodable.

I do not think we need any new mechanism here.

[jodator]

The table background was just an example so let's focus only on indent here.

This is why, I think, it should be a simple "if" in the block indent plugin which checks if the selection is in the list and if the list plugin as enabled, or the other way: list plugin can overwrite indent command execution, as @Reinmar suggested. Fortunately, the execute method of command is decodable.

We do need 3 plugins/features for it to do so as any of combination is valid IMO:

• indent button with indent list & indent block
• indent button with indent list only (no indent block plugin)
• indent button with indent block only (no indent list - ie no lists at all)

So it would have to be

• indent (probably in core or as a separate plugin for creating buttons and base commands)
• indent list that overrides indent commands
• indent block that overrides indent commands

I think that indent list and intend block doesn't have to know about each other why tie them?

So the simple if in any of list/block command is artificial and would require all plugins to be loaded in order to use one feature.

Also overriding other commands executions doesn't seems clean to me in this case. I can see that overriding default behavior of "enter" key in lists is valid but in here I don't think so.

[Reinmar]

I've been thinking about this too and I like the idea about MultiCommand. This is a nice implementation of the composite pattern and actually quite classic. So that looks fine.

My biggest problem was where to place the base indent stuff. I proposed ckeditor5-core because:

• there's PendingActions already there,
• in ckeditor5-ui we also include some base plugins.

But after talking with @oleq I think I'm changing my mind. All the plugins mentioned above are just utils and Indent will not be a util but an end-user feature (but without any default behaviour). So, I'd say that moving it to ckeditor5-indent despite the fact that it will be empty is the cleanest solution. And it's proven by CKEditor 4 already too.

[Reinmar]

So, I'd say that moving it to ckeditor5-indent despite the fact that it will be empty is the cleanest solution. And it's proven by CKEditor 4 already too.

In addition to the above – do we really need ckeditor5-indent and ckeditor5-block-indent? That'd be cleaner, but for convenience, we could merge both into ckeditor5-indent.

WDYT?

[oleq]

I'm for keeping

• the generic code,
• the block-indent,

in the same place (ckeditor5-indent). Sounds like a good place to aggregate indent features.

TBH, if possible, I'd go further and expose the minimal API in ckeditor5-list and move the indent list logic to ckeditor5-indent too. Not sure if that's possible, though.

[jodator]

So we could just rename the ckeditor5-block-indent repository to ckeditor5-indent and proceed with other changes?

[Reinmar]

So we could just rename the ckeditor5-block-indent repository to ckeditor5-indent and proceed with other changes?

If "other changes" mean moving there the code from ckeditor5-core, then yes :D

[Reinmar]

The first implementation landed in: http://github.com/ckeditor/ckeditor5-indent 🎉

[mlewand]

This feature was recently merged to the master branch 🎉

To enable it add the ckeditor5-indent plugin to your build.

Sample screencast: