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 Comments
Leave a Reply. |