I am making an editor without relying on contenteditable, in order to get a clean, controlled output. So I'm catching all keyboard and mouse events, building a model and creating a DOM view from that model.
Since I need spellcheck, I activated contenteditable in divs in my view. The user doesn't interact with it, because I'm catching all events.
The problem I have is that spellchecking only seems to be activated on user input on the contenteditable div, which in my case happens only when I right-click somewhere on the text (because I'm not catching that). I've found a question that just says we shouldn't expect spellchecking to be active at the beginning - but in my case even when the user types, spellchecking doesn't happens (because he doesn't type in the contenteditable, I'm building it).
HTML spellcheck in contenteditable div not working after span
So is there a way I can trigger an event that would make the browser think the user is interacting with the contenteditable?
Update: that's only for Chrome, in Firefox the spellchecker works even without events directly caused by the user.
Related
I have a canvas app where I handle window's keyup and other events. This works fine. However, now I've created a popup div with a textarea in it, and I don't want my keyup handling to be active when the textarea is focused (or when the popup is visible).
I could set a bool isPopupVisible and check for that in my keyup handling, but it strikes me that much more elegant would be to just use the standard focus management of HTML. So I tried handling the canvas's keyup event rather than the window's, but now the problem is that the canvas never receives focus (not even if I click on it) so it doesn't receive any key events. Apparently most HTML elements can't receive focus.
What would be a good way to resolve this?
Edit: It now occurs to me that what I want is in effect a modal dialog box, which HTML doesn't natively support. To support this modality, it's normal to implement it manually with a bool as I initially planned. Standard HTML focus doesn't provide for that, even if I could get the canvas to receive focus. Because the user can switch focus back to the canvas by clicking on it even when the popup is still visible (undesirable).
So I guess I withdraw my question.
I have a <div contenteditable class="content"> </div> in my template whose inner HTML is tied to Mongo. When I (dynamically) add a new .content, I'd like to be able to focus it so that the next thing a user types is entered in the contenteditable div.
However, the .focus() event doesn't play nicely with Meteor's rerendering; even SO's hacks don't work: The JS executes without error, but the focus event doesn't seem to trigger anything (or, it does but it's immediately overwritten by Meteor's rendering).
My question is: How can I force focus that div? A plan I considered was setting a tabindex and then artificially tabbing to that element, but I'm hoping to not have to resort to such silliness.
[EDIT] I'm aware of the {{#constant}} tag, but as far as I can tell, that stops the element from being rerendered at all, which is certainly not what I want.
Place focus code into Template.blah.rendered.
As we know can set contenteditable in DIV to allow editable. It can make same like Textarea.
However there's the most big different are the "content copy and paste" to DIV and Textarea.
DIV is allow html/plain but Textarea only serve plain text.
Below are the method to solve those problem:-
Method 1 - Direct using window.clipboardData.getData('Text') ( will prompt for asking permission).
Problem : Mozilla and chrome are not support clipboarddata.
Method 2 - Using flash.
Problem : Flash v.10 has upgraded to new rules which cannot get clipboarddata without user first initialize.
Method 3- Using "onpaste" event. When data paste on div -> Set focus
on hidden textarea -> Get value from hidden textarea and set into div
by using setTimeout -> clear hidden textarea.
Problem : The timing set value to hidden textarea are not consistent.
I have saw google was doing well on this.
For IE , use clipboarddata.
For Mozilla,others (not support html5) - Anyone know how google done it ?
Hint: use iframe designmode ?
For Chrome (support html5) - Just set DIV to Contenteditable="plaintext-only".
The trick that I use for this kind of thing is to have an offscreen <textarea>, which is not visible to the user.
The textarea is focussed and has a keyboard handler that notices whether the user is typing in the textarea. As I detect the user is typing, I grab the value of the textarea and dump it in the div.
This is the basic idea. You'll need a bit more to get the look and feel right:
you can't just hide the textarea with display:none or visibility:hidden because that will generally make it insensitive to typing and events too. So you need to make it really small and position it outside the screen, or stack it behind some other element.
you're going to have to detect whether the textarea blurs and decide if you need to refocus it.
You'll want a click handler on the div so that if people click the div you can focus to the textarea instead so people can start typing again.
The nice thing about this approach is that general keyboard handling, like ctrl+cursor, and cut+paste etc. all work exactly as expected without having to code that yourself - you're just piggybacking on the existing functionality of the textarea.
Here's an example of how this works:
http://js1k.com/2012-love/demo/1168
(A javascript shell)
I have a small text editor in my home page ( a textarea ) where I can paste text. How can I get this text in a variable before it would be pasted? I know that there is this function:
clipboardData.getData()
but it doesn't work in Firefox, and I want something for all the browsers.I am using HTML and Javascript.
thanks
The short answer is that in general you can't get the text before it is pasted. What you can do is what big web-based WYSIWYG editors such as CKEditor and TinyMCE do, which is:
Detect a Ctrl-v / shift-ins event using a keypress event handler
In that handler, save the current user selection, add a <div> element off-screen (say at left -1000px) to the document, move the caret to be inside that div, thus effectively redirecting the paste
Set a very brief timer (say 1 millisecond) in the event handler to call another function that retrieves the HTML content from the div and does whatever processing is required, removes the div from the document, restores the user selection and inserts the processed HTML.
Note that this will only work for keyboard paste events and not pastes from the context or edit menus. By the time the paste event fires, it's too late to redirect the caret into the div (in some browsers, at least).
Getting the clipboard to work across all browsers is tricky and I believe it's safe to assume there's no way to make it work with only JavaScript, unless you're targeting one specific browser (usually IE). I used ZeroClipboard for this: http://code.google.com/p/zeroclipboard/ - it seems to do its job OK.
When it comes to navigating through an HTML form by hitting the TAB key, Internet Explorer 7 treats an INPUT element with TYPE=FILE as two controls (see MSDN for details). The first time you hit TAB it focusses on the text field, and the second time it focuesses on the Browse button. This is invisible to JavaScript.
The problem is I want to use Ajax Upload or something similar to allow the user to click what looks like a button and see the File chooser appear. This works by placing an invisible file-input element under the mouse. I have managed to change the script to allow you to TAB to the hidden file-input element and for this to trigger a CSS change so the fake button looks like it has focus, the upshot being that, on browsers other than IE7, it looks to the user as if you can tab to the button and activate it as you would expect.
This cannot work on IE7 because the first TAB takes it to the invisible text field; pressing SPACE adds a space to the invisible file name instead of activating the file picker. I have tried adding an event handler for keypress that calls the click event, but when I do this the change event I am depending on seems not to be fired.
I am beginning to think the only accessible solution on IE7 (and, I assume, IE8) will be to replace the whole dialogue with a two part form -- the first part with a (visible) file-input element and Upload button, the second part with all the other form items. This is unfortunate because (a) IE7 get a less slick user experience, and (b) I have to add all sorts of extra server-side code to allow the form to be submitted in two parts.
So I would be interested to know if anyone has a way to make IE7's file-input element behave like a single control, or, alternatively, to allow JavaScript to access both controls of the element (something the DOM was not designed for!).
This a bit complicated to do but here's how:
Create a new button to use as your "fake" input control (you have this as the visible element). This element needs to be a button or a link for it to be able to get tab focus (I suggest button so that it works better on Safari).
Remove the file input from the tabbing order by setting it's .tabIndex to -1. It should now be hidden from sight and tabbing order.
Assign events to the file input so that on activity then the focus is moved back to the fake button, values are copied from it, and so forth.
Assign a click event to the fake button that calls .click on the file input element. This will only work for IE. It will also very likely break in a future release.
For mozilla style browsers you can move the focus from the fake button to the file input on keydown, the keypress event will the occur on the file control and you can then move the focus back to fake button on change. This should also give you del/backspace functionality (clear field).
Clearing the field in IE can only be done by rebuilding a new file input control.
As should be obvious from my other answer, I have managed to build this widget with full keyboard accessibility.
My sincere advice is to drop this pursuit. It is a maintenance nightmare. You are exploiting security holes in the browser to make this work and it is only a matter of time before vendors close something that you rely on.
You could also check out swfupload, as it may provide what you're going for and more.