I'm trying to force spell check on a contenteditable element that is not being directly modified by the user's keystrokes (i.e. I'm translating events and performing content changes, selections, etc, via Javascript). This is an issue, as Webkit browsers only attempt to spell check content that is from the user, of which I have none via the event translations.
Element.forceSpellCheck() remains unsupported everywhere which should be the right way to do this.
The technique for dealing with this on inputs was to mimic a selection on each word as discussed here.
I haven't had any luck in getting this technique working on contenteditable elements. The only behavior that will reliably result in the spellchecker's red underline is using the arrow keys and not overriding the events - only when the cursor is placed directly on a misspelled word will the visual red line appear.
Is there another strategy to try out for dealing with this?
Related
I am working on an nw.js app that uses a rich text editor. I would like to implement as-you-type spell checking using the typo.js api[1]. Unfortunately this api ships with no UI and it is up to the developer to implement one.
I will mention that while the Chromium built-in spell checker is now available in nw.js, I would prefer not to use that for reasons I won't go into now.
The editor is a contenteditable div element and currently what I have worked up for spell checking is iterating through the text nodes of the contenteditable element using treeWalker, parsing out word strings, and spell checking them. It is convienent once I have identified the nodes and the offsets of the misspelled words to get the geometric position of the words using range.getBoundingClientRect, in order to know where to place decoration (eg "squiggly underlines" or what have you.)
The challenge in this is how to make the UI responsive something of the caliber of spell checkers which are probably written in lower lever languages. I have tried:
1) Creating fixed position divs appearing as underlines and appending them to document.body, and using left/top to position them correctly.
2) Splitting out text nodes of the misspelled words and making them a child of a styled span which is inserted in their place.
1 has the problem of finding a natural (and not too kludgy) way of getting the decoration to follow changes in the positions of the misspelled words, such as when inserting text before a misspelled word, scrolling, or resizing.
2 takes care of this problem, however I would rather not mess with the DOM of the editor. For one thing, this can often be picked up when copying and pasting into another app.
I am hoping there is some other means of which I am unfamiliar in how to go about this task. Any and all suggestions would be appreciated.
[1]https://github.com/cfinke/Typo.js/
I've check numerous questions on SO but couldn't achieve required behaviour.
I have registered an on change listener on ckeditor instance, when a charecter is typed I check if the language is persian or not.
If the language is persian, direction should be changed to RTL automatically.
Similiar question has been asked here but reinitializing the editor doesn't create a nice ux.
Another approach I tried was to change config of the editor on the fly, but apparently Ckeditor ignores it completely.
the way I did was:
CKEDITOR.replace('editor1', newConfig);
So my question is: how do I change ckeditor's direction on the fly without reinitializing the instance?
You could take a look at BiDi plugin which allows to change text direction of any block-level element (e.g. paragraphs) - see this SDK sample.
So if on change event you detect that Persian was typed, you may automatically update the block-level element dir attribute (that's what BiDi plugin is using). To get block-level element based on current selection take a look at elementPath and its block property.
I am working on a WYSIWYG editor (customising someone else's code) and have encountered a few problems that I just can't seem to overcome.
So far I have been able to get most custom divs working, but I am having some trouble with a few things:
Problem 1: If the cursor is before a div element, I am able to press delete and begin to remove the contents of the div without removing the actual div itself. This is how the element should look within the WYSIWYG for example:
But after pressing delete when the cursor is before the element, I get the following:
How can I check if the next element is this custom div and cancel a delete key press?
Problem 2: I am also able to press backspace after an element, which causes any text after the element to appear inside it, like so:
How can I check if the previous element is my custom div and cancel a backspace key press?
Problem 3: When inside a section (where the 'put content here' text is), I am using a div with the attribute contenteditable="true". Every time I press 'enter' within this div, a new <div> tag is created, rather than a line break tag (<br>). How can I force a line break tag to be created instead of a div element?
I have looked far and wide on stackoverflow and have yet to find a proper solution to the problem that is cross-browser.
Disclaimer: I am a CKEditor core developer.
If you want to customise this there are three ways:
You can spend few months (or more) on learning about contenteditable, ranges, selection and all that stuff and trying to implement your custom handlers. You could of course spend only one week or month on that, but the result won't be great, believe me.
You can choose good, existing WYSIWYG editor.
You can lower your expectations regarding the expected behaviour ;).
Now, if you would decide to use CKEditor there's one new feature called Widgets which was introduced in recently released CKEditor 4.3 beta (4.3 stable is going to be released in max. 2-3 weeks). As far as I can see it may be very helpful in your case. Check out the Introduction to Widgets guide. In very short - it is possible to configure how enter key behaves in so called "nested editables" as well as to secure integrity of your custom markup.
I've been looking into creating a Rich Text editor, and at first I was planning on using contentEditable, but it turns out the results are extremely inconsistent and that the output HTML is often broken.
I was wondering if there are any alternatives to using contentEditable, such as the way Google Docs does it (they created there own engine).
Even Google Docs are built on contentEditable. They, however, use it in a different way most editors out there do.
When you focus the document area, it just seems like it is focused because of the fake caret. The actual focus goes to an <iframe> with keyboard event listeners set up. The engine (kix) then modifies the document area based on the keys you press.
This is awesome because there are really no serious cross-browser inconsistencies as the browser is not the one modifying the DOM.
The only alternative I can think of might be a simple text input instead of a contentEditable element but why bother with issues like max length when you can just take advantage of contentEditable ;-)
Why not give TinyMCE a go? It is quite good and fairly refined - just need to combine it with PHP and you can save the contents :)
I'm wanting to provide a resizing textarea control for users. I've given this a go and looked at a number of other implementations, but I can't seem to find one that meets all my requirements. Specifically I want a control that:
Works in IE6, IE7, IE8 on Windows and Firefox 3 and 3.5 on Windows and OS X when the page is rendered in standards compliant mode (i.e. not in quirks mode).
Does not mess up the undo buffer/undo stack. This is a particularly nasty issue with IE - adding nodes, removing nodes and some other DOM operations will reset the input buffer meaning that if an implementation relies on these techniques an undo will not behave like it does in a standard textarea control. I haven't been able to find much information about this bug except for this note. Implementations like the jQuery Auto Growing Plugin suffer from this problem - try undoing changes in IE and compare how this works to a standard textarea. I've added an example page demonstrating this problem to JSBin.
Has a maximum height beyond which the control cannot grow.
Shrinks appropriately when content is deleted.
Does not flicker or act strangely on keypress. e.g. jQuery Auto Growing Textarea control behaves strangely with, at least IE7, when the control has grown beyond it's initial size.
Does not require the control to use a fixed-width/monospace font.
The closest I've seen to something that works like this is Facebook's status update field, which is implemented as a content editable div element, but I have some reservations about using such an element because using a div means:
Need to explicitly style the border which means we could end up with a border that looks different to a native textarea.
Need to sync content with the real textarea (possibly in both directions?).
Adds complexity when placing hints and other elements relative to position of a textarea.
While this approach works for something like a Facebook status update, how well would it work in a form containing hundreds of standard input elements?
What I've set out above represents the "ultimate resizing textarea" - addressing what I perceive to be issues with existing approaches. Does such a control exist? Is it possible to write such a control?
Check out DOJO tools text area control
see more on this demo page (text area At the end of the form )
This closely come to your requirements.
You may need to roll your own to meet those requirements.
These could be a start.
http://tuckey.org/textareasizer/ (though try and avoid eval() in yours)
http://www.felgall.com/jstip45.htm
http://viralpatel.net/blogs/2009/06/textarea-resize-javascript-jquery-plugin-resize-textarea-html.html
This actually seems like a good jQuery plugin. I might have a tackle at developing something like this. If I get it done, I'll post it here.
I spent a few hours developing something, but then I found this one that seems to be really good.
http://www.aclevercookie.com/demos/autogrow_textarea.html
You want to auto-size the display? but leave the content the same?
That is all the scripts can do, adjust the display, and let you see more of your own text...
This A List Apart post contains an implementation that looks pretty close to meeting your criteria and contains a good explanation of what's going on.
Are any of these useful?
Textarea Resize JavaScript: Resize textarea using jQuery plugin
Smart Area: A Lightweight Resizing Text Area Plugin for jQuery
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 1
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 2
How to Build an Auto-Expanding Textarea jQuery Plugin, Part 3
Resizable Body
I have been using nicEdit. It seems to have all that you need and the script is only 1700 lines with an MIT license so you could make any changes you need.