A way to open a link

[Reinmar]

There's no way now to open a link which is inserted into the content. I'd expect that when I click the link in the editable, a balloon appears in which I have such option.

I also started thinking that showing the link form immediately when you place selection in a link isn't the best idea. First of all, we can't first show the link (so you could open it) plus, you may change something by a mistake. Hiding editing under an "edit" button would prevent that.

[Reinmar]

https://github.com/ckeditor/ckeditor5-link/issues/32 is a bit related to this issue. Because if we hide editing behind a button, then we have (more) right to save all changes (even those which weren't explicitly saved).

[wwalc]

This is how WordPress does it (the selection was inside "example"):

There is an edit button, the link shown in a baloon can be clicked and opens the page in a new tab.

[oskarwrobel]

Related: https://github.com/ckeditor/ckeditor5-link/issues/26

[oleq]

There's no way now to open a link which is inserted into the content. I'd expect that when I click the link in the editable, a balloon appears in which I have such option.

Yes, I had the same impression but waited for you guys to check if it's a common problem or just me.

We could allow opening the link i.e. by CTRL+click to avoid an additional UI component. We could also prototype a 2–step editing, like described in #4732 and figure out how bad it is.

Honestly, I'd like to avoid an additional step at any price, because it collides with the idea of keeping things smart, smooth and simple in the UI. 2–step editing is OK in apps like Google Docs which usually deal with a lengthy content that you spend lots of time to create using tons of UI, but if CKE5 is to be used as a component edit short, Twitter–like content, the 2–step link insertion feels like an overkill.

WDYT?

I also started thinking that showing the link form immediately when you place selection in a link isn't the best idea. First of all, we can't first show the link (so you could open it) plus, you may change something by a mistake. Hiding editing under an "edit" button would prevent that.

Yes and no. Please take a look on the solution I proposed in https://github.com/ckeditor/ckeditor5-link/issues/26#issuecomment-246636488. I think it's enough to provide a nice editing experience and avoid unwanted changes.

[fredck]

I don't think that 2-step on editing is a big deal... after all, it doesn't happen often that you change a link once you created it. It certainly happens more often that you want to open it just to check what it is.

[oleq]

Let's find out. I'm for sticking to stable 1–step editing in iteration 3 and figuring it out how to improve it in i4. Even by adding that 2nd step.

[Reinmar]

Actually, the easiest way to open a link is using the right click -> open link :D.

[oleq]

@Reinmar Yeah. That's a good point. Maybe we should wait for the feedback from users, not developers and then decide? Maybe there's no problem after all ;-)

[scottmessinger]

@oleq Speaking for our users (tech savvy and non-tech savvy teachers), right clicking and selecting "open link" isn't at all obvious or intuitive. The lack of a way to open a link would be a huge problem for them.

I think @fredck has it exactly right -- opening a link is a far, far more common action than editing the URL. I'm in favor of the wordpress method or the gmail method:

[wwalc]

Maybe there's no problem after all ;-)

@oleq https://dev.ckeditor.com/ticket/7145 and plenty of duplicates

[scottmessinger]

For version 1, I'd like to advocate for adding a button to the link balloon that takes you to the link. For our app, we feel this need acutely -- we don't have a separate editing interface (it's always editable if you have permission). So, you can't click "Done editing" and then click the link like normal. In an inline editing interface, there isn't any possible way to click the link without such a button. Let me reiterate that -- the entire reason people add a link is to visit that site and this feature makes those links meaningless. This isn't a nice to have -- this is breaking links.

I find the answer "users will right click and open link" really puzzling. Maybe your users are way more sophisticated than ours, but I haven't met any non developer who would think that's the way you open a link. But, regardless of whether you trust my observations, the presence of this feature in Gmail, Wordpress, Medium, and the 6 year old bug in CKeditor seems to show this is a pretty standard feature of editors.

Especially if CKEditor5 is serious about being used as an inline editor, this issue is critical to address. I hope you're able to fit it into version 1.

[oleq]

Because the topic of 2-step link editing and visiting emerges here and there (https://github.com/ckeditor/ckeditor5-link/issues/52, https://github.com/ckeditor/ckeditor5-link/issues/143), I prepared some working prototype of the feature with the full keyboard support.

Surprisingly it only took about ~2h to develop and the only missing fragment is tests and minor adjustments.

The obvious reason this 2-step editing is needed is that there's no way (other than using the context menu) to open a link that is in the content. People want this feature and it's supported in big word processors and CMSs.

The second reason is that we want to keep the UI clean. People seldom re–edit links they inserted. But when they go back to them, they usually unlink or visit. So instead of showing the huge form with some "Visit" and "Unlink" buttons overwhelmed by the input etc. we want to offer a clean "come back" in the first step.

There's also the question of the unlink button in ckeditor/ckeditor5-link#143. ATM, the link form shows up for collapsed selection in a link or a completely selected link. If we decide to support a partial selection too, there's a question what would happen if the URL has been changed (split? new href for the entire link?). I'm wondering if the 2-step editing could solve this problem somehow...

Some additional remarks:

1. Closing the form (Esc, "Cancel" or "Save") focuses editable instead of going back to the first step that I called "link actions".
2. If all the UI is hidden, pressing CTRL+K or pushing the toolbar button shows up the form (omitting the link actions). Straight to the point.

Editing

Unlink

Visiting

Accessibility

[oleq]

An afterthought: do we need an icon after the URL?

[wwalc]

How will it look with longer URLs? Eg. https://stackoverflow.com/questions/3341485/how-to-make-a-html-page-in-a4-paper-size-pages

[Reinmar]

Could it be just "open a link" link, without a URL. It'd be slightly less useful because you wouldn't see the entire URL immediately (you'd need to hover it) but URLs are so long anyway that you wouldn't fit most of them if you had 500px for that. So there may be no point in trying to fit anything in there.

[oleq]

ATM text-overflow: ellipsis; at 150px is used which results in http://someveryverylongurl.... It's not that bad. We can increase the limit, of course, to reduce the number of truncated links but still keep the UI useful.

[iainhallam]

Does it have to be a click to show the palette? Given that links are active objects, and that the normal flow is to simply click and go, perhaps on the desktop the palette could open on hover. Then a single click on the link could still open it, and applications that don't have a separate editing interface wouldn't break the fundamental model of the web in their normal usage.

[Reinmar]

Clicking in the text is the most natural way to put there the caret. So if clicking would have the default action (opening the link) then you wouldn't be able to perform many typical actions in a straightforward way. E.g. what if the entire editable content was a link? How would you edit it? That's just an edge but it shows that it's not an option.

Besides, such a behaviour would also be dangerous. You might lose your content if the page didn't handle the beforeunload event.

Finally, presenting actions on hover makes the interface inaccessible for people who don't use the mouse (which is the entire mobile world and all keyboard users and blind users, etc.) so there would need to be an alternative way anyway.

BTW, this solution would not even be that straightforward to implement because browsers block the click event in contenteditable elements themselves.

[iainhallam]

OK; that's a good argument for having a way of disabling the edit mode on the text, just so that the site can be used normally. Thanks.

[zadam]

Right click -> open in new window isn't available in Electron (and similar runtimes). Currently there's no (native) way to open the link (currently using doubleclick but that's not ideal).

[oleq]

This issue will be handled in #645.