3

I am trying to solve a problem about the following code:

<div contenteditable="true">
    <label contenteditable='false'>Tag1</label>
</div>

The problem is when the user copy and paste the label code inside the div it loses the property "contenteditable='false'". It means, the second label (copied) is no more contenteditable=false.

Any idea how can i solve this?

I tried the following css code, but it does not allow the user to delete the tag.

-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-o-user-select: none;
user-select: none;

I also find about Sanitaze, but i think its too much code to solve something like this..

thanks

Community
  • 1
  • 1

1 Answers1

1

You can work around this problem by putting the "contenteditable=false" attribute back after a paste:

$(document).bind("input", function(e){
    $(".uneditable").attr("contenteditable", "false");
});​

(This assumes that the label has a class of "uneditable". I use the "input" event rather than the "paste" event because that takes effect after the paste (rather than before), and it covers some other actions, such as dragging and dropping text.)

jsFiddle: http://jsfiddle.net/DYKbB/3/

Brilliand
  • 13,404
  • 6
  • 46
  • 58
  • You can, and probably should, put the event handler on the editable div specifically instead of on `document`. – Brilliand May 30 '12 at 01:25
  • Can i solve this problem without this trigger? With css only? – Flavio H. Freitas May 30 '12 at 01:32
  • I don't think so. The issue is `contenteditable` vanishing, and `contenteditable` has no equivalent in CSS. You can, however, do this with pure JavaScript only (no jQuery) - the code would be a bit longer, but not too much. – Brilliand May 30 '12 at 02:39
  • @Brilliand: I have the same need as the original author. I have a contenteditable that the user can edit, but I also have external buttons that put specific "widgets" into the contenteditable. These widgets are contenteditable=false. The user can copy and paste these widgets (and their surrounding text), but the user should not be able to "break" a widget. – Daniel Yankowsky Jul 19 '12 at 17:14
  • @Brilliand: I used something similar to your solution, except triggered by the input event and without the setTimeout. But my comment was actually a response to "you'd think that if the user pasted something, he should be able to edit what he pasted." I just wanted to point out that the OP isn't the only one with this requirement, and that there are legitimate reasons. – Daniel Yankowsky Jul 26 '12 at 18:18
  • +1 to using "input" vs "paste" -- paste doesn't get triggered when you drag 'n drop the text, which also causes contenteditable="false" to get wiped out. – josh Jul 27 '12 at 16:21
  • Thank you - I've updated my answer accordingly. While testing this, I noticed that this workaround has no effect on IE, since IE7 transfers `contenteditable=false` properly, and later versions ignore `contenteditable=false` entirely. So this behavior can't be counted on in recent versions of IE. – Brilliand Jul 30 '12 at 04:15