## Problem
Current core has a basic textarea as its default editing interface. (With a classic toolbar, but being removed from core per T30856).
Extensions currently "add" editors to MediaWiki by using hooks based on adding arbitrary HTML and JS modules to a page. This does not scale and creates various usability problems that block feature development, which stems from the basic premise that MediaWiki doesn't recognise the concept of an editor. It's just arbitrary HTML that happens to be on the edit page between "page notices" and the textarea.
## Technical requirements
* Core must have a registry of content editing interfaces.
* Extensions must be able to add their interface to this registry.
* Core must allow registered interfaces to restrict themselves to certain content models.
* The registry must have a way to decide what the default will be.
* There must be a way to set the default via a site configuration variable.
#### Undecided
These are not yet requirements. They could be considered as "todo later" (not in the first version), or may be considered "not needed" (easy to do in extensions without core support), or may become requirements later based on feedback.
* Automatically create preferences for deciding which editor should be the default for a given content-model (e.g. dropdown of registered editors).
* Allow setting editor ID by URL (e.g. `title=..&action=edit&editor=..`). This would error if the editor is unknown or not valid for the page's content model. We may end up using query parameters internally as a way to switch between editors (although it could be done invisibly via POST.). But this bullet point is whether we //need// sharable permalinks to specific interfaces (and if so, why).
## Outcome
One can install a wiki, add zero or more extensions to it (e.g. WikiEditor, VisualEditor, CodeEditor), and without doing anything else:
* On the edit page (plain `action=edit`) an appropiate editor is displayed by default for the page's content model.
* The edit page must have a way to switch between editing interfaces (if there is more than 1).
Current issues to address:
* No competing editors should get loaded, overwritten or replaced at run-time.
* No editors should load via urls other than an (extended form of) `action=edit`.
## Proposals
### Miscellaneous
There is not yet a single unified proposals, but here are some ideas to consider:
#### Method of registering
* Configuration variable: wg available editors = array()
* Extension attribute
* Hook
>>! @Krinkle
> Preferably only one method of registering, and I'd prefer not via hooks (for performance), unless we specifically want to encourage complex or conditional registration, which, if we have use cases for it, may lead to improving the registry instead.
#### Entity being registered
>>! @Krinkle
> It seems conventional to register things in MediaWiki by a class or object that implements an abstract interface (with the option to provide a class name, or callback that returns an instance). Do we want that here? If not, why not?
#### Content model
Should we make content model a primitive by which the registry is fragmented? Or should instead the registered entity have a way to decide whether it is compatible? E.g. `AvailableEditors[:contentModel][:editor]` vs `AvailableEditors[:editor]` with `IEditor::supports(ContentModel, TitleValue)` or some such.
#### Setting the default
* wg default editor?
Related:
* {T28914} / T28914#311593 by @brion
* {T120414}
* {T157658}