5 ms·

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out with a <input type="richtext"> element, which is controlled through a sane API, and the spec spelled out to support everything by default. And get rid of the bane that is rich text editing on the web.

DaiPlusPlus 9y ago
This library is using execCommand: https://github.com/jaredreich/pell/blob/master/src/pell.js https://github.com/jaredreich/pell/blob/master/src/pell.js I note that `contenteditable` itself began as a proprietary DOM/HTML extension by Microsoft in IE5.5 back in 2000 - Gecko didn't support it until 2003. In the 2008 draft of the HTML5 specification[1] the `contenteditable` attribute's summary seems to imply that it's only featured because it "is a common attribute". [1]: https://www.w3.org/TR/2008/WD-html5-20080610/editing.html#contenteditable0 https://www.w3.org/TR/2008/WD-html5-20080610/editing.html#co...
- anilgulecha 9y ago
  My point was execCommand is non-standard, thus requiring workarounds for different browsers/platforms.
chuckdries 9y ago
Minor nitpick: Generally speaking you use execCommand and contentEditable together, otherwise you;re reimplementing execCommand with the selection API
simias 9y ago
Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs and then copy/paste it in the box. Regular <textarea> editing on the web is not generally a pleasant experience (I just had to grab my mouse to extend the comment area so that I can actually see what I'm typing) but rich text "WISIWIG" editors are even worse because the edition shortcuts always intersect somewhat with the regular browser shortcuts (sometimes in fun and interesting ways), they're slow and generally simply not up to par with stand alone editors. Why does everything need to be in the browser? It's a complete anti-pattern as far as I'm concerned. Emacs is often mocked as the "emacs OS" because of how extensible it is but generally this is done by calling external programs, not reimplementing everything in elisp from scratch.
- anilgulecha 9y ago
  Agreed. Hence my point that a web standards body is best placed to solve this once and for all by providing a common (reference) component/API.
- _wmd 9y ago
  98% of the difficulty in implementing a rich text editor is already present in every browser, its hard to call it wheel reinvention at that point. Drawing a caret and responding to key presses by mutating the dom is about the only thing left
  - simias 9y ago
    IMO actually displaying text is not the big challenge in a text editor. The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things since they're not needed to purely "browse" the web. If you want performance while handling big files you also need to optimize the way you stream data from the disk, something browsers are terrible at. Is there any web-technology-based editor that handles big files decently? Last time I've seen a benchmark it was pretty abysmal. Not that Emacs is great at it (it was pretty bad for a long time actually, especially pre-64bit computers) but it still was orders of magnitude faster than Atom for instance: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
    - _wmd 9y ago
      Accurately rendering text in an WYSIWYG HTML editor has equivalent difficulty to implementing the engine used in the web browser that will eventually be used to render that HTML, otherwise it can never truly be WYSIWYG
      - simias 9y ago
roryisok 9y ago
> <input type="richtext"> IF this ever came about (big if) it should support native conversion between markdown / html and other formats. That stuff is a nightmare
- vertex-four 9y ago
  I've never seen two Markdown implementations that do exactly the same thing, unfortunately... even with so-called CommonMark implementations.
jpttsn 9y ago
I think that's a bridge too far. "Rich text" editing is not something to be standardized. Consider <input type="imagepickerwithfilters"> or <input type="spreadsheet">. Useful sometimes, but implies too much standardization.

DaiPlusPlus 9y ago

This library is using execCommand: https://github.com/jaredreich/pell/blob/master/src/pell.js https://github.com/jaredreich/pell/blob/master/src/pell.js I note that `contenteditable` itself began as a proprietary DOM/HTML extension by Microsoft in IE5.5 back in 2000 - Gecko didn't support it until 2003. In the 2008 draft of the HTML5 specification[1] the `contenteditable` attribute's summary seems to imply that it's only featured because it "is a common attribute". [1]: https://www.w3.org/TR/2008/WD-html5-20080610/editing.html#contenteditable0 https://www.w3.org/TR/2008/WD-html5-20080610/editing.html#co...

anilgulecha 9y ago
My point was execCommand is non-standard, thus requiring workarounds for different browsers/platforms.

chuckdries 9y ago

Minor nitpick: Generally speaking you use execCommand and contentEditable together, otherwise you;re reimplementing execCommand with the selection API

simias 9y ago

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs and then copy/paste it in the box. Regular <textarea> editing on the web is not generally a pleasant experience (I just had to grab my mouse to extend the comment area so that I can actually see what I'm typing) but rich text "WISIWIG" editors are even worse because the edition shortcuts always intersect somewhat with the regular browser shortcuts (sometimes in fun and interesting ways), they're slow and generally simply not up to par with stand alone editors. Why does everything need to be in the browser? It's a complete anti-pattern as far as I'm concerned. Emacs is often mocked as the "emacs OS" because of how extensible it is but generally this is done by calling external programs, not reimplementing everything in elisp from scratch.

anilgulecha 9y ago
Agreed. Hence my point that a web standards body is best placed to solve this once and for all by providing a common (reference) component/API.
_wmd 9y ago
98% of the difficulty in implementing a rich text editor is already present in every browser, its hard to call it wheel reinvention at that point. Drawing a caret and responding to key presses by mutating the dom is about the only thing left
- simias 9y ago
  IMO actually displaying text is not the big challenge in a text editor. The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things since they're not needed to purely "browse" the web. If you want performance while handling big files you also need to optimize the way you stream data from the disk, something browsers are terrible at. Is there any web-technology-based editor that handles big files decently? Last time I've seen a benchmark it was pretty abysmal. Not that Emacs is great at it (it was pretty bad for a long time actually, especially pre-64bit computers) but it still was orders of magnitude faster than Atom for instance: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
  - _wmd 9y ago
    Accurately rendering text in an WYSIWYG HTML editor has equivalent difficulty to implementing the engine used in the web browser that will eventually be used to render that HTML, otherwise it can never truly be WYSIWYG
    - simias 9y ago

roryisok 9y ago

> <input type="richtext"> IF this ever came about (big if) it should support native conversion between markdown / html and other formats. That stuff is a nightmare

vertex-four 9y ago
I've never seen two Markdown implementations that do exactly the same thing, unfortunately... even with so-called CommonMark implementations.

jpttsn 9y ago

I think that's a bridge too far. "Rich text" editing is not something to be standardized. Consider <input type="imagepickerwithfilters"> or <input type="spreadsheet">. Useful sometimes, but implies too much standardization.