Implement basic link creation and edition UX using mouse

[oleq]

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

---

Note: This issue is for mouse–only interaction.

Note: This is the most basic but also the must–have UX that should be implemented in iteration3. Other improvements and sophisticated tweaks to the link UX will have their own issues, which can be resolved in later iterations.

Link creation

Collapsed selection

1. User types text.
2. User clicks toolbar button.
3. URL field in the form is focused.
4. User fills the form and clicks "Save".

Expected:

• A link is created which href == innerHTML.
• Link is selected in editable.
• Editable is focused, typing is possible.

Regular selection

1. User selects text.
2. User clicks toolbar button.
3. URL field in the form is focused.
4. User fills the form and clicks "Save".

Expected:

• A link is created which href corresponds with the URL in the form but innerHTML is what had been selected before linking.
• Link is selected in editable.
• Editable is focused, typing is possible.

Link edition

href === innerHTML

1. User puts the caret inside of a the link.
2. User clicks toolbar button.
3. URL field in the form is focused.
4. User fills the form and clicks "Save".

Expected:

• Link href is updated so it corresponds with the URL in the form.
• Link innerHTML is updated to match its href.
• Link is selected in editable.
• Editable is focused, typing is possible.

href !== innerHTML

1. User puts the caret inside of a the link.
2. User clicks toolbar button.
3. URL field in the form is focused.
4. User fills the form and clicks "Save".

Expected:

• Link href is updated so it corresponds with the URL in the form.
• innerHTML remains unchanged.
• Link is selected in editable.
• Editable is focused, typing is possible.

[fredck]

Should we make it in a way that, if the user starts typing after creating a link in a collapsed selection, the typed text replaces the link contents?

[oleq]

@fredck What you described is beyond the scope of this particular issue. More sophisticated UX behaviours will be described in separate issues, so they can be developed separately.

What I created in this issue is a must have thing in iteration3. Other behaviours can be implemented in i3 or following iterations.

[fredck]

So no discussion if this is a must have? I remember @Reinmar saying something about being able to define the text of the link in such cases, so I thought about proposing the above solution for it.

[Reinmar]

I agree with Fred that it's a must have, but I understand Olek's point – this can be done in a separate ticket. It's a bit beyond the scope of the link itself because it's also a question what engine and typing packages will do.

[oleq]

@fredck, @Reinmar: I decided to split the UX into a number of issues, as granular as possible. This will let us stay focused, understand current status of implementation and manage the lifecycle of feature in the future.

How many issues like this will be closed in iteration3? This one, that's for sure. More is better, of course. I'm creating other issues for different UX aspects of linking right now, so stay tuned.

[oskarwrobel]

Sorry for closing :) Wrong button :)

[oleq]

Closed by ckeditor/ckeditor5-link#19.