Can DIV replace TextArea - javascript

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)

Related

Trigger a spellcheck in a contenteditable div

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.

How to build a lightweight online text editor?

I want to build a lightweight online text editor like google doc, but quite quite lighter than that.
What I mean is, I only want to realize the following three functions:
input/delete characters
create/delete a new line
indent
But I'm not quite sure how to build it.
Here is my idea:
Treat every line as a single div.
Monitor the keyboard event, when user hit enter, create a new div
According to my method, I need to set the div's contentEditable=true
However, after that, whenever I hit enter, a newline is created inside the div.
So, how to stop that? (can it only be solved by using javascript?)
Or, is there any other way to achieve my goal?
Just use event.preventDefault(); like so:
$(document).bind("keydown keypress", function(event) {
if ( event.which == 13 ) {
event.preventDefault();
// Your code here
}
});
I think you mean text editors like tinymce or CKEditor. You can make them as lighter as you want.
Be careful about letting people do this on your webpage -- if you're not properly escaping/monitoring input, they can wreak havoc on the page itself preventing them from being able to save things, etc.
Most of these editors implement their editor as an embedded iframe. Since it's being served from the same port, protocol and host, you have full script access to it.
So you make a tag in the iframe editable, and leave all the controls outside the iframe. When they click on a control, you make that happen in the iframe.
When they save, you just grab the contents of the iframe's div.
I would read the keyboard events and just modify the DOM to reflect those keyboard changes. The biggest problem you will have is to position the 'caret' (vertical line').View this SO question to do this correctly -> calculate-text-width-with-javascript
Another alternativ, and one that I prefer, is to use the tag. Its a more lightweight solution and comes with text measurement built-in. Google Closure library has a lot of support for this built in -> Closure Library, and example with text selection -> Canvas Text

Catching all changes to the contents of an input box using JavaScript/jQuery

I have a page with an input box, and a function that processes the value of this input box and produces piece of text. I want this text to always be up to date in relation to the contents of the input box, so I've attached a couple of event handlers to it with jQuery to catch any changes:
$('#input').bind('keyup cut paste', function(){...});
This works well in most cases. Whenever the user modifies the contents using the keyboard in any way, or right-clicks to use the cut or paste functions, the text is updated immediately. However, there are two events I still haven't figured out how catch, if it's even possible to do so:
When the user selects a of text and drags it do a different position in the input box
When the user uses the Delete action in the right-click context menu
Both of these can of course be detected by binding the change event, but the problem with that approach is that it doesn't fire until the input box loses focus. The whole point of these bindings is to have the text update in real-time as the value of the input box changes, so change is no good.
English is my second language so I could simply be bad at wording my Google searches, but so far they've turned up nothing. I haven't found any solutions to this after digging through a couple of related Stack Overflow pages either, so I'm asking here. Is there an event binding for this that I don't know of? If not, is there a different approach I could take? Or is this simply not possible with plain JavaScript?
In non-IE browsers, you can handle the input event.
In IE, you can handle the propertychange event.
Demo (works in all browsers)
It's possible this SO question (and related jsfiddle) might answer your question.
(On the linked jsfiddle, put text in the top box to test)
In other words, bind to mouseup and mousedown, etc.
If you can't find a combination of events that cover all cases, you may want to use setInterval(function() {... }, period). You could play around with the period to see how well this works.

How can I get the text that is going to be pasted in my html text editor?

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.

Can we make IE7 treat a FILE TYPE=INPUT element as a single control?

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.

Categories

Resources