Develop Reference

Managing No Man's Land in a content editable editor

Background:
My program offers smart brace completion, that is automatic addition of a ] on typing a [.
Problem:
Consider this scenario:
Notice the editor on the left where the caret is placed. As you can see in the Inspect Element on the right, the caret is placed right between two consecutive <br>s. There is no text node or element node between them. The caret belongs to neither of the <br>s. It is a no-man's land. What is surprising is that the caret belongs to the parent editor!
Above you can see range.startContainer and range.endContainer both point to the parent content editable editor div.editor.show. Also, the second print line that mentions 2 is the caret position that I got using range.startOffset. I have a faint guess that the 2 refers to one text node and one <br> that precede the caret.
What happens due to problem:
The second ] that has to be inserted after [ gets inserted at the second index in the entire div.editor, meaning right after Th at the beginning. So, after I locate my caret in the no-man's land and press [, this happens:
Question:
How am I supposed to detect and provide a fix for this no-man's land problem?
JSFiddle
Note: this does not occur in <textarea>s.

How to get nth line of a text by JavaScript?

Consider a simple html element as
<div id="test">
a long text without line break
</div>
The browser will create lines based on the glyph and font sizes. After text arrangement by the browser (e.g. depending on the window width), how to get the lines of the text by JavaScript?
For example:
How to get the total number of lines
How to get the first line as appeared in the current window?
How to get the nth line?

No, there is no API that gives you access to the rendered text after layout has occurred. The only way to approximate this is pretty hacky, i.e. add words into a container one at a time and see when it changes height. See this related question:
detecting line-breaks with jQuery?
Yeah, who'd have thought it, even jQuery doesn't do this! ;-)

2 easy solutions and a extremely hard one.
1 Formatting the text.
Inside a pre & textContent
html
<pre>hello
hello1
hello2</pre>
js
document.getElementsByTagName('pre')[0].textContent.split('\n')
http://jsfiddle.net/gq9t3/1/
2 Adding br's
Inside a div with br & textContent
html
<div>hello<br>hello1<br>hello2<br>pizza</div>
js
document.getElementsByTagName('div')[0].innerHTML.split('<br>')
http://jsfiddle.net/gq9t3/4/
To much trouble
css
div{width:100px;line-height:20px;}
html
<div>hello dfgfhdhdgh fgdh fdghf gfdh fdgh hello1gfhd gh gh dfghd dfgh dhgf gf g dgh hello2</div>
js
document.getElementsByTagName('div')[0].offsetHeight/20
easy way to find the number of lines but you need to calculate the text width to find the corresponding line content.
http://jsfiddle.net/gq9t3/3/

I was attempting to style the first line of text, but text-transform:uppercase messed it up. http://zencode.in/lining.js/ helped with addressing the first line (responsively!), so perhaps this library will assist with your issue too.

Adding an absolute positioned element causes line break

So I have a "cursor" object created like so:
var cursor=document.createElement('span');
cursor.id="currentCursor";
cursor.innerHTML="|";
cursor.style.fontWeight="bold";
cursor.style.position = 'absolute';
cursor.style.marginLeft="-1px";
Then I add it to the page where someone clicks with this:
var selection = window.getSelection();
var currentRange = selection.getRangeAt(0);
currentRange.insertNode(cursor);
The problem I'm running into is in certain places (mainly end of lines) if the cursor object is added it creates a line break before the object. Using insertNode to move it to another area removes the line break. Also if I set the display to "none", wait for a few seconds and then set it back to "inline" the line break is removed.
This seems like maybe a browser bug in adding absolute elements, but I was wondering if someone had a workaround. I've tried setting the width to 0px but it has no effect.
Update
So if I change the cursor to
cursor.style.position = 'static';
It doesn't have random line breaks. However this causes space to be created around the element. Any way to not allow elements to create space around them?
Update 2
Added a fiddle to show the problem:
http://jsfiddle.net/Mctittles/pSg2D/1/
Original code is a bit large but I slimmed it down to highlight this problem.
If you click at the end of the smiley face and then type it causes line 33 to trigger creating a new text node. After typing a couple letters you'll see the cursor object is forced to the next line. Clicking somewhere else to move it makes the lines merge again.
If you un-comment lines 38 and 40 you'll see what I was talking about with making it initially display:none and changing it later. This time it doesn't cause a line break.
I took out some cross-browser code for fiddler, so this might only work in Chrome

However [position:static] causes space to be created around the element.
No, it doesn’t cause it – there is no actual space created “around it”, it’s just the display width of a character plus spacing in the used font, and that gives the span element itself a width that is more than the | character itself. But when you position the element absolutely, you don’t notice that, because it is taken out of the flow, so it doesn’t push the following characters to the right.
My workaround proposal: Don’t put | into the span as innerHTML, but leave it empty – and then implement the line by giving the element a border-left:1px solid. Remove position:absolute, so that it defaults to static.
Then you might probably not like the height your cursor is getting with that – but that can be fixed as well, by setting display to inline-block, and giving it a height as well.
Here, see how you like ’dem apples: http://jsfiddle.net/pSg2D/9/

You should use CSS instead. Using z-index and maybe even float would (atleast should) fix this.
Edit: Always make sure no other styles make it break line!

different caret position on firefox and IE

To recreate the problem, please visit http://jsfiddle.net/BsJ6V/ and type any character right after the opening body tag (for example, <body>h if you type the h character).
An alert box will display the caret position. When you run it in Firefox the caret position is 56, when you run it in IE it is 60. Could you please what the matter is?
EDIT::
UPDATED LINK.

The difference is because IE counts each line break within a textarea as two characters (CRLF, or \r\n) while Firefox counts it as a single LF (\n) character.
Your function won't get the right caret position in IE if there are leading line breaks. To see this, place the caret at the start of the textarea in your first jsFiddle example and press return a few time and trying typing in one of the empty lines. To fix this, you can use a function I've posted before on Stack Overflow or if you prefer a jQuery plug-in, I've created one for dealing with textarea selections: http://code.google.com/p/rangyinputs/
UPDATE
Note that jQuery's val() method normalizes this difference in line breaks between browsers (unhelpfully, in my view, since the value that gets sent to the server isn't normalized) so that line breaks are always \n. Both my plug-in and your function return a caret position relative to the textarea's raw value property, not jQuery's normalized value, so if you are manipulating the value using the caret position, you need to use $textarea[0].value instead of $textarea.val().
You can see this difference here: http://jsfiddle.net/MyR7J/2/

What characters will a TextArea wrap at, other than spaces?

I'm working on the latest version of my plugin, Textarea Line Counter (http://mostthingsweb.com/?p=84). To make it even more accurate, I want to identify regions of text that wrap because they are too large to fit on the line (like a sequence of repeated characters).
I'm assuming that browsers only wrap text at spaces. Are there any other characters that lines can be wrapped at? Thank you,

Looks like it depends on the browser, my Opera wraps also on e.g. + % ? $ / ( [ { } \ ° ! ¿
Safari/Chrome on ¿ ? too
(guess there are lots more)

Nice idea for a plugin. Fighting the accuracy issues is going to be a challenge.
There's not a universal catch all for the way textarea is going to handle a string (other than line breaks at spaces), or using word-wrap.
IE produced a break with . , () {} ?, but not with / * = +
In this example, textarea seems to have that "special" feeling like a td

Based on all your advice, I have created a solution. It is rather large, and in fact I think I will make it into a separate plugin, as well as including it in my Textarea Line Counter. It works like this:
Create a div to act as a container, and set the font to something monospaced (i.e. every character is the same width)
Create a span within the container, and place a single letter.
Take the width measurement of the span (which will be the width of the letter, once margins, padding, and some other CSS attributes are cloned)
Create another div within the container and clone its CSS attributes. Set it's width to be two times the width of the letter found in step 3, and record its height.
To test if a character will cause a wrap, set the text of the div to: A[some character]A. [some character] is a character you are trying to test.
Test the height of the div. If it is larger than the height found in step 4, the text has wrapped.
I'm looking forward to releasing this plugin. Thank you again for all your advice.

some browsers will break inside words if the word is longer than the col width,
otherwise they break on spaces.
I notice some browsers set this by default- you can, too in most bowsers with:
textarea{word-wrap: break-word}
you can be sure it is not set by using textarea{word-wrap: normal}