[EPIC] WYSIWYG/Rich Text Editor

As a person using the dwyl App to capture my thoughts/ideas/tasks/nots
I want to have a rich text editor with (basic) controls for formatting
So that I can _visually_ enhance my `items` so they are easier/faster to organise and read.

# Features / Requirements

Each one of these feature/requirement checkboxes will link to a sub-issue with more detail.
If the feature is already available in our choice of (_existing open source_) package, then we can simply check it off once the feature is working (_and covered by our end-to-end UI tests_).

+ [ ] **Basic**:
+ [x] ability to apply styles to text:
+ [x] **bold**
+ [x] _italic_
+ [x] underline (_not standard markdown but we want it for completeness_)
+ [x] strikethrough
+ [ ] hyperlink _existing_ text
+ [ ] pasting/typing a valid link should be automatically hyperlinked (ideally shortened for brevity)
+ [ ] links to Youtube/Vimeo should prompt: "embed or just link"?
+ [ ] embed an image by pasting a link to the image (display thumbnail inline no resizing yet)
+ [ ] Click/tap an image to enlarge/full-screen it
+ [ ] Use Keyboard Tab key to indent text.
+ [ ] Indenting text should create a "sub-item" where appropriate (acceptance criteria TBD)
+ [ ] Bullet points for presentation
+ [ ] Numbered (Ordered) lists
+ [ ] Checkbox for when an `item` becomes a `task` ✅
+ [ ] **Advanced**:
+ [ ] Markdown support? How popular is this outside of the tech community? I know _I_ would use Markdown if we supported it ... how about you? How important do you feel this is?
+ [ ] **Emoji** support
+ [ ] Emoji lookup? (_is this available by default on mobile device keyboards?_)
+ [ ] **Mention** another person in your team (or contact list) to inform them of or assign a task.
+ [ ] Upload images
+ [ ] Re-size images in the body of the text

_Please_ add more features/requirements to this list as you think of them. 🙏
This is _your_ product every bit as much as it's mine. Contribute! 🚀

# Research

I've done a fair amount of research (8+ hours) into the available options in preparation for opening this issue.

For Web I think we need to use a _existing_ **`JS`** package in the short term to _ship_ faster.
As much as I (_still_) love `Elm`, there is no "pret-a-porter" editor we can use, and I think it will take us 1-2 months to develop our own. (see more detail below)

During the course of my research I looked at:

+ https://github.com/basecamp/trix - used by basecamp. well tested.
+ https://github.com/jaredreich/pell - describes itself as "_the simplest and smallest WYSIWYG text editor for web, with no dependencies_" ... zero dependencies. this _really_ appeals to me!
+ https://github.com/yabwe/medium-editor - an open source clone of the medium editor
+ https://github.com/neilj/Squire - Squire is an HTML5 rich text editor, which provides powerful cross-browser normalisation in a flexible lightweight package (only 16.5KB of JS after minification and gzip, with no dependencies!) - used in production at ProtonMail, Tutanota, Zoho Mail and Superhuman ... Squire would be my close-second option, but it does not appear to have an efficient way of passing data for collaborative editing (see below)
+ _many_ more options: https://awesomeopensource.com/projects/rich-text-editor

# Quill.js

My _preliminary_ leaning is towards using Quill.js: https://github.com/quilljs/quill
I don't think Quill is _necessarily_ "_better_" than any of the others, it just has a "kill feature"!
My _reasoning_ for Quill is actually [Delta](https://quilljs.com/docs/delta) the underlying format!

> Deltas are a simple, yet expressive format that can be used to describe Quill’s contents and changes. The format is a strict subset of JSON, is human readable, and easily parsible by machines. Deltas can describe any Quill document, includes all text and formatting information, without the ambiguity and complexity of HTML.
> Don’t be confused by its name Delta—Deltas represents both documents and changes to documents. If you think of Deltas as the instructions from going from one document to another, the way Deltas represent a document is by expressing the instructions starting from an empty document.
> Deltas are implemented as a separate standalone library, allowing its use outside of Quill. It is suitable for Operational Transform and can be used in **realtime, Google Docs like applications**.

`zefyr` https://github.com/memspace/zefyr uses Delta:
So _when_ we need to build our Cross-platform Native App in Flutter, we already have the format to allow us to efficiently pass minimal data over the wire to collaborate on work as a team. see: https://github.com/dwyl/learn-flutter/issues/50

I like the approach taken by Medium (the blogging/writing) platform they don't show the editor controls at _all_ until you highlight a block of text. At which point they show an ultra-minimalist contextual editor:


We _definitely_ want to take the approach of _hiding_ the interface until the interaction by the "user" invokes it. Having a _cluttered_ interface is the _worst_!

## Elm?

I _obviously_ searched for "elm wysiwyg editor" and "elm rich text editor" both on Google and https://korban.net/elm/catalog (_the package search that only includes v0.19 compatible packages_) and looked at https://github.com/mweiss/elm-rte ... it hasn't had much traction since the RFP on Elm Discourse (still only [1 contributor](https://github.com/mweiss/elm-rte/graphs/contributors) last commit 26 Dec 2019), no (real) [tests](https://github.com/mweiss/elm-rte/blob/master/tests/Tests.elm) ... the author appears to have shifted focus to: https://github.com/mweiss/elm-rte-toolkit which is still in it's infancy but looks _really_ [promising](https://mweiss.github.io/elm-rte-toolkit).
See: https://discourse.elm-lang.org/t/a-toolkit-to-create-rich-text-editors-in-elm/5464

If we had _unlimited_ time, we would write our own WYSIWYG editor in Elm for _sure_!
Having no runtime errors and a compiler to catch any type errors would be _awesome_!
But we _really_ don't have a lot of time to spend _months_ writing our own editor which will only be useable on the Web and then we would still need to re-write it for Mobile ... We need to _Ship_!

I don't think we will incur too much technical debt by using an _existing_ JS editor, provided we are laser focussed in our use and it's self contained in the "form" template.

Thoughts?