Implement seamless link insertion and editing using just keyboard

[oleq]

A followup of https://github.com/ckeditor/ckeditor5-link/issues/2#issuecomment-240374891

When typing a sentence I want to be able to press CTRL+K at any moment, then type the address and then fill the link text (either in the editable or in the tooltip. CKEditor 4 forces (this will be fixed in 4.6 AFAIR) you to first write the text, then select it, then press the keystroke and type the URL. This must be super simple.

Also

Allow typing at the end of the link. In most editors if you type at the end, the text is inserted outside of the link. This is tricky, because there must also be a way to escape the link.

---

I see 2 possible approaches to the problem:

Type link text in editable

Once the user types the URL and confirms it by pressing Return, an empty (virtual) link is created, which text can be typed directly in editable.

Pros:

• Fastest possible way to type the link text.

Cons:

• It directly collides with link creation in collapsed selection (!!!). There's no way to have both features at the same time. Either the link feature inserts a link which href === innerHTML, or users type its innerHTML on their own.
• I see no easy way to get out of the "link text typing mode" (3) other than
  • Clicking unlink – an extra mouse action or keyboard shortcut to remember. Not very cool.
  • Breaking the line – this could not work if enter feature decides to retain the link in the new line; besides it's also a potato UX because it enforces changes in the content to control the formatting (like Return, Backspace). Rubbish.
  • Changing selection – it's a disaster when there's nothing else besides the link in the content. Plus an extra effort to do a simple task.

Anyway, it's not a very good UX if you get stuck in link text typing and switching back to regular typing is not quite obvious.

Type link text in the panel

This is what Google Docs implemented after they encountered, I'm sure, some of the problems described above.

Pros

• Solves lots of UX problems.

Cons

• Clutters the panel.
• Complicates some processes for the users and developers. Like link creation when the selection is not collapsed. In such case, the text within the selection must always be displayed in the "Txt" input in the panel and, if changed by the user, to be updated in editable after clicked "Save".
  • Now what if there's some formatting in that text already? How to transfer it to the "Txt" input? How to update it – discard it or... what?
  • What if there's an entire paragraph of text selected there? Is it OK to put 500 characters in a 200px wide text input?
  • What if the selection spans across a couple of lines? How to express it in the "Txt" input? How to preserve it after linking?

Trade–offs

In case of formatting in selected text, Google simply discards it when displaying the text in the panel and then retains it as it gets linked. If the user changed anything in the link text input in the panel, the formatting is discarded completely.

As for the multi–line selection, Google solves the problem by simply preventing user from editing text in the panel:

It's seems the only sane way of addressing the "cons" but it still requires an extra effort from developers and could be confusing for the users. OTOH, these are rather edge cases so I'm ready to accept this kind of trade–off.

WDYT?

[Reinmar]

The status of things is as follows:

If I press CTRL+L, type URL, enter. Then a link with a text==href is inserted. The link is fully selected, but I'm not able to change its text, cause that cause deleting it. Unfortunately, this makes sense... :D.

When I'm thinking about this now, I see that the only option which won't require hacking the selection requires adding a "text" input to the link dialog. And there are two options:

• The text input should only be visible when creating a link on a collapsed selection. So when editing an already created link or creating a link on a non-collapsed selection, only the URL field should be visible. Optionally, instead of hiding the text input, we can disable it.
• Showing the text input more often and handling all the tricky cases like GDocs...

If you think that the first solution is OK, then I'd go with it simply because it's simple and should be better than what we have now anyway :D.

[Reinmar]

PS. The biggest issue right now is that you cannot easily edit the whole text of a link, cause it disappears...

[fredck]

Would something like this work, when the whole link is selected?

• If I immediately start typing, the link stays and the text change to what I type.
• If I delete, the whole link is removed.

This would work when creating links on collapsed selections as well. We could select the whole link after creating it with the link URL as the initial text. The the above options would apply.

[Reinmar]

I've been thinking about this too, but it'd require hacking the typing feature a bit.

One option would be to change the behaviour of deleteContents to leave a selection with the link attrs. The typing feature uses deleteContents mechanism initially to clean up non-collapsed sel, so theoretically we could change it (there's a hook), but then we'd also change the behaviour of delete :D.

So we'd need to be more specific and affect typing only. We plan to expose it as a command, but then you can hook in only before (useless because selection is not collapsed yet) or after (but then you don't know what was inserted and we cannot rerender content during composition anyway).

In other words, changing the behaviour of input will be tricky. We'd need to carefully think on that algorithm and hooks we expose. Perhaps it will be worth to do this anyway, but this isn't my only worry.

The second reason why I'm afraid about such a solution is that its discoverability is hard to predict. We don't know how many users won't automatically start pressing backspace before typing something. If they do so, then they won't learn how to override the text. Users may also start wondering how to specify the text when still inside the link balloon. There's no promise there that they will be able to change the text later.

tl;dr: I think this could be a nice enhancement in the future, but it shouldn't be the only way.

[oleq]

The text input should only be visible when creating a link on a collapsed selection. So when editing an already created link or creating a link on a non-collapsed selection, only the URL field should be visible. Optionally, instead of hiding the text input, we can disable it.

This is not an option. A magical field, which is displayed only in some cases is a UX nightmare. People will get confused/angry because it is displayed in some cases and sometimes it is not. We can either show it no matter what case (just like Google did) or ditch the idea and keep things simple, which is just as bad (see "cons" in https://github.com/ckeditor/ckeditor5-link/issues/11#issue-172902804).

Would something like this work, when the whole link is selected?

• If I immediately start typing, the link stays and the text change to what I type.
• If I delete, the whole link is removed.

I'm also concerned with discoverability of such implementation. It's not very clear what happens when and people might just get as confused as with the disappearing text field I mentioned.

But don't worry. This is but an improvement to the overall UX. It's not essential at this moment. It's OK that we don't know what to do yet, really (!).

Let's give the feature a break and see how it performs in some real–life integrations. Let's give it some time and then go back to see what could be done to make the feature even more amazing with a better understanding of the problem, with more knowledge about the needs of our users.

[Reinmar]

This is not an option. A magical field, which is displayed only in some cases is a UX nightmare. People will get confused/angry because it is displayed in some cases and sometimes it is not. We can either show it no matter what case (just like Google did) or ditch the idea and keep things simple, which is just as bad (see "cons" in ckeditor/ckeditor5-link#11 (comment)).

So +1 for what Google did.

[Reinmar]

In the topic of typing over a link and replacing link text: w3c/editing#156.

[Reinmar]

And typing after a link: w3c/editing#156.

[Reinmar]

The current behavior is much better than in the past. Right now, you can do that:

1. Press ctrl+k
2. Type the link URL
3. Press enter
4. Your caret ends up after the link
5. Select the link text (shift+left)
6. Start typing (this was fixed in ~21.0.0)
7. The text of the link was changed, the link was preserved

So, it's not as short as it could be if we added additional input to the link balloon but it's quite ok right now.

[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).