Skip to content
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

Should links be pasted as rich HTML or as plain-text? (when data transfer provides HTML) #6629

Closed
oleq opened this issue Apr 17, 2020 · 2 comments
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:link resolution:expired This issue was closed due to lack of feedback. status:discussion status:stale type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@oleq
Copy link
Member

oleq commented Apr 17, 2020

📝 Provide a description of the improvement

A follow-up of #6053 (comment).

For example:

  1. Go to this fiddle:
  2. Copy the URL from the browser address bar (not the one in the textarea).
  3. Paste it inside CKEditor -> auto-linking DOES happen.
  4. Go back to that fiddle:
  5. Now copy the URL from the textarea in the results pane.
  6. Paste it inside CKEditor -> auto-linking DOES NOT happen.
    We have an inconsistent behavior here. Users may feel that what happens is right but the fact is that CKEditor is having no control of it... and no control is not good.

The fact is that the browser itself is saving in the clipboard the url copied from its address bar in both HTML and plain-text format. The HTML version is something like <a href="url">url</a> and that's the one used by CKEditor. When copying from the textarea, the clipboard has plain-text only.

I believe the proper solution here is not auto-linking in such situation and leave the auto-linking feature to be handled by a future feature that will do so in all cases, no matter if copied from the address bar or a plain-text source.


Personally, I see nothing wrong with links being pasted as rich text until we have a proper auto-linking feature. For the end-user it's almost always a win if the editor does any content discovery (even if accidental).


If you'd like to see this improvement implemented, add a 👍 reaction to this post.

@oleq oleq added type:improvement This issue reports a possible enhancement of an existing feature. status:discussion package:link labels Apr 17, 2020
@Reinmar Reinmar added the domain:ui/ux This issue reports a problem related to UI or UX. label Apr 27, 2020
@mlewand mlewand added this to the nice-to-have milestone Apr 27, 2020
@pomek pomek removed this from the nice-to-have milestone Feb 21, 2022
@CKEditorBot
Copy link
Collaborator

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 still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

@CKEditorBot
Copy link
Collaborator

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

@CKEditorBot CKEditorBot added the resolution:expired This issue was closed due to lack of feedback. label Nov 12, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:link resolution:expired This issue was closed due to lack of feedback. status:discussion status:stale type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

5 participants