problem with IE which removes new lines from $("#content").text()
HTML Code
<div id="content">
<p>hello world</p>
<p>this is a paragraph</p>
</div>
jQuery Code
alert($("#content").text());
result (IE) IE removes new line (\n) how can i fix this problem ?
hello worldthis is a paragraph
result (FF)
hello world
this is a paragraph
take a look :
http://jsfiddle.net/vB3bx/
It works fine if you use the div's innerText property. Try replacing
alert($("#content").text());
with
alert( document.getElementById( "content" ).innerText );
Internet Explorer normalizes all white-space and new-line characters into the SPACE character. As far as I know, there is nothing you can do about it.
btw, it seems that IE9 beta changed this behavior. I get new-lines in it.
I'm pretty sure Sime Vidas is correct. I've tried just about everything and whatever I try (innerText, innerHTML, jQuery methods, TextRange, cloning element and putting it inside a pre element etc etc) white space is removed. I'm guessing IE will just remove it on any type of call. It clearly is there during rendering since a white-space:pre will show it, but retrieving it through javascript will always remove the white space except for pre and textarea content.
This behavior has changed in IE9. The only solution in older versions would be to replace new line characters with tags (or anything really, semicolon etc) on the server if possible and then replace them back into \n in javascript after retrieving the text content.
Not sure you're going to find a solution using text() if you consider the following:
Due to variations in the HTML parsers
in different browsers, the text
returned may vary in newlines and
other white space.
at http://api.jquery.com/text/
Related
I know there are other questions on editable divs, but I couldn't find one specific to the Markdown-related issue I have.
User will be typing inside a ContentEditable div. And he may choose to do any number of Markdown-related things like code blocks, headers, and whatever.
I am having issues extracting the source properly and storing it into my database to be displayed again later by a standard Markdown parser. I have tried two ways:
$('.content').text()
In this method, the problem is that all the line breaks are stripped out and of course that is not okay.
$('.content').html()
In this method, I can get the line breaks working fine by using regex to replace <br\> with \n before inserting into database. But the browser also wraps things like ## Heading Here with divs, like this: <div>## Heading Here</div>. This is problematic for me because when I go to display this afterwards, I don't get the proper Markdown formatting.
What's the best (most simple and reliable) way to solve this problem as of 2015?
EDIT: Found a potential solution here: http://www.davidtong.me/innerhtml-innertext-textcontent-html-and-text/
if you check the documentation of jquery's .text() method,
The result of the .text() method is a string containing the combined text of all matched elements. (Due to variations in the HTML parsers in different browsers, the text returned may vary in newlines and other white space.)
so getting whitespaces is not guaranteed in all browsers.
try using the innerText property of the element.
document.getElementsByClassName('content')[0].innerText
this returns the text with all white spacing intact. But this is not cross browser compatible. It works in IE and Chrome, but not in Firefox.
the innerText equivalent for Firefox is textContent (link), but that strips out the whitespaces.
This is what I've been able to come up with using that link I posted above in my edit. It's in Coffeescript.
div = $('.content')[0]
if div.innerText
text = div.innerText
else
escapedText = div.innerHTML
.replace(/(?:\r\<br\>|\r|\<br\>)/g, '\n')
.replace(/(\<([^\>]+)\>)/gi, "")
text = _.unescape(escapedText)
Basically, I'm checking whether or not innerText works, and if it doesn't then we do this other thing where we:
Take the HTML, which has escaped text.
Replace all the <br> tags with line breaks.
Strip out any tags (escaped ones won't be stripped, i.e. the stuff the user types).
Unescape the escaped text.
In my contenteditable div, if the text is deleted (by a user), then immediately proceeded by a space (using the spacebar) and any text, empty quotes appear below the text in the DOM inspector (Chrome and Safari, tested).
Below is what's shown in the DOM inspector:
<div id="reminderTextEditable" contenteditable="true">
" test text"
""
</div>
If the text's leading space is removed in the div, the empty quotes are still there
<div id="reminderTextEditable" contenteditable="true">
"test text"
""
</div>
I tried the following code in an attempt to locate the empty quotes using Javascript, but it always alerts "1":
var list = document.getElementById('reminderTextEditable');
var list_items = list.childNodes;
alert(list_items.length);
Whatever the empty quotes are (whitespace?), they seem to be causing layout issues.
How can whatever is causing the empty quotes be removed?
If you hit enter while editing, some browsers (like Firefox) add a tag to achieve that effect. When you hit backspace, the cursor appears to erase the newline, but it does not erase the tag. It is still there. A similar issue can happen with other whitespace characters.
Mozilla has a couple pretty detailed examples which have functions that delete extra tab indentations or new lines
https://developer.mozilla.org/en-US/docs/Rich-Text_Editing_in_Mozilla.
To do it yourself you have to parse the innerHTML of the contenteditable element. If a node has no innerHTML (or is a text node with no nodeValue), delete it. Then go through the BR tags and if a tag is a BR and has no nextSibling delete it.
Perhaps your best bet would be to adjust your layout so that it doesn't get affected by this issue, either through CSS or JS if the complexity warrants it.
I have the following html
<label>Hello\r\nUsername</label>
<textarea></textarea>
After page load i want to set the content of the label to textarea
normally
$("textarea").val($("label").html()); // or may be $("label").text();
will set the content to the textarea including new lines.It works fine in FF,But not in IE.
It looke like IE is losing the new line info.
How can i solve this ? Please help me.
After a small search on Google I found out that it isn't possible in IE with a version less then 9 since its a built in problem. Check web.student.tuwien.ac.at/~e0226430/innerHtmlQuirk.html for reference. In all, IE<9 removes all white-space in any DOM element except pre and textarea.
This code work greate in any browser (included IE)
document.getElementById('solicit').innerHTML += document.getElementById('prod1').innerHTML+"< br >";
But when I try remove this same substring using IE, it does not work! In Firefox or Chorme works OK.
var text=document.getElementById('solicit').innerHTML;
document.getElementById('solicit').innerHTML = text.replace(document.getElementById('prod1').innerHTML+"< br >","");
IE does not recognize the substring with < br > ?
I tried without < br > tag and IE works correctly, but I need to be able to add and remove spaces in my HTML element.
using Firefox or Chorme it's replaced with no problem.
How to solve this problem?
Thanks a lot!
The innerHTML property doesn't have to return the exact string that you assign to it. Some browsers do, but IE doesn't.
In IE when you read the property, the HTML code is constructed from the elements in the DOM, not from the HTML code that was used to create the elements. In IE you will get back <BR> even if you use <br> in the HTML code to create the element. That could be solved with a case insensetive replace, but the same applies to the elements inside prod1, which might not be as simple to solve depending on what the code looks like.
You should rather add/remove elements in the DOM instead of manipulating HTML. When you use += and replace on the innerHTML property, you will be converting the elements to HTML, then create new elements again, including all the elements in the solicit element that you don't change. You might consider using a library like jQuery, which makes it a lot easier to manipulate elements.
View source and you might see
<BR>
so add a ,"i" to the replace to ignore case - and possibly a regex to handle the missing white space in the result tag
Thanks for all the help!
Knowing the information that you passed me by saying that IE interprets the < br > as < BR > I was only able to develop this solution:
var text=document.getElementById('solicit').innerHTML;
if (navigator.appName=='Microsoft Internet Explorer')
document.getElementById('solicit').innerHTML = text.replace(document.getElementById('prod1').innerHTML+"<BR>","");
else
document.getElementById('solicit').innerHTML = text.replace(document.getElementById('prod1').innerHTML+"<br>","");
With this browse verification my code works correctly. But I'm sure my solution is not the most "elegant" as possible.
Is there any other alternative using only javascript?
Thanks again
I'm using javascript with a super simple regex to replace a "<" with the HTML character code for it so I can place some code on my site using the pre and code tags and have it done automatically.
jsFiddle link
basically I'm trying to figure out why this js code:
var str = document.getElementById("cleanme").innerHTML;
str=str.replace(/</g,"<");
document.getElementById("cleanme").innerHTML = str;
removes the "/" in the br tag
<pre><code id="cleanme">
<p><br />this is some code</p>
</code></pre>
not a huge deal because I'm just displaying code, but I'd still like to know.
it outputs this:
<p><br>this is some code</p>
thanks
I believe it has to do with the way certain browsers return the innerHTML property. If you use Google Chrome, inspect any < br/ > tag using the debugging tools and you'll notice they don't show a backslash. The same is true when Chrome returns an innerHTML property, the blackslash is stripped out.
So when you pass in:
<pre><code id="cleanme">
<p><br />this is some code</p>
</code></pre>
The browser return an innerHTML property of:
<pre><code id="cleanme">
<p><br>this is some code</p>
</code></pre>
Your RegEx is not the issue.
Your script is OK.
If you try this:
var str = '<p><br />this is some code</p>';
str=str.replace(/</g,"<");
str=str.replace(/>/g,">");
document.getElementById("cleanme").innerHTML = str;
It'll correctly print <br />.
Possibly it's effect of browser's HTML normalization.
Maybe too late to help you, and you've accepted a correct answer, but there's another big potential problem.
I tried this with Firefox 3.6.11 on Linux and 3.6.12 on Windows and they both behaved the same --
I did not see the <p><br>this is some code</p> in the Result pane on your fiddle, instead I saw simply this is some code with no markup at all.
Throwing firebug at it by adding a debugger; statement as the first line in the JavaScript pane and tracing through it, I found that str was getting a value of '\n', that is, just a newline was being returned from innerHTML and nothing else.
Thinking about this, but with no way to confirm it, I suspect it's because Firefox is building the DOM tree differently than you expect, because the HTML you're using is invalid. Inline elements are not allowed to contain block elements; specifically, the <code> tag is not allowed to contain a <p> tag, and <pre> is likewise not allowed to contain a <p> tag -- again, only limited inline elements can be used inside a <pre> tag).
I think FF is implicitly closing the code block before opening the paragraph so the innerHTML of id="cleanme" is nothing but the newline. It renders with the "pre" font as you expect because you've thrown the browser into Quirks Mode.
innerHTML does not return the literal source code, but the result of the browser's interpretation of it.
Different browsers will return very different results for innerHTML, sometimes omitting some quotes and 'optional' end tags, capitalizing some tag names and attributes, and collapsing extra white-space.
And HTML does not close open tags that can't have end tags, so they are not included either.