#Nanospell liscence key free
SCAYT: credit to them for providing a free solution, but I'm not sure this something that's appropriate to enable by default in Drupal because of the terms of use / risks as below. It automatically ends up configured the way the user wants it - language, user dictionary and so on.Even if casual users don't get it, anyone who is technical minded and edits pages a lot may well get it. I agree control-click isn't intuitive, but we could add an option to turn on an on-screen explanation somewhere nearby the editor window.Even without the context menu, you still get the spelling mistakes underlined.CKEditor SpellCheck from Nanospell is an affordable solution.īrowser native spell-check: I think this is pretty usable and would suggest that it is the default. Any spellchecking you see in CKEditor by default is sent across the internet to a 3rd party commercial server for processing, and comes back with PPC ads attached. The rich editor must disable the default spellchecking behavior to render it's menu system. Server:"php" // can be php, asp, asp.net or javaįor background - CKEditor has no built in spell-checking capability on any browser.
#Nanospell liscence key code
Just copy the following lines of javascript code anywhere in your page. The page will verify that everything is working for you, and even provide personalized code samples. Given #6, it seems like there is no viable solution, making this task won't fix or at least postponed?Īs there is no viable solution - i would like to (shamlessly) propose that my own work that my own solution is viable:ĭownload nanospell ckeditor spellchecker and unzip it anywhere in your web/intranet project.īrowse to /path/to/nanospell/getstarted.html
We know that it's kind of anti-pattern, but it's lesser of two evils. The conclusion is that until editor will gain more control over native UI it must block native context menu. I spent a longer while trying to convince the committee that browser can't play a god here.
Therefore, being able to control native UI for contenteditable for me is one of the most important aspects of the contenteditable spec that may finally be developed. That could however lead to unpredictable issues, because of native context menu's contents.
toolbar or bottom bar) in order to unblock the native spell checker. Why I mention that? Because I was analysing whether we could move context menu to other location (e.g. The situation is even worse on mobile Safari where native toolbar pops out when user makes a text selection. Many times these options should not be available, but editor has no control over that. It's even worse on Safari, where we can find options to change font (color, name, bold, italic, underline), enable automatic quotes, automatic links, etc. On I've got about 20 positions in it and some of them are harmful, because they cannot be integrated with editor yet - e.g. Apart from inability to add new options to native context menu, there's a problem with options that are already there. If CKEditor's context menu is required, I believe that SCAYT is the only solution.Īs we are discussing the context menu, I've got one more topic that you could be interested in. To sum up - if CKEditor's context menu isn't required, then native spell checker is a better choice because it's reliable and fast. It's not a perfect solution too though, because it requires internet connection (or buying a server from ), it is a little bit slower and has some additional bugs (it's absurdly hard to implement spell checking in contenteditable). (There's also the possibility to display native context menu if CTRL was hold ( !/api/nfig-cfg-browserContextMenuOn.) but no one knows about this, so this isn't a reasonable solution.Īnd the alternative for above is to use SCAYT which is integrated with CKEditor's context menu. Unfortunately none of the browsers allow yet to extend native context menu (though the feature is included in HTML5) and there's no API to use native spell checker from JavaScript, so CKEditor could integrate native spell checker into its context menu (I proposed this on W3C's mailing list once but the reception wasn't good will try again some day :>). So if you enable native spell checker, you must disable CKEditor's context menu, losing the options that sometimes are available only there (table tools for instance). The problem with native spell checker is that you need the native context menu to use it. Both solutions are imperfect, though, in a general case like Drupal, I would choose SCAYT. Native spell checker and the SCAYT plugin.
0 kommentar(er)
