-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to open a link #4735
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). |
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?
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. |
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. |
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. |
Actually, the easiest way to open a link is using the right click -> open link :D. |
@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 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: |
@oleq https://dev.ckeditor.com/ticket/7145 and plenty of duplicates |
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. |
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 Some additional remarks:
EditingUnlinkVisitingAccessibility |
How will it look with longer URLs? Eg. https://stackoverflow.com/questions/3341485/how-to-make-a-html-page-in-a4-paper-size-pages |
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. |
ATM |
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. |
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. |
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. |
Other: Removed the "Unlink" button. Closes #52. See https://github.com/ckeditor/ckeditor5-link/issues/31#issuecomment-316992952 and https://github.com/ckeditor/ckeditor5-link/issues/149 for plans how unlinking will be exposed in the future. BREAKING CHANGES: The `unlink'` UI component was removed from the component factory.
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). |
This issue will be handled in #645. |
Feature: Implemented a 2–step link UI with a refreshed look&feel (see ckeditor/ckeditor5#645). Closes #31. BREAKING CHANGE: The structure of the link UI has changed dramatically. Some pieces of the `LinkFormView` belong now to the `LinkActionsView` class. The CSS classes have also changed along with component templates.
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.
The text was updated successfully, but these errors were encountered: