Go to Administration -> Plugins -> Text Editors
Enable the HTML 5 Text Editor and move it to the top of the list.
Try it on different browsers in different areas of Moodle: (Some suggestions are forum, course settings, create a quiz multiple choice question).
Note the list of subtasks on this issue for improvements already raised.
Try it on a phone.
Get your Mum to try it on her iPad.
Try it on a "Chrome Pixel (you might need to buy this yourself)"
Try it on a palm pilot

Description

Also needs: MDL-40493 to allow users to set their choice of editor in their preferences.

Reasoning:

1. TinyMCE has bugs in iOS that we have been unable to solve in a reasonable amount of time. This editor is much simpler - so less to debug/maintain. We can leave tinymce as the default - but use this editor on iOS spcifically where tinyMCE fails.
2. It fits with Moodle better - it uses YUI for window management, and event handling - and uses moodle pix_icons etc - so the UI "fits" better with Moodle.

Things to do:

Change the name? - done - rename to "HTML5 text editor"

Change the icons? - only for consistency. Can be done when icons are ready.

If this is to be a core editor it needs to support enough of the features that TinyMCE supports so that it is not seen as worse.
Some things tinyMCE does that contenteditable does not:

Andrew Davis
added a comment - 15/Aug/13 2:47 AM When I checked out the branch "HTML5 text editor" was disabled in Site Admin manage editors. Once I enabled it and moved it up the list of editors it appeared.

There doesnt seem to be any visible sign that a button is toggled. If Im typing and click the bold button then shift the focus back to the text field there's no way to know that bold is on aside from simply typing and seeing what happens. It gets weird as soon as you starting turning multiple things on and off as you have to keep the state in you head.

Andrew Davis
added a comment - 15/Aug/13 3:12 AM There doesnt seem to be any visible sign that a button is toggled. If Im typing and click the bold button then shift the focus back to the text field there's no way to know that bold is on aside from simply typing and seeing what happens. It gets weird as soon as you starting turning multiple things on and off as you have to keep the state in you head.

Andrew Davis
added a comment - 15/Aug/13 3:15 AM - edited The text box size changes if you toggle back and forth between wysiwyg and html mode.
https://tracker.moodle.org/secure/attachment/34114/pretty.png
https://tracker.moodle.org/secure/attachment/34113/html.png
Also, when you are in html mode the other buttons are disabled but the visual difference is very subtle. If my eyesight was less good I suspect the difference would be invisible.

In tinymce we offer heading 1 through 6, paragraph, preformatted and address. preformatted and address are a little cryptic...

In the new editor there is title, heading, quoted and plain. Looking at the html title is h1 and heading is h2. Do we just want to call them heading 1 and heading 2 as they are in tinymce? Do we still want to provide all the way up to h6? Maybe just to 4?

Andrew Davis
added a comment - 15/Aug/13 3:20 AM - edited In tinymce we offer heading 1 through 6, paragraph, preformatted and address. preformatted and address are a little cryptic...
In the new editor there is title, heading, quoted and plain. Looking at the html title is h1 and heading is h2. Do we just want to call them heading 1 and heading 2 as they are in tinymce? Do we still want to provide all the way up to h6? Maybe just to 4?

If you expand the drop down containing title, heading etc clicking elsewhere doesnt close it. You can click back in the text box and keep typing and it stays expanded. Pretty minor but a bit unexpected. You can close it by clicking on the button you used to expand it.

Andrew Davis
added a comment - 15/Aug/13 3:22 AM If you expand the drop down containing title, heading etc clicking elsewhere doesnt close it. You can click back in the text box and keep typing and it stays expanded. Pretty minor but a bit unexpected. You can close it by clicking on the button you used to expand it.

Regardless of the scroll position the link dialog displays slightly off the bottom of my screen. 13" laptop if that is relevant. I can drag it up but if I close it and reopen it it goes back to the bottom of the screen.

Also notice that the dotted line from the file area shows through.

And if I click the link button in the editor without having any text selected, nothing happens.

If I select text, make it a link then keep typing the typing goes into the display text of the link. I can't see how to "break out" of the link short of jumping into html view. Simply clicking the unlink button doesn't seem to help. In tinymce I select text, make it a link then any additional typing appears after the link.

I can select text, "unlink" to remove the link entirely but, similar to the link button, it gives me no sign that its even registered the click if I just click it with nothing selected. Perhaps both the link and the unlink button should be visibly disabled until text is selected.

To try and edit a link I reselected a link and pressed the link button. Link URL was empty so I re-entered it. The result was a nested link.

There doesnt seem to be any way to set a link target ie same window, new window. This seems important. If I'm provided a set of links in the forum (or wherever) I'll almost certainly want them to open in a new window.

Andrew Davis
added a comment - 15/Aug/13 3:37 AM - edited https://tracker.moodle.org/secure/attachment/34115/linkDialog.png
Regardless of the scroll position the link dialog displays slightly off the bottom of my screen. 13" laptop if that is relevant. I can drag it up but if I close it and reopen it it goes back to the bottom of the screen.
Also notice that the dotted line from the file area shows through.
And if I click the link button in the editor without having any text selected, nothing happens.
If I select text, make it a link then keep typing the typing goes into the display text of the link. I can't see how to "break out" of the link short of jumping into html view. Simply clicking the unlink button doesn't seem to help. In tinymce I select text, make it a link then any additional typing appears after the link.
I can select text, "unlink" to remove the link entirely but, similar to the link button, it gives me no sign that its even registered the click if I just click it with nothing selected. Perhaps both the link and the unlink button should be visibly disabled until text is selected.
To try and edit a link I reselected a link and pressed the link button. Link URL was empty so I re-entered it. The result was a nested link.
<a id="yui_3_9_1_3_1376534829364_2306" href="http://moodle.org"><a href="http://moodle2.org">moodle.org</a><br></a>
There doesnt seem to be any way to set a link target ie same window, new window. This seems important. If I'm provided a set of links in the forum (or wherever) I'll almost certainly want them to open in a new window.

On the insert image dialog I suspect the "browse repositories" button should be above all the text boxes. Most people are presumably going to use that button and then the text boxes are all filled in automatically. That way the dialog opens, "browse repositories" is at the top to select/upload a file, the text fields are filled automatically and the preview is displayed with the "insert image" button below it.

The insert media dialog is similar.

Clicking outside the insert image dialog doesnt close it. Not sure if it should.

It does not appear to be possible make an image into a link. In tinymce I add the image, click it, click the link button and my image is put within an a tag. In the new editor, selecting the image and clicking the link button doesn't seem to do anything.

On my laptop the insert image dialog is displayed with the close dialog X off the top of the screen. I can drag it down but maybe it would be better to have the top onscreen and require the user to scroll down to see the bottom. https://tracker.moodle.org/secure/attachment/34116/scrollup.png
Note the page scrollbar position. I can scroll down but not up. I have to grab that narrow strip of dark grey and pull the dialog down.

Andrew Davis
added a comment - 15/Aug/13 3:59 AM - edited On the insert image dialog I suspect the "browse repositories" button should be above all the text boxes. Most people are presumably going to use that button and then the text boxes are all filled in automatically. That way the dialog opens, "browse repositories" is at the top to select/upload a file, the text fields are filled automatically and the preview is displayed with the "insert image" button below it.
The insert media dialog is similar.
Clicking outside the insert image dialog doesnt close it. Not sure if it should.
It does not appear to be possible make an image into a link. In tinymce I add the image, click it, click the link button and my image is put within an a tag. In the new editor, selecting the image and clicking the link button doesn't seem to do anything.
On my laptop the insert image dialog is displayed with the close dialog X off the top of the screen. I can drag it down but maybe it would be better to have the top onscreen and require the user to scroll down to see the bottom.
https://tracker.moodle.org/secure/attachment/34116/scrollup.png
Note the page scrollbar position. I can scroll down but not up. I have to grab that narrow strip of dark grey and pull the dialog down.

None of the buttons have tooltips. For users on a regular computer they are nice.

Tinymce give you the ability to toggle LTR and RTL. Does the new editor use the user/site language and automatically format correctly?

Tinymce allows you to insert tables. Not sure if that functionality is important. Generally tinymce offers a lot of manual control. Colors, alignment etc. Stuff I suspect we can do without, at least if the new editor is going to be a light weight fallback for tinymce.

Andrew Davis
added a comment - 15/Aug/13 4:12 AM None of the buttons have tooltips. For users on a regular computer they are nice.
Tinymce give you the ability to toggle LTR and RTL. Does the new editor use the user/site language and automatically format correctly?
Tinymce allows you to insert tables. Not sure if that functionality is important. Generally tinymce offers a lot of manual control. Colors, alignment etc. Stuff I suspect we can do without, at least if the new editor is going to be a light weight fallback for tinymce.

no need for license file and README file (readme useful information should be in the UI for the admin that sometimes can not check the server files)
lang/en/editor_contenteditable.php:

comment about tinymce
lib/editor/contenteditable/lib.php:

supports_repositories(): set to false but it looks it works (weird)

no need to have head_setup() or call parent function - the method is not abstract, so some content could be added.

some /* ...code... */

remove all code from $context=... to $langrev=... as the three variables instancied are not used

you might rename open_browser() in open_filepicker ()

remove console.log();

Well done Damyon, it's some pretty clean and structured js.

Note: it does miss a lot of features. At the moment it's mainly cool for phone as on phone the user is likely to do less than on a desktop (my assumption). Would it be useful to have in the administration a way to order the editor for phone only? I totally can see people asking for all tinymce features to be integrated into this editor and then we'll end up with two tinymce... I'm a bit worry about the situation. Maybe the solution is in fact to make a phone editor that is only displayed on phone, and in this case I think the issue deserve a bit more time in the specification/mockup/usability tests phase.

Jérôme Mouneyrac
added a comment - 15/Aug/13 8:18 AM - edited Andrew reviewed the UI/usability, I'll just comment about the code.
Previously said to Damyon, some minor comments:
no need for license file and README file (readme useful information should be in the UI for the admin that sometimes can not check the server files)
lang/en/editor_contenteditable.php:
comment about tinymce
lib/editor/contenteditable/lib.php:
supports_repositories(): set to false but it looks it works (weird)
no need to have head_setup() or call parent function - the method is not abstract, so some content could be added.
some /* ...code... */
remove all code from $context=... to $langrev=... as the three variables instancied are not used
you might rename open_browser() in open_filepicker ( )
remove console.log();
Well done Damyon, it's some pretty clean and structured js.
Note: it does miss a lot of features. At the moment it's mainly cool for phone as on phone the user is likely to do less than on a desktop (my assumption). Would it be useful to have in the administration a way to order the editor for phone only? I totally can see people asking for all tinymce features to be integrated into this editor and then we'll end up with two tinymce... I'm a bit worry about the situation. Maybe the solution is in fact to make a phone editor that is only displayed on phone, and in this case I think the issue deserve a bit more time in the specification/mockup/usability tests phase.

Damyon Wiese
added a comment - 16/Aug/13 4:02 AM Thanks for the reviews.
So we can get more people to comment on and work on this I'll fix the code related issues so we can get this version integrated and create new issues for any changes to the functionality.

Damyon Wiese
added a comment - 16/Aug/13 7:12 AM Pushed a new branch with these fixes:
Remove license and readme
Remove unused and commented code
Add missing phpdocs
Make enabled by default
Allow making images links
Lets you edit existing links
Added doc comments + licenses to all
It looks in pretty good shape now - I'll create some new issues for the functionality changes listed above so we can discuss them.

Martin Dougiamas
added a comment - 19/Aug/13 2:18 AM Damyon can you come up with a new unique name for your editor? (Whatever you like)
I feel HTML5 or contenteditable are too generic (you can't google for this editor currently).

The use of the @author phpdocs tag. This was mentioned IRL in the office last week and it has brought it into my mind. A lot of these phpdocs tags were discussed in the documentation sprint (which took place just before I started for HQ) and as its not mentioned in the coding guidelines I believe it is intentionally not used. I think we rely on the git history for that. And in fact, I think that Martin intentionally prefered the copyright attribution to be distributed (hehe, I shouldn't speculate on something like that that). Also, you're doing it inconsistently across the files.

Dan Poltawski
added a comment - 19/Aug/13 2:42 AM - edited Hi Damyon,
In addition to the comments from martin and cibot:
The use of the @author phpdocs tag. This was mentioned IRL in the office last week and it has brought it into my mind. A lot of these phpdocs tags were discussed in the documentation sprint (which took place just before I started for HQ) and as its not mentioned in the coding guidelines I believe it is intentionally not used. I think we rely on the git history for that. And in fact, I think that Martin intentionally prefered the copyright attribution to be distributed (hehe, I shouldn't speculate on something like that that). Also, you're doing it inconsistently across the files.
Misleading comment:
//== Custom Moodle strings that are not part of upstream TinyMCE ==
Different naming:
// YUI text editor integration.
Trailing whitespace in lib/editor/contenteditable/lib.php

Damyon Wiese
added a comment - 19/Aug/13 2:22 PM Renamed the editor - I squashed the commits because of the rename (it didn't make sense in the history).
All codechecker and moodlecheck warnings and errors are fixed.
All copyright/license tags are consistent and author tags removed.

In my IE10 it doesn't look to be working properly. The box is too small and I can't edit in it (attached screenshot)

Which raised a question - is this going to work fine in older verisons of IE? (Despite wanting to get rid of browser sniffing, i'm wondering if there is a case for falling back to tinymce for some compatibility)

Dan Poltawski
added a comment - 26/Aug/13 3:14 AM - edited Hi Damyon,
In my IE10 it doesn't look to be working properly. The box is too small and I can't edit in it (attached screenshot)
Which raised a question - is this going to work fine in older verisons of IE? (Despite wanting to get rid of browser sniffing, i'm wondering if there is a case for falling back to tinymce for some compatibility)
Trivial: get_init_params() has a couple of unused globals

Damyon Wiese
added a comment - 26/Aug/13 3:20 AM Thanks Dan,
I'll check it in ie 10 - I have tested it in ie 7, 8 and 9 and it works fine (ie was actually one of the first browsers to support this).
I'll add a fix the unused globals.

A fix for some dodgy bootstrap styles that were affecting the div for this editor. I could not actually trace them because ie dev tools don't let you inspect a generated page element and it only affects ie. Instead I set them explicitly on the div based on the values from the text area. This makes sense anyway - themers style the plain text area and the styles will affect the content editable div.

A fix for the headings menu not appearing in the right place. This was due to a bug in M.core.dialogue.

Damyon Wiese
added a comment - 26/Aug/13 2:23 PM I repushed the branch with:
The unused globals removed - I squashed this into the main commit.
A fix for some dodgy bootstrap styles that were affecting the div for this editor. I could not actually trace them because ie dev tools don't let you inspect a generated page element and it only affects ie. Instead I set them explicitly on the div based on the values from the text area. This makes sense anyway - themers style the plain text area and the styles will affect the content editable div.
A fix for the headings menu not appearing in the right place. This was due to a bug in M.core.dialogue.
It's also rebased on integration.

Damyon Wiese
added a comment - 27/Aug/13 1:41 PM For Dan,
I have just pushed a branch with 2 fixes on it.
Fix 1 is to enable atto by default on upgrades.
Fix 2 is for a display issue on firefox (that I had fixed before but had lost that commit on this branch).
The branch is MDL-41098 -master-fix1 - can you pull this in Dan? Feel free to tell me to add the upgrade code in a new issue.
Thanks

Rajesh Taneja
added a comment - 28/Aug/13 5:32 AM Thanks for fixing this Damyon,
In addition to linked subtask, problem I found were:
Border style added to blockquote in Firefox and IE
To add block in ie, user needs to select text, else it doesn't work.
In ie, blockquotes with number or bullet option doesn't behave similar to other browsers
Rest all look great, thanks for working on this.
Passing this and will open another issue.

In addition to above, it might be nice to consider fixing keyboard navigation. Tabbing from previous field to Atto takes user though each icon.
Also, title menu stays open, even if user focus/click on any other part of moodle. Seems like we can auto close on focus change.

Rajesh Taneja
added a comment - 28/Aug/13 5:53 AM In addition to above, it might be nice to consider fixing keyboard navigation. Tabbing from previous field to Atto takes user though each icon.
Also, title menu stays open, even if user focus/click on any other part of moodle. Seems like we can auto close on focus change.

Damyon Wiese
added a comment - 30/Aug/13 2:54 AM There was a young man named McGee
Who thought squashing bugs was easy
He tried it one day
And to his dismay
The bug guts made his keyboard all greasy
Thanks!
This has issue has been fixed and released in Moodle.

Martin Dougiamas
added a comment - 21/Oct/13 9:07 AM Just a note that I've decided we need to pull this back out from 2.6, much as I love the editor and Damo.
I think adding it as a second core alternative would:
confuse users with two things that are quite similar, yet different.
create more workload for FRONTEND to maintain it because people WILL be filing bugs for it.
create more ongoing workload for authors of plugin editors.
mess with training and documentation all over the place
We need to revisit this again in 2.7 in the context of a complete replacement/upgrade of TinyMCE3.