4 ms·

Can you point to where contenteditable is used? I was not able to see the attribute when inspecting the demo source.

jameskilton 9y ago
https://ckeditor5.github.io/ https://ckeditor5.github.io/, inspect the content editing div itself, it's there. One thing I've realized playing with a ton of different editors is that contenteditable gives you one very important feature that you can't fake yourself: access to the browser's spell check and corrections. It's possible that CKEditor ignores everything else about contenteditable, but turns it on just for red squigglies.
- mook 9y ago
  Spellcheck and corrections can be faked, I think, if you decide to compile your own hunspell (or whatever). IME (i.e. entering text for languages that do not have a one-to-one mapping of key press to character), though, is a lot harder; you have no idea what languages the user has configured, and showing _everything_ in a list is impractical.
  - mwcampbell 9y ago
    Not only IMEs for various languages, but also alternative forms of input such as speech recognition.
  - steadicat 9y ago
    Few people seem to know about Composition Events: https://w3c.github.io/uievents/#events-compositionevents https://w3c.github.io/uievents/#events-compositionevents Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.
    - marijn 9y ago
      Unfortunately, it's not that easy. Composition events are typically controlled by the IME software, which is not part of the browser proper, and tends to be a lot less serious about conforming to standards. The result is that the data in those events often simply doesn't correspond to the actual DOM changes that they caused. On Android, you can't even rely on the fact that compositionstart fires when a composition is started—with some virtual keyboards (which act as IME providers) you routinely get compositionupdate or compositionend before a start event. Listening to these events and using DOM diffing can get you a more or less accurate idea of what happened. But 'relatively easy' does not apply.
  - kijin 9y ago
    IME support sucks, even with contenteditable. I have yet to find a free contenteditable-based WYSIWYG editor that works properly with the Korean IME in recent versions of iOS. Duplicate characters everywhere. Even the Enter key sometimes works and sometimes doesn't, depending on what character is immediately before the line break. Froala is better, thanks to a Korean guy who helped develop a fix for them despite the fact that it's not even FOSS.
    - scofalik 9y ago
      It is true that working with IME is hard, even though it is kind of supported by operating system and browser. As much as it is doable for standalone editing, it is a nightmare for collaborative editing, where content changes all the time - not only at the place where you type. Each content change may cause composition (IME) to break. That's how the browser works. This is one of the reasons why "real-time collaborative editing" solutions often implement "block limiting" -- one block/paragraph can be edited only by one user at the same time. Enabling IME will be one of the toughest goals for CKE5's collaborative editing solution - Letters: https://ckeditor.com/letters/ https://ckeditor.com/letters/
- Reinmar 9y ago
  Yep, we do use contentEditable as an input source and also as the view to which we render (you wouldn't be able to reliably handle the keyboard otherwise). I covered the "Can't it be avoided?" section in this article a couple of years ago: https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c https://medium.com/content-uneditable/contenteditable-the-go... tl;dr: Unless browsers will open for the Web multiple crucial features (such as IME, keyboard, selection, touch, on-screen keyboard, spellchecker, etc.) contentEditable is the only sane way to handle text editing. There's an ongoing initiative to fix this situation but it's an extremely complicated topic. I wrote a few words about it in https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d https://medium.com/content-uneditable/fixing-contenteditable... but later things got even more tricky. Since then I've been on W3C's meeting in Paris and contributed to many discussions about the standards and I can say that this whole topic makes even the most experienced browser people suffer when trying to solve it. Fortunately, 2 years later I can still say that things move forward. E.g. the beforeinput event landed in a couple of browsers.
  - dgreensp 9y ago
    Makes sense. There is a route you can go that doesn’t use contenteditable, except as a small box at the cursor position to handle IME; it’s what Google Docs does. At my most recent job (stealth start-up) we built an editor like this, painting our own selection and everything. It makes certain things easy or possible — custom text wrapping, tab stops, custom handling of cursor and selection with regard to embeds. It doesn’t get you very far on mobile web, though.

https://ckeditor5.github.io/ https://ckeditor5.github.io/, inspect the content editing div itself, it's there. One thing I've realized playing with a ton of different editors is that contenteditable gives you one very important feature that you can't fake yourself: access to the browser's spell check and corrections. It's possible that CKEditor ignores everything else about contenteditable, but turns it on just for red squigglies.

mook 9y ago
Spellcheck and corrections can be faked, I think, if you decide to compile your own hunspell (or whatever). IME (i.e. entering text for languages that do not have a one-to-one mapping of key press to character), though, is a lot harder; you have no idea what languages the user has configured, and showing _everything_ in a list is impractical.
- mwcampbell 9y ago
  Not only IMEs for various languages, but also alternative forms of input such as speech recognition.
- steadicat 9y ago
  Few people seem to know about Composition Events: https://w3c.github.io/uievents/#events-compositionevents https://w3c.github.io/uievents/#events-compositionevents Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.
  - marijn 9y ago
    Unfortunately, it's not that easy. Composition events are typically controlled by the IME software, which is not part of the browser proper, and tends to be a lot less serious about conforming to standards. The result is that the data in those events often simply doesn't correspond to the actual DOM changes that they caused. On Android, you can't even rely on the fact that compositionstart fires when a composition is started—with some virtual keyboards (which act as IME providers) you routinely get compositionupdate or compositionend before a start event. Listening to these events and using DOM diffing can get you a more or less accurate idea of what happened. But 'relatively easy' does not apply.
- kijin 9y ago
  IME support sucks, even with contenteditable. I have yet to find a free contenteditable-based WYSIWYG editor that works properly with the Korean IME in recent versions of iOS. Duplicate characters everywhere. Even the Enter key sometimes works and sometimes doesn't, depending on what character is immediately before the line break. Froala is better, thanks to a Korean guy who helped develop a fix for them despite the fact that it's not even FOSS.
  - scofalik 9y ago
    It is true that working with IME is hard, even though it is kind of supported by operating system and browser. As much as it is doable for standalone editing, it is a nightmare for collaborative editing, where content changes all the time - not only at the place where you type. Each content change may cause composition (IME) to break. That's how the browser works. This is one of the reasons why "real-time collaborative editing" solutions often implement "block limiting" -- one block/paragraph can be edited only by one user at the same time. Enabling IME will be one of the toughest goals for CKE5's collaborative editing solution - Letters: https://ckeditor.com/letters/ https://ckeditor.com/letters/
Reinmar 9y ago
Yep, we do use contentEditable as an input source and also as the view to which we render (you wouldn't be able to reliably handle the keyboard otherwise). I covered the "Can't it be avoided?" section in this article a couple of years ago: https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c https://medium.com/content-uneditable/contenteditable-the-go... tl;dr: Unless browsers will open for the Web multiple crucial features (such as IME, keyboard, selection, touch, on-screen keyboard, spellchecker, etc.) contentEditable is the only sane way to handle text editing. There's an ongoing initiative to fix this situation but it's an extremely complicated topic. I wrote a few words about it in https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d https://medium.com/content-uneditable/fixing-contenteditable... but later things got even more tricky. Since then I've been on W3C's meeting in Paris and contributed to many discussions about the standards and I can say that this whole topic makes even the most experienced browser people suffer when trying to solve it. Fortunately, 2 years later I can still say that things move forward. E.g. the beforeinput event landed in a couple of browsers.
- dgreensp 9y ago
  Makes sense. There is a route you can go that doesn’t use contenteditable, except as a small box at the cursor position to handle IME; it’s what Google Docs does. At my most recent job (stealth start-up) we built an editor like this, painting our own selection and everything. It makes certain things easy or possible — custom text wrapping, tab stops, custom handling of cursor and selection with regard to embeds. It doesn’t get you very far on mobile web, though.