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
All 21 comments
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).
Reinmar
on 19 Sep 2016
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.
wwalc
on 19 Sep 2016
oskarwrobel
on 19 Sep 2016
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鈥搒tep editing, like described in ckeditor/ckeditor5#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鈥搒tep 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鈥搇ike content, the 2鈥搒tep 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.
oleq
on 19 Sep 2016
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.
fredck
on 19 Sep 2016
Let's find out. I'm for sticking to stable 1鈥搒tep editing in iteration 3 and figuring it out how to improve it in i4. Even by adding that 2nd step.
oleq
on 19 Sep 2016
Actually, the easiest way to open a link is using the right click -> open link :D.
Reinmar
on 22 Sep 2016
@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 ;-)
oleq
on 5 Oct 2016
@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:
scottmessinger
on 1 Dec 2016
Maybe there's no problem after all ;-)
@oleq https://dev.ckeditor.com/ticket/7145 and plenty of duplicates
wwalc
on 2 Dec 2016
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.
scottmessinger
on 12 May 2017
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鈥揺dit 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:
- Closing the form (Esc, "Cancel" or "Save") focuses editable instead of going back to the first step that I called "link actions".
- 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
on 21 Jul 2017
An afterthought: do we need an icon after the URL?
oleq
on 21 Jul 2017
How will it look with longer URLs? Eg. https://stackoverflow.com/questions/3341485/how-to-make-a-html-page-in-a4-paper-size-pages
wwalc
on 24 Jul 2017
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.
Reinmar
on 24 Jul 2017
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.
oleq
on 24 Jul 2017
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.
iainhallam
on 26 Jul 2017
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.
Reinmar
on 26 Jul 2017
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.
iainhallam
on 26 Jul 2017
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).
zadam
on 26 Dec 2017
This issue will be handled in https://github.com/ckeditor/ckeditor5/issues/645.
oleq
on 24 Jan 2018
Related issues
benjismith
路
3Comments
metalelf0
路
3Comments
hamenon
路
3Comments
oleq
路
3Comments
pandora-iuz
路
3Comments
Most helpful comment
ATM
text-overflow: ellipsis;at 150px is used which results inhttp://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.