I have had this problem for a long time and I just can't figure out how to fix it. I want to create a simple WYSYWYG editor and I have some problems.
Currently I have this:
<div id="editor" contenteditable="true"></div>
<input type="button" value="B"
onmousedown="document.execCommand('bold',false,null); return false;"/>
So, if I have some text inside my DIV, select it and click on "B" it is converted to BOLD, and remains selected, but this doesn't work on Opera and IE.
I just don't know how to make the editable DIV not only keep the focus but also the text selection.
Any idea?
Two possible options are:
Use mousedown instead of click and prevent the default browser action: http://jsfiddle.net/dA9NK/
Make the button unselectable: http://jsfiddle.net/8hpvv/
Related
I have a div that the contenteditable attribute is true,
<div tabindex="1" id="editor" contenteditable="true"></div>
I have another div that acts like a button
<div>Click Me</div>
The problem am having is that after typing inside the editor box, I selected some text and when I clicked on the "click me" div the editor box looses focus and thus removing the highlighted text.
I used in js to programmatically send the focus back
document.getElementById("editor").focus()
But after this the selected text is no more selected the cusor just moves to the beginning of the editor box.
How do I get the focus to make sure the initial selected text is selected again after the click me has been clicked
One solution is setting user-select: none on your button-like div. If the browsers you care about support it, it's the simplest (but as discussed in the comments here, someone reported problems with getting it to work in Safari...)
Otherwise you'll have to save and restore the selection using JS, the text range module of rangy.js is useful for that. Check out https://stackoverflow.com/a/57546051/1026 for a usage example; in your case you'll need to save the selection onblur and restore it after processing the click on the button-like div.
On Chrome (and possibly other WebKit based browsers too), I have an issue where if a checkbox is wrapped inside a label and the label has the attribute contenteditable=true, Chrome fails to focus properly on the label.
<label contenteditable="true">hello <input type="checkbox" /></label>
Clicking on the text fails to focus and instead checks the checkbox.
To focus on the text, it is necessary to select some text and then click on the selection to see the cursor blinking.
To see the wanted behaviour, check on Internet Explorer 11. Clicking on the text itself selects the text, and clicking on the checkbox selects the checkbox.
Is there any fix to this (other than changing the HTML)?
Actually that is what a label is supposed to do
If you insist on doing it as a label you have to prevent the default behaviour of it and cancel the propagation on the checkbox itself:
<!-- Dirty example -->
<label contenteditable="true" onclick="event.preventDefault()">hello <input type="checkbox" onclick="event.stopPropagation();" /></label>
Like I commented before, I would not recommend this. Let the labels do what they are supposed to do and use a span instead.
This is what a label is supposed to do. They make interacting with form field easier (especially on small devices). It is for better UI accessibility.
To see the wanted behaviour, check on Internet Explorer 11. Clicking
on the text itself selects the text, and clicking on the checkbox
selects the checkbox.
You'll need to just use a <span> instead:
<span contenteditable="true">hello <input type="checkbox" /></span>
I have a problem that when the background is double-clicked the first element is selected.
Check out this fiddle:
https://jsfiddle.net/cb6fjr7n/1/
<input style="text" value="lala"/>
If you double-click outside of the input the input will get selected, but it still doesn't have focus because you can't type.
I need to stop this behavior. I want no selection, no focus, no highlight or anything like that when double-clicking. And not just a cosmetic fix, I don't want the focus to move at all.
I still need to be able to input text in the input field though when the input itself is clicked upon.
Just use the css property user-select
Check out this fiddle
https://jsfiddle.net/34kuf1c1/
Just add disabled to your input !
<input disabled style="text" value="lala"/>
I have an input field with some text, and I am trying to toggle its visibility. The problem I'm running into is that after toggling slide animations on the field, its text is invisible.
When the field is brought into focus though, the text is visible again.
I've tested this on Safari/IE/FF and the input text stays visible, but I cannot figure out why Chrome is acting so odd.
http://jsfiddle.net/f63Et/1/
The problem is that jQuery sets the display of the input to inline-block when it does an .slideDown() and that makes Chrome render it incorrectly.
You have a couple of options, for example wrap the input in a div, or set the display to block
You can try to manually focus it by putting in the slideDown()'s callback:
$(this).focus()
This doesn't answer the question of why Chrome behaves strangely, but, as a workaround, if you enclose your input in a div:
<div id="text"><input type="text" /></div>
Then slideToggle the div:
$(document).on('click', '#slide', function() {
$('#text').slideToggle();
});
That appears to work in Chrome.
As a variant you can use $('input').toggle('slow')
I am developing an HTML code editor using simple DIV's and capturing events. When I use this on the iPad the keyboard never pops up since i'm not technically in an editable field.
Is there a way to programatically tell the iPad that I need a keybaord?
If your code is executed via something that was initiated via a user action then it will work.
E.g;
this works (pops keyboard):
<input type='text' id='foo'><div onclick='$("#foo").focus();'>click</div>
this doesn't work (input gets a border but no keyboard pop):
<input type='text' id='foo'>
<script>
window.onload = function() {
$("#foo").focus();
}
</script>
To make the keyboard show on iOS devices you need to focus on an editable element such as an input or a textarea. Furthermore, the element must be visible and the .focus() function must to be executed in response to a user interaction such as a mouse click.
The thing is - we DON'T want the input element to be visible..
I have fiddled with this for quiet some time and eventually got the result I was looking for.
First, create an element you want to use to show the keyboard - in this case a button, and a hidden input element: (Working jsFiddle or Test on a mobile device)
<button id="openKeyboard">Open Keyboard</button>
<input id="hiddenInput" style="visibility: hidden;">
Then use the following javascript:
document.getElementById('openKeyboard').addEventListener('click', function(){
var inputElement = document.getElementById('hiddenInput');
inputElement.style.visibility = 'visible'; // unhide the input
inputElement.focus(); // focus on it so keyboard pops
inputElement.style.visibility = 'hidden'; // hide it again
});
Notes:
I have noticed that iOS safari will automatically scroll and zoom to the area of the input so make sure you use proper viewport and position your input element in a relevant location.
You can use some CSS on your input like setting the opacity, height and width to 0. However, if your input is completely hidden this won't work again, so make sure you leave the padding or border just so there's something to be rendered (even though it won't show up due to the opacity). This also means you shouldn't use display:none to hide it, hidden elements are just not allowed to be focused.
Use the regular keyboard events (keydown, keypress, keyup) on your hidden input to access the user's interaction as you would normally do. Nothing special here.
Place a transparent textarea over the contentEditable div. The keyboard will open, as soon as the user focus the textarea.
Register an event listener on the textarea for the focus event and set the visibilityof the textarea to hidden. This prevents the blinking cursor.
Set the visibility of the textarea back to visible after the blur event occurred.
Register additional event listeners for keydown, keyup, keypressevents and process theses events the same way, as you process them in the contentEditable div.
I have found that calling prompt("Enter some value") does trigger the keyboard on my iPad 2. Not sure if this is helpful in your situation or not.
The answers to this questions suggest that it's not possible: Why doesn't #contenteditable work on the iPhone?
A colleague of mine who was working on a similar project ended up using a textarea for the iPad version of his editor, and contenteditable divs/spans for browsers that support contenteditable. Perhaps something similar would work for you.
Proxy input trick
I figured out another dirty workaround, but works well.
The trick is based on the fact, that if the keyboard is already open, changing the focus will not close the keyboard.
Add a small "proxy invisible input" in top left of the page with position fixed (the fixed position prevents the flicker, also make sure that the field has font-size bigger than 16px to prevent iOS page zoom on focus)
On clicking the button, just .focus() on this invisible field. The keyboard will open...
Show or render your other input fields
Now with the keyboard open just .focus() on the desired input. You can use small setTimeout delay, for example 500ms if needed
Here's a solution for you:
<input id="my-input" type="text" />
<script type="text/javascript">
var textbox = document.getElementById('my-input');
textbox.select();
</script>