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/
Related
According to the answer provided here, this is a Firefox bug that has been resolved resolved:
https://bugzilla.mozilla.org/show_bug.cgi?id=45375
https://bugzilla.mozilla.org/show_bug.cgi?id=218223
<div title="jgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkejgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gkjgjgnfmfnfjdbfkfhrbmfludgdbmfldjrnmgfkvjmrmffgkhfbrkfjgbfjhbfhfghfmjfjnrjrjntmvlgjtmg,lgk,gk" class="hello">
This is a test of a tooltip that could potentially go off of the edge of the screen. What it should do is wrap at the edge of the screen to the next line. It is debateable whether or not a line break in the code should put a new line into the tooltip, since that could be used to make a list. The HTML 4.01 spec says newlines should be treated as whitespace in all attributes that take CDATA, but TITLE takes text, not necessarily CDATA. This has all been in one line up to this point. Now for a newline:
This is a new line. Now for a double newline
</div>
(Open in Firefox)
How do I solve this?
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.
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!
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}
I've written a simple JS function that places the cursor at the end of the contents of an input box when it receives focus (the most common action in the box being to append). I haven't checked in IE, but when there is more text than is visible, even moving the cursor to the end of input doesn't scroll the view to the end of input in firefox 3.6.
Any idea how to do this?
P.S. And no I'm not using JQuery, nor is it an option ;)
Found a solution here using different wording (caret instead of cursor)
You can scroll by assigning to the textarea's scrollTop property:
// scroll to bottom
elt.scrollTop = elt.scrollHeight;
Firefox and Safari also offer scrollByLines, and IE has doScroll, but the scrollTop property is cross-browser and simpler to use.
Personally, I don't like it when the cursor is moved for me to the end of a textarea. If I want it at the end, it takes a fraction of a second to do it my self. It takes around a second to move the cursor from the end to somewhere in the middle (the end is a larger target, thus takes less time to hit). Unless the textarea has a special purpose, I wouldn't bother with the append-on-focus function.