My task is to set a text caret to appear inside an empty span node within a contentEditable
div.
The following gives me no problems on Firefox 3.6:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script ty开发者_运维技巧pe="text/javascript" src="js/jquery-1.4.3.min.js">
</script>
<style>
#multiple {
border: 1px solid #ccc;
width: 800px;
min-height: 20px;
padding: 5px;
outline: none;
}
</style>
<script>
$(document).ready(function(){
var contentEditable = document.getElementById('multiple');
var lastItem = contentEditable.getElementsByTagName('span').item(2);
var selectElementText = function(el, win){
win = win || window;
var doc = win.document, sel, range;
if (win.getSelection && doc.createRange) {
range = doc.createRange();
range.selectNodeContents(el);
range.collapse(false);
sel = win.getSelection();
sel.removeAllRanges();
sel.addRange(range);
}
else
if (doc.body.createTextRange) {
range = doc.body.createTextRange();
range.moveToElementText(el);
range.select();
}
}
contentEditable.focus();
selectElementText(lastItem);
});
</script>
<title>Range Selection Tasks (Make Me Want to Cry)</title>
</head>
<body>
<div id="multiple" contentEditable="true">
<span style="color:red">First</span><span style="color:green">Second</span><span style="color:blue"></span>
</div>
</body>
</html>
... but on Webkit and IE, the focus is set to the penultimate span. No idea why. It works if I put a space inside the last span, but then I get a one-character range selection.
Having said that, it's acceptable to have whitespace in the last node if the caret is at the very start.
Any help with this would be greatly appreciated. Thank you in advance.
Set the element's innerHTML
to a zero-width character:
('element').innerHTML = 'ÈB';
Now the carret can go there.
IE's selection/range model is based around indexes into text content, disregarding element boundaries. I believe it may be impossible to set the input focus inside an inline element with no text in it. Certainly with your example I cannot set focus inside the last element by clicking or arrow keys.
It almost works if you set each span to display: block
, though there's still some highly strange behaviour, dependent on the existence of whitespace in the parent. Hacking the display to look inline with tricks like float, inline-block and absolute position make IE treat each element as a separate editing box. Relative-positioned block elements next to each other work, but that's probably impractical.
If it makes you feel any better, IE9 finally fixes this unpleasantness and adopts the standard range model. (Hooray!)
it's acceptable to have whitespace in the last node if the caret is at the very start.
I'd probably do that, then, unless an IE selection expert can think of anything better. (Calling Tim Down!)
I found a workaround for Webkit, don't know if anybody found this before but instead of programmatically appending a zero-width space, you can do the same thing with the css3 content property in the after psuedo-selector of the elements you want to put the caret in. This has the advantage that the extra characters don't show up in the DOM and the user can't navigate the caret between it. So basically it doesn't need cleaning up.
For this to work for any child element of your content editable element it would be something like this:
#mycontenteditableelement *:after {
content: '\200B';
}
I didn't check completely, but I suspect this is a full workaround.
For me setting it content of contenteditable div to <br>
works. I tried setting it to nbsp;
but that creates extra character space in the div before i start editing.
Hope this helps.
A bit late to the party but I used Unicodes Zero-Width No Break Space (
) . Then on an event thats called after the users input takes place, remove the Zero-Width No Break Space.
I had many issues with using the Unicode space issue, mostly bad UX. This prevents the user from ever knowing there was an issue.
Applying a minimum height and minimum width to elements inside contenteditable with inline-block can do some good, though the impact has unintended side effects:
#multiple * {
min-height: 1em;
}
span, b, strong, i, em, a, etc {
display: inline-block;
min-width: 1em;
background-color: hsla(0, 50%, 50%, .5); /* this is only a visual aid; discard @ will */
vertical-align: middle; /* so elements w/ inline-block align w/ text correctly */
}
You'll find there are still issues, but if you're willing to sacrifice some problems for a smaller set of others, this can so some good.
精彩评论