While programming a custom WYSIWYG HTML based editor I came to this strange behavior.
jsfiddle
One enters some text containing new lines in a div, which has contentEditable set to true.
At that moment div.innerText contains exactly the entered text including the new lines.
Then one sets div.style.display = none and re-checks the div.innerText: it is the same text, but the new lines are removed.
Why is that? Is there "standard behavior" for this case?
(Tested in both FF Developer Edition 89.0b3 (64-bit) and Chrome Version 90.0.4430.85 (Official Build) (64-bit))
=> Follow up
There is also another similar strange problem:
var d = document.getElementById("divTest")
function setup() {
d.innerText = "1\n2"
}
function log() {
console.log(d.innerText)
logChildren()
}
function logChildren() {
console.log("Child nodes: ");
d.childNodes.forEach(node => {
console.log(node.toString());
});
}
div[contenteditable] {
border: 1px solid red;
}
<div contenteditable="true" id="divTest"></div>
<input type="button" value="setContent" onclick="setup()"/>
<input type="button" value="log" onclick="log()"/>
Click on the setContent button and then on log button. The output is as expected:
1
2
[object Text]
[object HTMLBRElement]
[object Text]
Then click inside the input div. Press enter after the 2 to go to a new line, and press 3. One gets
1
2
3
in the div and one would expect to get the same in the div.innerText, but it is unfortunately:
1
2
3
Child nodes:
[object Text]
[object HTMLBRElement]
[object HTMLDivElement]
[object HTMLDivElement]
Why would 1 be a [object Text] but 2 and 3 [object HTMLDivElement] ? Why would there be empty line between 1 and 2? etc. ...
It does not make any sense to me.
The implementation of innerText depends on whether or not the element is visible. As #Nisala noted in the comments, if you set the display attribute of the div back to block, the innerText contains your newline characters again.
const input = document.querySelector("#input");
function performExperiment() {
console.log(`innerText before style change: ${input.innerText}`);
input.style.display = "none";
console.log(`innerText after first style change: ${input.innerText}`);
input.style.display = "block";
console.log(`innerText after second style change: ${input.innerText}`);
}
#input {
border: 1px solid black;
}
<p>Enter multiple lines of text into the box below, then click the button</p>
<div id="input" contenteditable="true"></div>
<button onclick="performExperiment()">Experiment</button>
If we have a look at the innerText documentation, we see the first step of the behavior for the getter is defined as follows:
If this is not being rendered or if the user agent is a non-CSS user agent, then return this's descendant text content.
Note: This step can produce suprising results, as when the innerText getter is invoked on an element not being rendered, its text contents are returned, but when accessed on an element that is being rendered, all of its children that are not being rendered have their text contents ignored.
So when our div is not being rendered, we should expect that innerText returns the textContent of our div. Indeed, that is what we see.
const input = document.querySelector("#input");
function performExperiment() {
input.style.display = "none";
console.log(`innerText: ${input.innerText}`);
console.log(`textContent: ${input.textContent}`);
}
#input {
border: 1px solid black;
}
<p>Enter multiple lines of text into the box below, then click the button</p>
<div id="input" contenteditable="true"></div>
<button onclick="performExperiment()">Experiment</button>
So why are the newlines present in our innerText when the div is visible? The documentation continues:
Let results be a new empty list
For each child node node of this:
Let current be the list resulting in running the inner text collection steps with node. Each item in results will either be a string or a positive integer (a required line break count).
In this case, innerText is ignoring textContent and is instead operating on the childNodes list. Let's see what the value of that is for our div:
const input = document.querySelector("#input");
function performExperiment() {
input.childNodes.forEach(node => {
console.log(node.toString());
});
}
#input {
border: 1px solid black;
}
<p>Enter multiple lines of text into the box below, then click the button</p>
<div id="input" contenteditable="true"></div>
<button onclick="performExperiment()">Experiment</button>
As you can see, pressing the ENTER key adds a newline to the content of our div by adding a div to the childNodes list of our div. Why this is the case is outside the scope of this question, but would make for a good question on its own.
If you're working on an in-page editor, the HTML spec has a section containing best practices.
To recap:
If the div is visible, the innerText getter uses the textContent property of the div.
If the div is not visible, the inner text collection steps are followed for each node in the childNodes tree and the results are concatenated together.
When computing the value of innerText for our div, the value of the display attribute matters because it determines whether the textContent property or the evaluation of the childNodes tree will be used.
Note: There's a little more information in this answer by #Domino.
Related
I have to create a second button/input box on the page, underneath the green paragraph square where the text has to appear. How do I write the function to get the text centered in the paragraph? I have to use document.getElementById to get the input box object and the paragraph object. Here is what I have so far:
HTML:
</head>
<body>
<div>
<button onclick="sayMagicWord();">Press For Magic </button>
</div>
<p></p>
<div>
<input id ="inputbox" type ="text" size ="10" value="Enjoy your semester at Fordham"/>
<button onclick="enjoy();">Click To Place Text In Paragraph </button>
</div>
CSS:
p {
width: 200px;
height: 200px;
background-color: green;
margin-left: 20px
}
JS:
function sayMagicWord() {
alert("PLEASE");
}
function enjoy() {
}
And here are the instructions from my prof if this makes it clearer:
On the HTML page, add a paragraph with a green background and a width and height 200px X 200px below the first button on the page. (Use a separate css file for styling the paragraph by id )
On the HMTL page, create an input box and another button side-by side and below the paragraph
Associate a second function with the new button. On the javascript file page, create that function. Inside that function, take the text from the input box and place it centered inside the paragraph ( Make use of css also). Give the paragraph and input box an id
Use document.getElementById command to get the input box object, and the paragraph object
Then assign the value of the textbox entry to the innerHTML of the paragraph
So, you need to set an id for the paragraph first. Lets say <p id='e'> </p> , though you can name it whatever you want. Then, in your javascript file, you can tap into the document, then get the ID of the paragraph (in this case, e) and use the method innerHTML() to set the paragraph to the value of the textbox
This would be:
function enjoy() {
document.getElementById('e').innerHTML = 'value here';
}
As for the CSS, refer to
https://www.w3schools.com/csS/css_align.asp
Try to look at pages like w3schools guide on things like the document object model, or its methods. As its homework, some research would go a long way.
I am trying to read multi line user input on a content editable div, and I don't get the right number of line breaks when I read the input with contentEditableDiv.innerText.
I tried textContent, but it doesn't return any line break, while innerText returns too many sometimes. innerHTML doesn't seem appropriate since I don't want any HTML code, just text.
If my div contains:
a
b
It returns "a↵b" (97 10 98 in the example)
But if my <div> contains:
a
b
innerText returns a↵↵↵b (one too many ↵, 97 10 10 10 98 in the example)
var input = document.getElementById("input");
var button = document.getElementById("button");
var result = document.getElementById("result");
button.addEventListener("click", (event) => {
var charCodes = "";
for (var i = 0; i < input.innerText.length; ++i) {
charCodes += input.innerText.charCodeAt(i) + " ";
}
result.innerText = charCodes;
});
<div id="input" contenteditable="true" spellcheck="true" style="border:1px #000 solid"></div>
<button id="button">check</button>
<div id="result"></div>
The standard is a bit vague:
UAs should offer a way for the user to request an explicit line break at the caret position without breaking the paragraph, e.g. as the default action of a keydown event whose identifier is the "Enter" key and that has a shift modifier set. Line separators are typically found within a poem verse or an address. To insert a line break, the user agent must insert a br element.
If the caret is positioned somewhere where phrasing content is not allowed (e.g. in an empty ol element), then the user agent must not insert the br element directly at the caret position. In such cases the behavior is UA-dependent, but user agents must not, in response to a request to insert a line separator, generate a DOM that is less conformant than the DOM prior to the request.
To conform this definition, it is safe to wrap the <br> element into <div>, which Chrome does, but it is UA dependent, so you should not rely on this. The side effect on this behavior and the cause of your problem is that both div and br elements produces line break in the innerText property.
The innerHTML of a↵↵b looks like this in Chrome:
a
<div>
<br>
<div>
<br>
<div>
b
</div>
</div>
</div>
But if you paste it (instead of typing char by char) it looks like this
<div>a</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>b</div>
To reduce the line breaks, you need to further process the innerHTML and treat
<div><br></div> after every input change as a single line-break and then read the innerText (with caution on places where phrasing content like br is not allowed, but in real life browsers can handle them well).
I have a normal HTML input box: <input id="ip">.
And this input box has focused. I know this by looking at the screen and the fact document.activeElement tells me so.
Now I want to replace this input node. And I do so with: var the_new_node = document.createElement("input"); the_new_node.id="ip"; the_input_node.replaceWith(the_new_node);
When I do this, however, the input box loses focus. document.activeElement now points to the body. Is there anyway to prevent this?
Edit: I realise I can call .focus(). Yet in my code I won't necessarily know if the node to be replaced will have an input within it.
For instance, the in various 'virtual dom' implementations they replace segments of the dom tree while retaining focus. How do they do it?
If you want to only focus the new input if the element you're replacing had a focused element inside, you can code exactly that using .contains(document.activeElement):
function runReplace(idx) {
document.querySelectorAll("input")[0].focus();
setTimeout(() => {
let p = document.getElementById("par").children[idx];
let wasFocused = p.contains(document.activeElement);
let newNode = document.createElement("input");
newNode.type = "text";
newNode.value = "replacement for child #" + idx;
p.replaceWith(newNode);
if (wasFocused)
newNode.focus();
console.log("Replaced ", p, " with an input; wasFocused=", wasFocused);
}, 3000);
}
<div id="par">
<p>This is a paragraph with <b>an <input type="text" id="inp" value="<input>"> inside</b></p>
<p>This is a paragraph with no input inside</p>
</div>
<button onclick="runReplace(0)">Replace first paragraph in 3 seconds</button>
<button onclick="runReplace(1)">Replace second paragraph in 3 seconds</button>
There's no magic way the browser can "preserve" focus in face of replacing an arbitrary DOM sub-tree with another arbitrary sub-tree, so you have to do it manually.
I looked at this question where it is asked for a way to simply copy text as plain text. I want to do exactly that but with one additional thing - not lose focus on the current element.
I need this for a Chrome extension, so I'm not bothered with cross-browser support. When the user types in an input (or contenteditable), a dropdown with choices appears. If he chooses one of them, it is copied to his clipboard. I don't want the element to lose focus because some sites might have implemented logic to run on the element's blur event.
Here's what I've tried:
Solution 1
Create an <input> element and use its select() method:
function clipWithInput(text) {
var input = document.createElement("input");
document.body.appendChild(input);
input.addEventListener("focus", function (e) {
e.preventDefault();
e.stopPropagation();
});
input.value = text;
input.select();
document.execCommand("copy");
document.body.removeChild(input);
}
document.getElementById("choice").onmousedown = function (e) {
e.preventDefault(); // prevents loss of focus when clicked
clipWithInput("Hello");
};
#main {background: #eee;}
#choice {background: #fac;}
<div id="main" contenteditable="true">Focus this, click the div below and then paste here.</div>
<div id="choice">Click to add "Hello" to clipboard</div>
As you can see, this works. The text is copied. However, when you focus the contenteditable and click on the "choice", the focus is lost. The choice element has preventDefault() on its mousedown event which causes it to not break focus. The dummy <input> element is the problem here, even though it has preventDefault() on its focus event. I guess the problem here is that it's too late - the initial element has already fired its blur, so my dummy input's focus is irrelevant.
Solution 2
Use a dummy text node and the Selection API:
function clipWithSelection(text) {
var node = document.createTextNode(text),
selection = window.getSelection(),
range = document.createRange(),
clone = null;
if (selection.rangeCount > 0) {
clone = selection.getRangeAt(selection.rangeCount - 1).cloneRange();
}
document.body.appendChild(node);
selection.removeAllRanges();
range.selectNodeContents(node);
selection.addRange(range);
document.execCommand("copy");
selection.removeAllRanges();
document.body.removeChild(node);
if (clone !== null) {
selection.addRange(clone);
}
}
document.getElementById("choice").onmousedown = function (e) {
e.preventDefault(); // prevents loss of focus when clicked
clipWithSelection("Hello");
};
#main {background: #eee;}
#choice {background: #fac;}
<div id="main" contenteditable="true">Focus this, click the div below and then paste here.</div>
<div id="choice">Click to add "Hello" to clipboard</div>
This works perfectly at first glance. The text is copied, no focus is lost, the caret stays at the same position. No drama. However, when you paste the text in a contenteditable (like Gmail's email composer), this is the result:
<span style="color: rgb(0, 0, 0); font-family: "Times New Roman"; font-size: medium;">Hello</span>
Not plain text.
I tried appending the element in the <head> where there are no styles - nope. Text isn't selected and nothing is copied.
I tried appending the text node in a <span> and set stuff like style.fontFamily to inherit, as well as fontSize and color. Still doesn't work. I logged the dummy element and it correctly had my inherit styles. However, the pasted text didn't.
Recap
I want to programmatically copy plain text with no styles while preserving focus on the currently active element.
Your solution (especially 2) was okay. When you paste in a contenteditable, it needs to be expected that there are span codes inserted, many use that in insertHTML. You are not to expect plain text programmatically. Some would suggest not using a contenteditable at all (though I understand you're talking about some extension). But your solution is more compatible with mobiles than MDN or such.
So, you programmatically copy plain with no style added (if no contenteditable) while preserving focus on the current element.
I have been searching on Google for over a week now, I've been trying to implement different solutions, but with no success, and it's bugging the hell out of me.
So you have a contenteditable div with several paragraphs(or other child elements of the same kind). Obviously this is the kind of layout you wanna keep. If the user selects two or more paragraphs and types text over it, it removes the paragraphs and sets the caret focus inside the parent div:
body {
font-family: georgia;
}
.editable {
color: red;
}
.editable p {
color: #333;
}
.editable span {
color: limegreen !important;
}
<div class="editable" contenteditable><p>paragraph one</p><p>paragraph two</p></div>
<hr>
<p>How to reproduce the bug:</p>
<ul>
<li>Focus the contenteditable above by placing the cursor somewhere in one of the two paragraphs.</li>
<li>press ctrl-a (in windows or linux) or cmd-a (in osx) to select-all</li>
<li>type some text</li>
<li>red text means that the text went directly inside the contenteditable div, black text means it went inside a paragraph</li>
</ul>
<p>The correct behaviour should be that that select-all and delete (or "type-over") in a contenteditable with only block tags should leave the cursor inside the first block tag.</p>
<p>Webkit gets this right, Firefox gets it wrong.</p>
I did try something like this in Jquery:
$(document).on('blur keyup','div[contenteditable="true"]',function(event){
var sel = window.getSelection();
var activeElement = sel.anchorNode.parentNode;
var tagName = activeElement.tagName.toLowerCase();
if (!(tagName == "p" || tagName == "span")) {
console.log('not on editable area');
event.preventDefault();
//remove window selection
var doselect = window.getSelection();
doselect.removeAllRanges();
}
});
So after blur or keyup event on contenteditable, detect where the caret position and if it's outside accepted editable areas stop the event or something?
I've tried changing the selection range, and a bunch of other stuff but maybe I'm just not seeing it. I'm sure a lot of people have had the same problem, but the only answers I found on Google or here is "content editable sucks", "why don't you just use an open source editor" and that kind of stuff.
Firefox weird behaviour: Inserting BR tags on break line
I have also tried to remove Firefox'es weird behaviour with a function to remove all the <BR> tags firefox automatically inserts. Like this:
function removeBr(txteditor) {
var brs = txteditor.getElementsByTagName("br");
for (var i = 0; i < brs.length; i++) { brs[i].parentNode.removeChild(brs[i]); }
}
So I attached this to a keydown event, and it does exactly what it's expected, however that causes more weird behaviour (like preventing you adding spaces on selected paragraph).
Please vote up the question so we can raise more awareness.
I'm sure a lot of other people have bumped into the same problem, I think it would be good to know if there's a workaround or any "right" way to do it. I think it should really be discussed...
So Firefox injects this abomination - <br></br> - into the contenteditable div when removing the paragraphs.
With a little bit of jQuery we can remove it and replace it with paragraph tags.
Current Limitation - The break tag seems to be injected only when removed with delete or backspace, not when typed over... consider this a concept :-)
Open this example in Firefox to test:
$("button").click(function() {
$("br:not(p br)").replaceWith('<p>Write Me!</p>'); // dont replace when inside p
});
body {
font-family: georgia;
}
.editable {
color: red;
}
.editable p {
color: #333;
}
.editable span {
color: limegreen !important;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<div class="editable" contenteditable>
<p>paragraph one</p>
<p>paragraph two</p>
</div>
<hr>
<p>Remove all text to trigger bug in Firefox and hit "fix problem!"</p>
</ul>
<p>Webkit gets this right, Firefox gets it wrong.</p>
<button class="fix">Fix Problem</button>
Whats happening is this, when you select both groups of text and delete them you are also deleting all tags within the editable element. So your actually deleting the <p> tags from the div and then the only thing to write to is the div itself.
Why do you need two seperate paragraph tags? It would be easier to have the div by itself...
Rather than setting the div as editable, have you tried setting the <p> tags as <p contenteditable="true">