Hi All,
As work on 2.7 has just entered the planning phase, I would like to get feed back on what you would like to see in the implementation of TinyMCE 4.
The specification is still in progress: http://docs.moodle.org/dev/TinyMCE4
Please post any feedback or ideas here.
I have just received clarification that TinyMCE 4 is one of the optoins we are looking at, and there are many. I will bve taking recommendations and suggestions from the community over the next few weeks, weighing them up and then presenting a tally of the editors considered.
The spec for this project is now at http://docs.moodle.org/dev/Editor_2.7
Where did the scores come from? Are they just subjective, or is there some methodology behind how they are derived.
Do you think all the Considerations should receive equal weight, or do you plan to weight them somehow? (Is a weighted sum of scores really a valid way to combine different considerations?)
Is it credible that Moodle HQ, who build Atto, are rating it far better than the competition? It is well known that parents always think that their baby is far more beautiful and intelligent than anyone else's. In this case HQ seem to be saying that their baby is more capable than some much older children who have spent years in school. Extraordinary claims require extraordinary evidence.
There is a very good article by Joel Spolsky: In Defense of Not-Invented-Here Syndrome
The main gist of the article is: If it's a core business function -- do it yourself, no matter what.
The HTML editor is one of the major places where instructors generate content, but is it a "core business function"? The activities and resources are the heart of Moodle.
How does the HTML editor relate in respect to those elements? I would say very highly, but that's just my opinion.
You're correct David, and I have collapsed them in to one, without really thinking through what they mean for the editor. I've rescaled Atto in that category, because there will be more work for the Moodle team to maintain it for testing, documentation, etc.
Yes, the scores are purely subjective and are probably biased in favour of Atto, but to be honest, I am currently liking CKEditor, and would prefer that over the rest of them.
The table and scores are just a starting point, where I have jotted down my first impressions. I posted this here to get feedback like this - although I was hoping more for suggestions about how the weighting should be balanced rather than just questions about it and reprimands for being "a proud parent" (however well deserved it is).
correct URL is http://www.tinymce.com/tryit/basic.php
Joseph
I just have two text areas in a plain HTML page, one loading TinyMCE4 the other loading CKEditor - there has been no integration of these editors in to Moodle yet, I am just evaluating them both externally at this point.
TinyMCE takes about 1 second longer to load that CKEditor does - longer if I clear the cache on my browser.
As for TinyMCE3 taking so long to load, there are a few reasons for that - the string conversion for Moodle's AMOS lang files, the inclusion of the filepicker in the TinyMCE dialogs, and the external plugins that were written for TinyMCE to make it better for Moodle.
You mean HQ developers have not integrated these editors yet...
If it helps Didier Belot integrated CKEditor 3.5 to moodle 2 about 3 years ago already https://github.com/electrolinux/moodle-ckeditor. I would be happy to see all these 3 editors available as optional text editor plugins in moodle 2.7 or some future version.
I tested TinyMCE 4 with moodle 2.6 some weeks ago and I did not see any gaps in loading times - moodle itself causes some slowness in different database queries, translation etc like you said but editor files seem to be loading fast. The main difficulty I had with Tinymce 4 was launching file browser ( I could not make file browser launch with that yui module code ) and translation method of strings has changed from tinymce 3 to tinymce 4 which may be the main challange.
Some notes about http://docs.moodle.org/dev/Editor_2.7 :
TinyMCE 4 does support inline editing like CKEditor and Atto http://www.tinymce.com/tryit/inline.php
Keyboard accessibility of TinyMCE 4: Did you try for example ALT F9 - ESC - ALT F10 - ESC - ALT F11 ...
Plugin support - can our community write plugins easily? TinyMCE and CKEditor have large communities and documentation about different features and modifications in http://www.tinymce.com/wiki.php and http://ckeditor.com/about - I have personally tried writing some plugins both for TinyMCE 3/4 and CKEditor but not yet for Atto because I don't know the plugin structure of Atto well enough (any docs anywhere?)
Atto uses YUI for it's plugins, which is why I gave it the extra point over the others. That is all.
That wasn't what I meant by inline editing - I meant swapping between WYSIWYG and HTML source mode without launching a new dialogue. I know JCE (TinyMCE for Joomla) did it at one point, but I haven't seen it in TinyMCE itself
To the question about TinyMCE 4 menus: "Can the menu visibility be toggled?"
Yes.
You can set menubar to false in Tinymce 4 init code. You can also select what is shown in TinyMCE 4 menubar and where:
http://www.tinymce.com/wiki.php/Configuration:menubar
http://www.tinymce.com/wiki.php/Configuration:menu
The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5.8, which is now unsupported.
Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
TinyMCE version 3.5.8 is about 1 year old now but Moxiecode continues supporting and backporting most bug fixes also to 3.x from 4.x packages. From 3.5.10 changelog.txt
Version 3.5.10 (2013-10-24)
Fixed bug where dialogs using inlinepopups plugin would display incorrectly sometimes
Fixed bug in paste plugin word import that was removing type from lists
Fixed bug where IE 11 wouldn't be properly detected if IE 10 emulation was enabled.
Version 3.5.9 (2013-10-10)
Added IE 11 compatibility. IE 11 is treated as Gecko but it has still many IE bugs.
Fixed bug where importing CSS classes would fail if it contained @import rules to remote domain on Gecko.
Fixed bug in spelling plugin where misspelt words are not always marked.
Fixed bug where script tag was removed when nested inside a div or p.
Fixed full screen plugin state migration from original editor.
Fixed edgecase on up/down arrow keys scrolling with native lists.
Fixed bug where space can scroll webpage when using keyboard to access toolbar buttons.
Fixed bug where up/down arrow keys scroll entire webpage when using keyboard nav in menu ui.
Fixed bug where applying ins/del as inline elements would apply them as blocks.
Fixed bug where backspace on a space after an image would produce a BR on WebKit.
Fixed bug where it wasn't possible to change block type of text blocks.
One of the most important things in editor integrations is that version upgrading should require minimal effort - custom hacks make upgrading and bug fixing more difficult.
One typical example about these "unexpected problems" is the latest IE11 and bugs like MDL-42907
Are there any plans for upgrading tinymce 3.5.8 to tinymce 3.5.10 (or coming 3.5.11?) or does "unsupported" here mean that 3.5.8 is the last version of tinyMCE 3.x supported by HQ ?
About Dragmath plugin and other possible plugins for mathematics, physics, etc:
I suppose it's not difficult to create a dragmath plugin for Atto or any other editor - you only need to create the object (or originally applet) tags with id 'dragmath', give codebase and java parameters and call document.getElementById('dragmath').getMathExpression();
Applet returns the expression and insert it to editor with some proper function (or cancel).
Is it the best tool available? Probably not, but tools like Wiris are not open source (only Wiris plugin is but to be able to use it in a long term you need a valid license).
CKEditor 4.3 has a cute widget based plugin http://ckeditor.com/addon/mathjax that has a demo in http://ckeditor.com/demo#widgets and I have tested it in my local moodle 2.5.3 test install. It can be used together with mathJax javascripts in additional html or themes without any major problems - and those mathematical formulas inside spans can be re-edited - but this kind of plugins require that you need to know the syntax of LaTeX (or exactly those LaTex commands that MathJax supports - see http://docs.mathjax.org/en/latest/tex.html#supported-latex-commands ) and for most users LaTex is not easy or user-friendly at all...
By the way, this is not at all true:
Requires tex filter to be enabled globally
Dragmath plugin is using MoodleTex output format but you can use any latex renderer with double dollars (or other delimiters) - for example MathJax. Furthermore Dragmath has several output formats and you can create new ones: Maple, Latex, MathML, Maxima, AsciiMathML ,...
Marc Grober was arguing with Petr S about this setting of tinymce equation editor some years ago. Luckily Petr gave up and added the setting to TinyMCE in moodle 2.
The OU uses a similar TinyMCE plugin for maths input (that we wrote), with our own filter for rendering maths (it can either display as an image, or embed MathML in the page). So, Like that CKeditor example, but with a small delay to contact the server to render the equation.
I have obviously not been paying much attention, but I still have to wonder why DragMath is not visible in the editor in the Moodle forums? Are we still fighting over the issue of whether it is appropriate to use Math in Moodle? I would have to argue that Math would appear to be at least as important as emoticons, lol, but as I write these words it appears very easy for me to add an emoticon but not so easy to enter any Maths.... go figure....
I have been tied up on several other projects and have not been following forums lately, but I have to agree with Marc. It seems that teaching Maths on Moodle is very low priority.
I pointed out this issue in the Moodle Sites forum (https://moodle.org/mod/forum/discuss.php?d=244488#p1060128 should be the link) and Helen responded that she turned TeX filter on in Math forum alone. I responded that I thought that inadequate, but there you go.... you can have your say on the matter in that forum. The upshot is that all TeX is now orphaned except TeX in that forum, so $$$$ is just another emoticon with money on its mind, lol, and though we have the opp through MathJax to be able to now do inline as well as display TeX, that is apparently nothing that has crossed the minds of those in charge ...
$$x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}$$
Thats something about community policy on the site, and is totally off topic for this post - we are here to discuss the new editor options, choices and preferences.
Damyon,
could you also send a link or note here once we can test the filter and Atto plugin... so far we have been using Mathjax mostly with Additional HTML (site wide configuration) or in 1.9.x with theme files and if people are able to use MathJax through filter (enabled only if needed) and with different configuration options - settings - it's a huge advantage.
For example our current production site is using mhchem extension for chemistry and double dollars for inlineMath with
<script type="text/x-mathjax-config">
MathJax.Hub.Config({<br /> MMLorHTML: { prefer: "HTML" },
"HTML-CSS": {scale: 120},
TeX: {extensions: ["mhchem.js"]},
tex2jax: {displayMath: [ ['@d','@d'] ], <span style="color:#ff0000;"> inlineMath: [ ['$$','$$'] ]</span> }
});
</script>
<script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"></script>
and the latest MathJax 2.3 has some new interesting features like web fonts STIX, Asana Math, Neo Euler, Gyre Pagella, Gyre Termes, and Latin Modern so the ability to change configuration could be handy
I experimented with writing a filter myself for MathJax some time ago, and tried the one at https://github.com/damyon/moodle-editor_atto. Damyon's filter does not seem to be be context sensitive to me, although one certainly could make a filter that were. It just seems like a quick way to allow an admin to install MathJax without messing with configuration options.
The problem with using a filter that I found was that you are limited to placing it in the footer where this plugin seems to place it, or you have to run the filter on the header. Both methods have a performance cost.
On my production site, I instead configure MathJax contextually by calling MathJax in the theme header with the delayStartupUntil=configured option and placing the configuration in a HTML block. This seems like a much better option to me, and works well.
I did not find the link to the atto MathJax plugin, but would be interested in looking at it.
Might be here https://github.com/phalacee/editor27
Thank you Mauno, I found the editor plugin and tested it. It was not what I was expecting. It appears to me to be latex preview mechanism incorporated into the text editor, but at least at the moment the author has to have some familiarity with latex to use it. There is a latex library link that appears to be available to insert standard forms into the window. This is not a bad idea, and maybe a nice addition to the support that we have in TinyMCE. It is a little annoying to type a latex expression and save and display the page only to see that it does not display as one expected.
I agree it does not seem that Jason and Damyon completely understand the scope of the problem with mathematics notation and all the competing issues. The focus seems to be mainly accessibility. There is a need for ease of use for learners to be able to produce simple expressions correctly with the editor. There is also need for more advanced capabilities for teachers and advanced students to have a wider range of tools like full latex support and the ability to include other graphical tools in the editor. Dragmath is not just a graphical renderer, but was put together to fill a specific educational purpose.
That being said, I like the concept of the atto editor. Using a complete graphical editor from outside projects like TinyMCE brings with it some overhead and restricts what you might do without breaking something. The YUI library itself contains most of the functions you really need for a functional editor. I think atto is really just a grapical front end for YUI, and has the advantage the many moodle developers are familiar with it. From what I can tell it is probably easier or at least more consistent to make a atto plugin.
I have been playing around with making a YUI/MathJax based editor similar to Dragmath. I will try to see if I can get it to work with atto.
Mauno
Thanks for the note about the mhchem extension for MathJax as I had been looking for a way to handle Chemistry equations in Moodle for a while.
I also stumbled across a MathJax filter for Moodle by Ray Wainman of Oohoo.biz on GitHub
https://github.com/oohoo/moodle-filter_mathjax
There is also TinyMCE equation editor that works with MathJax that could, perhaps, provide a (non-Java) alternative to DragMath
https://github.com/oohoo/moodle-tinymce_matheditor
From a quick test, seems to be working on Moodle 2.7
Geoffrey,
that's exactly what is missing from the old open source equation editor integrations.
I think we have now all the required components to make a functional javascript based plugin if we combine the elements of CKEDitor's MathJax widget plugin
and
the elements of Mathquil based MathJax plugin by Ray Wainman and change it to use mathJax inside editor content area instead of mathtex images
The only problem might be that core developers don't like jQuery in Mathquil but they are probably going to translate MathQuil to YUI javascripts in the future anyway
Mauno
Sounds like a plan!
Makes sense that MathJax (rather than MathTex) is used to display the equation within the editor, as well as in the Moodle page.
At the risk of stating the obvious, perhaps aim to get this first into the Modules and Plugins database, then Moodle core.
There is another MathFax filter, by Jonathon Fowler, at https://github.com/jonof/moodle-filter_mathjax. May be good to merge the best features.
Would also be good to add a Chemical formula editing GUI, to support mhchem.js
Obviously, a big thanks for the folks at Oohoo and MathQuill for making their contributions open-source.
This filter is a lot like the last two although it does slightly more. It asks for preferred sources for MathJaX instead of installing local copies. It also wraps all the content in a div with class filter-mathjax before prompting MathJax to retypeset. It still loads MathJax in footer.
I also notice that Damyon's math editor appears but fails to function with the last two filters.
It is not clear to me why a filter is needed at all. The editor module can load its own copy of mathjax whether or not MathJax or the TeX filter is used on the page.
None of these plugins are filters, but excuses for requiring a YUI module to do configuration. If they are really only about configuration the options ought to appear in the course or activity settings or in blocks or themes.
Understood.
None of these are filters per se, just a simple way to add MathJax to specific courses. Of course, it could be argued that Mathematical markup should be available to all courses.
However, they do provide a convenient drop-in replacement for the default TeX filter (which is a filter!). So, in the short-term, provide a way to encourage the wider use of MathJax and move development forward.
Yes agree that this method is in some sense easy. However, in this case I believe easy is the opposite of good. It is easy because admins and developers can be lazy at the cost of poor site performance. I have tried the "filters" and compared them with a similar installation configured with the recommended link in the header. The "filters" are noticeably slower at rendering math. Math appears formatted well before the blocks are finished with the standard config and after the page is loaded completely with the "filter".
I am not suggesting that every site needs MathJaX in every course. I don't have it enabled everywhere on my site. My point is there are better options for doing that. There is not any reason at all why MathJax or a javascript app using it should require the use of a php filter to use it. If the best option for performance is placing it in a theme, and you want to have it off in some courses, you can duplicate the theme and modify the header in on copy, and instructors can choose using course level theme selection.
A better solution would be change Moodle to allow user preferences to determine whether the TeX Filter, MathJax or nothing runs. A block could also be configured to achieve this.
Damon,
if your filter and Mathjax plugin for Atto are the ones in Jason's GIT I accidently found them yesterday and tested right away (and checked also what you have done with CKEditor and TinyMCE4...)
There is a long history behind different editor plugins and math renderers - have you read any of those discussions? Simplifying things is good but using accessibility as a reason to strip more advanced tools may not be the only way to go.
Have you considered fallbacks - if something like java or flash does not work in all mobiles, tablets or screen readers you can give different, more accessable tools for those devices or hide not-accessable tools in such devices.
I comment here shortly the latest mysterious statements (opinions?) in http://docs.moodle.org/dev/Editor_2.7 about Equation Editor
Math renderers, filters and editor plugins are 3 separate things. MathJax is a math renderer script that can be used to render different types of math output: a small subset of LaTex http://docs.mathjax.org/en/latest/tex.html#supported-latex-commands with some custom commands but also MathML, SVG, AsciiMathML output formats,... The code that math renderers output on pages of moodle can be accessible even if the tools that were used to create the notations were not.
MathJax can use several delimiters so it is not a problem if old notations used double dollars and new plugins use some other delimiters (CKEditor plugin) - no need to hack the plugin, just add the new delimiters to configuration of MathJax. On the other hand double dollars are not "reserved" for old tex filter syntax.
If a site has used tex filter with some distribution of LaTeX or TeX , let's say core Mimetex or TexLive, you can't claim that MathJax plugin of Atto is100% compatible with existing equations. It's simply not. There is no universal Latex - different distributions of Latex can render different kinds of things with different extensions and MathJax can render parts of those things + MathJax has many new features that old renderers did not have.
About "ugliness" of Dragmath or Java - it's your opinion, right?
You need to give these tools settings to allow site users select what and how they want to use their tools, not to suppose that all users need simlar tools with similar settings.
and see what Christian Perfect has done with NUMBAS
Jason,
can you explain how you have tested mobile support?
You have written:
CKEditor 4: Editor works well, the the dialogues don't
Atto: Editor works well, as do the dialogues it launches
TinyMCE 4: Editor works well, the the dialogues don't
TinyMCE 3.5: Very poor
Do you mean standalone editor, plugins, themes, apps,... certain mobile types, browsers, OS, features,... ???
For example http://ckeditor.com/support/faq/features#question8 tells "The latest version of Safari is actively supported. Earlier versions may have compatibility issues." and http://ckeditor.com/support/faq/features#question9 tells that
"CKEditor has good iPhone compatibility with minor issues related to platform limitations. CKEditor is currently disabled on Android devices due to irreparable compatibility issues. You can change CKEditor settings to accept any mobile environment (at your own risk) by modifying the core/env.js file, but you will not have the same experience as on desktop environments."
Windows phones like Nokia Lumia models don't open CKEditor at all but both TinyMCE 3.5.8 and TinyMCE 4 work without major problems in Lumia models...
I tested Atto on my moodle 2.6. test site and my Lumia 920 (Windows8 mobile/IE10) could not use any plugins of Atto - not even bold or italics - so I could only write text. Obviously Atto does not keep focus or selection and plugins do nothing. Here I am using the same mobile and can use most plugins - file browser is buggy on Windows phones and emoticon plugin does not always keep cursor location but I can do much more than just write text... I can test Samsung Galaxy tomorrow, from Lumia 920 Atto gets 1 point and TinyMCE 3.5.8 ... 6 points. Usually I hate writing on small touch screens - this requires too much scrolling and scaling...
On my daughter's Samsung Galaxy S4 mini running Android 4.2.2 (Jelly Bean) both Atto and TinyMCE 3.5.8 were usable but not user-friendly. File picker was loaded somewhere outside the screen and after lots of scrolling and scaling here and there I could finally pick some images and videos from repositories (Wikimedia & Youtube)
Equal points for Atto and TinyMCE 3.5.8 mobile support from our Samsung Galaxy S4 mini test - 7 points
I don't understand how you turned Atto's mobile support to good and TinyMCE 3.5.8 to very poor
The dialogues for Moodle (the ones used for Atto, but not the other editors) should (and do in my experience) open full screen on mobile devices, allowing them to be used easily. That was my justification.
Please note these are just my experiences. We have set up a demo site to get feed back from as many people as possible, and will be using THAT feedback to make our decisions.
With all respect, Jason, wouldn't it be good to post at least a link of YOUR demo site to the community that has used and tested different editors and plugins since moodle 1.0 - http://prototype.moodle.net/editor/
I did find the link from the bottom of http://docs.moodle.org/dev/Editor_2.7#Mock-Ups.2FPrototypes and tested quickly the first versions of integrations yesterday and using your testing instructions today. It is clear that none of these new editor integrations is production ready - they need proper administration of settings and some more documentation.
It is also clear that core does not need 3 clones of Atto ( Atto - CKAtto and TinyAtto 4 ) - all of these editors have some special features and some options missing...
One funny note - your project site has already switched the Legacy editor to Atto - omen?
With all respect Mauno, that link is not ready for everyone to be seeing yet, which is why it hasn't been posted. They aren't clones of Atto, they are editors modified to look like the new toolbar UI we have released in 2.6 - as can be seen here on the forums, with TinyMCE3. The legacy editor is TinyMCE3, not Atto.
The special features and options that are missing were removed to level the playing field, so that the editors evaluated are done so in a state that is as close to the current editor as possible. This was done to remove any biased based on extra features that aren't normally used, or decisions made on the appearance.
We will be announcing the survey and the prototypes soon, one or two days I would imagine. The reason it wasn't done sooner was that they were still in development up until Friday, and now we are getting the survey sorted so all the right questions are asked.
You're right, the editors do need more integration and better documentation before they are production ready. But the point of creating prototypes is not to produce production ready systems. Hence the state of these editors.
Testing mobile/tablet Support only with iPhones and iPads is like testing IE8 only http://www.digitalbuzzblog.com/infographic-2013-mobile-growth-statistics/
It is strange that CKEditor developers have not worked harder on Android and Windows mobile Support - and that You call CKEditor mobile support good when CKEditor shows only textarea on those devices...but that was the case also in (what you call poor) tinymce a year ago so hopefully yui and CKEditor developers have found some new tools next year
Oh dear - http://docs.moodle.org/dev/Editor_2.7 is having more and more odd comments:
Atto
Technical notes (lessons learned from the prototypes)
Code is high quality, it is quick to build new plugins. Uses YUI in plugins - so easy for Moodle developers to learn
How do people build new 3rd party Atto plugins when there are no docs about the file structure of Atto available?
Ships with a nice mathjax solution
What's the difference between writing mathjax directly to the editor content area vs using Atto plugin? Answer: Atto adds double dollars for your code.
Fully themable in a moodle theme (even icons)
Docs for necessary css?
TinyMCE 4
Technical notes (lessons learned from the prototypes)
Code is of average quality. It is hard to build new plugins, the documentation is lacking.
You just have not found the docs http://www.tinymce.com/wiki.php/Tutorials:Creating_a_plugin
We have drag math for equations but it sucks
Dragmath is not a part of TinyMCE 4 so what's the logic in this equation editor comparison? How many minutes does it actually take to make a simple Atto type math plugin to TinyMCE 4 if you think that it must replace dragmath plugin?
Skinning is hard and ugly. Requires yet another tool for building skins (jake)
What??? If you have not read the posts about tinymce 4 from moodle.org forums check http://skin.tinymce.com/ - isn't creating skins with Tinymce 4 skin creator easy enough?
You can use the presets or change css in a easy way and download the skin files to your local computer. Then you move the custom skin to your moodle site folder lib/editor/tinymcefour/skin and modify file lib/editor/tinymcefour/lib.php to change skin param
'skin' => 'charcoal',
until these integrations get some settings to administration of editors. Where do you need jake or less there??? File structure of a TinyMCE 4 skin looks like this:
We are talking about skinning everything to look like the other toolbars in Moodle. The Filepicker, the file manager, and the PDF annotation. So yes, Atto is easier to skin for that - it was designed to be.
We aren't talking about getting a skin off a site and installing that, we are talking about writing a skin from scratch. Compiling the less and minifying the JS uses jake, rather than recess and shifter. Both of these things count against it, which is what was stated in the text you quoted.
You've already indicated you are completely biased towards TinyMCE4, and against CK Editor and Atto, we get that.
We (Damyon and I) are doing this whole design, test, feedback process with an open mind and recording our experiences. Then we will evaluate the feedback we get.
We did find the documentation for the plugins for TinyMCE4. and the documentation is lacking, in comparison to CK Editor (the TinyMCE4 docs are great compared to Atto's, which we will write if it is the chosen editor -- no point in wasting the time and effort for something that might not progress past prototyping).
Our comments against TinyMCE and in favour of Atto of CK Editor are not personal towards you or anyone else, but your responses to them seem slightly hostile or aggressive. That isn't helping this discussion at all.
I am not against Atto or against CKEditor or any other editor - I just don't understand such comments that are not true or try to make one editor better than another with statements that are actually just opinions or misunderstandings. I have tried to point out those "peculiar" statements in your project docs - nothing else.
I was testing a couple of years ago (F)CKEditor, TinyMCE, Xinha and YUIRTE with moodle 1.6-1.9 when moodle had HTMLArea and later different plugins for moodle 2.x and TinyMCE is not actually my favourite, I just know it better than these others - or Atto that I know worse than any of these other editors.
If you don't want to listen (read) my comments it's ok. If you feel that my comments are somehow hostile or aggressive it's ok too - I am really sorry if you feel that way. I am also happy to see your editor project going on because it is going to benefit all moodlers.
Atto may be EXCELLENT even if it's not perfect and TinyMCE & CKEDitor are the most famous open source editors but they are not perfect like we all know. If you rant dragmath you probably don't know how difficult writing maths on www actually is - there are no good open source tools for this purpose available. Wiris is pretty good but it's a commercial product and many teachers use external (commercial) tools like Mathtype the create the notations and copy/paste them to moodle. Writing maths online is a future challange - but it's not really moodle's (core developers) fault that there are no good tools available for this...
Of course, "other toolbars in Moodle" in Moodle do not necessarily have one "look". I assume what you really mean is that you plan to make it easy for a theme developer to style all the toolbars in a Moodle site to look like how the theme developer wants them to look in that theme.
Jason,
I think I am too old to talk about writing a skin from scratch or compiling the less and minifying the JS with jake, rather than recess and shifter. In the past we used simple text editors to write html, css or javascript and were happy with the results
<rant>
Nowadays you can't use normal css and javascript in moodle anymore - you need to use those yui tools to minify a small piece of code - but at the same time all icons need to be changed to separate pngs and svgs. Old tinyMCE 2 was using separate icons, TinyMCE 3 started to use a sprite for core icons and TinyMCE 4 started to use icon fonts.
Then somebody in moodleland got an idea to change sprite based TinyMCE 3 skin of moodle look more like TinyMCE 4 but not with the new icon font method - all icons had to be grey "moodle style" images - you know, cache takes care about loading images fast so it does not matter if there are 30 different icons... And now suddenly this grey (disabled) style is a new standard and we need to skin everything to look like the other toolbars in Moodle. So yes, Atto is easier to skin for that - it was designed to be...
</rant>
Attached screenshot is from icoMoon app showing beautiful moodle style icons from Atto and under them "ugly" tinymce 4 svg font icons
By the way - and this is not ranting, I am not angry or agressive - you could test image and media plugin in Atto with the latest Internet Explorer 11. Atto has a tiny bug in IE11 and when you add images or media files they simply vanish from html.
Regarding the IE11 bug, none of the editor developers (Damyon and I) have IE11 available to us at the moment, but we will make sure it is tested before any of these editors make it in to core.
Great!
And I promise to stop ranting now...
In fact it might be best for all to change core editor to a minimal version of Atto and explain ordinary people how to create plugins for it.
If you could offer at the same time a functional base integration of TinyMCE 3 & 4 & CKEditor 4 in downloadable plugins and somebody could upgrade the base versions occasionally most people might be happy.
Web maths is going towards apps like https://www.desmos.com/calculator or http://geogebraweb.appspot.com/app.html or http://webdemo.visionobjects.com anyway and this kind of apps won't find their way to core moodle so building custom plugins to custom editors and sharing them to community is an easier route than arguing about proper yui js/css minifying tools.
Mauno,
Thanks for your rant. Because the built-in editors are yanking things out that I purposefully and thoughtfully added (css inside style tags instead of inside tags and limited javascript), I have taken to using the standard editor rather than Tiny MCE. It works like notepad inside moodle. Works much better than all these fancy editors and I get exactly what I want.
Doug
With respect I don't think the File Picker, File Manager are a good benchmark. If anything I would argue the longer term aim should be to move the rest of Moodle over to a font based solution allowing easy styling reducing the need to write a skin from scratch along the lines of:
I think that is something many Moodlers could and would use, at a later point it could be configurable through the admin interface.
I think the number of people wanting or needing to write a skin from scratch would be very small by comparison.
I see the use of fonts in Tiny MCE is a "Con" yet the use of fonts as an alternative to icons is something theme developers are pushing for.
There is more than one thread and more than one tracker discussion on this topic, on that basis I would suggest there are at least some who would consider use use of / option to use fonts a "Pro".
Well, the editor plugin API was released in Moodle 2.4. That encouraged people to write TinyMCE plugins.
So I think it would be a bit disappointing to drop TinyMCE in favor of something else without a really good reason.
On the Moodle plugins directory there are now 3 TinyMCE plugins. Two of those are by me, and a third one is underway. But I know for a fact that institutions have been developing their own plugins for in house use too.
I know is possible to have X , Y and Z editors available but my vote is for TinyMCE remaining the default editor. No objections to TinyMCE 4, as long as we can still develop add-ons for it.
My humble vote for Tiny as default editor. It's configurable, we have been working with it for a long time and I see no reason to drop it. It's great to have alternative editors, but I guess most users will appreciate to have Tiny as the default one.
Good point, We have at least one ou-specific TiyMCE add-on.
However, while this factor should be taken into account as ad additional cost for deciding to move away from TinyMCE, moving may still be the best decision. In which case we need good documentation for how to write a 'neweditor' add-on that does the same thing as your TinyMCE add-on. Someone at Moodle HQ would have half-a-dozen to convert, and by the time they have done that, they should be well placed to explain it to the rest of us.
Even if you enable the compat3x plugin that allows TinyMCE 3 plugins to be used in TinyMCE 4 - the plugins that ship with Moodle still need to be altered to get them to work 100%. I would guess the same is true for non-core TinyMCE plugins.
Swapping to anything will require work for plugin maintainers.
I see you just added 'Must by styled with LESS' to the requirements, but I am not sure that is really needed.
Any HTML editor will be styled using CSS. LESS is a good way to compile the required CSS in a product as big and complex as Moodle, but I am not sure that requires anything particular from the editor. Isn't this about the same as saying that the editor code must be editing using VIM?
Another way to look at it is that TinyMCE is themeable. So, we can make a Moodle theme if we want. (Actually, that is a good point, for all the style changes in 2.6, was that done as a Moodle TinyMCE theme (so it is easy to switch pack if someone wanted to), or did we just hack to death the standard TinyMCE theme?
The latest hacks to tinymce 3.5.8 in moodle 2.6 did not break old skins otherwise but custom plugins need a little extra css to custom skins to hide and override new gray icons.
This part of http://docs.moodle.org/dev/Editor_2.7 is really amusing:
TinyMCE 4
Pros:
Uses LESS for style sheets
Cons:
Uses LESS for style sheets
Uses fonts for icons
Like Tim said editors don't need LESS but editor skins can use LESS if skin creators want to use LESS in their editor (skin/theme) css. Or icon fonts. They are options, advantages that allow theme designers make editors fit better to their theme css. So if you have a bootstrap based theme it can use bootstrap based css in skin or if you use some other theme css tool set you can simply add that tool set to skin. That's the main reason why both CKEditor and TinyMCE have skins.
TinyMCE 4 has one default editor theme, modern, and it is using default skin called "lightgray". Nothing prevents moodle (HQ developers) creating different skin for TinyMCE 4 without icon font or with/without LESS. TinyMCE 3.5.8 has two default themes, advanced and simple, and current moodle 2.6 is using custom skin called moodle in advanced theme.
The icon font that TinyMCE 4 is using was made with Icomoon app in http://icomoon.io/ and all (svg) icons of moodle could be added a new font the same way. For people who are scared about icon font accessibility http://modernwebaccessibility.com/en/blog/demystify-speak-none
Yeah, We've noticed that, but LESS is both good and bad, and TinyMCE 4 uses jake instead of recess, so that's not optimal either.
We will be creating a new theme for TinyMCE leaving the lightgray one in place. But the mention of fonts (I've now expanded it) was more about the fact it uses icoMoon, so if someone has created a plugin that uses an icoMoon hosted icon, they won't be able to access that without an internet connection (some instances of Moodle are intranet only).
Jason, there must be some misunderstanding about icoMoon app - isn't it only a tool for creating icon fonts? You can import svg images to that app and create svg, eot, woff and ttf fonts including those icons. You can download those fonts to be a permanent part of skin (like lighgray skin has). You can select the name for your fonts and prefixes/postfixes/classes you want to use in your site css for those fonts - just like FontAwesome in bootstrap http://fontawesome.io/
Any plugin can use custom fonts in moodle 2.6 and with some extra code also in versions before 2.6, right?
I don't understand why people should use icomoon.io service to access fonts - surely you can use cdn for those published fonts like FontAwesome - but file size of 4 fonts including icons necessary for editor is abot 100kb...
Ah, I thought icoMoon supplied the font via a CDN for you. Obviously I was wrong about that. Thanks for the clarification.
I can't see anywhere that says it must be styled with LESS, and I certainly didn't add that at any point - I see it as a benefit, to a degree, but it's also a setback, as it makes it harder for casual alterations to the CSS.
2.6 changes were done as a Moodle skin for the Advanced theme on TinyMCE 3.5. The same will be done for TinyMCE 4 if we take that path.
Sorry, I posted in the Mathematic tools forum a message about equation editor in the future Moodle editor for 2.7 that surely would be more at its place here, but I was not aware of this forum thread when I wrote it.
Here is a link : https://moodle.org/mod/forum/discuss.php?d=244333#p1089887
I really hope Moodle HQ devs will listen more closely at knowledgeable people like Mauno and Marc in the future.
Contrary to what you are saying Jason, I don't think they are agressive, but but maybe they are a little tired of not having be heard for so many years that they try to improve math in Moodle .
And as Maths is supposed to be THE key subject (arguable) in schools all over the world, we should be able to do it better in computers than we do. I use the latex, dvips and convert options in the TeX Notation filter and for geometry, I draw stuff up in Photoshop and import as images. To get to the point where I can do those things was not easy, it would be better if it was done as native in Moodle.
But then, if you want to look at the entire question of Maths from a completely different view, look here.
For CKEditor, the equation editor is actually called MathJax, and while I know that is a renderer, someone outside the Moodleverse decided to call it that, so we are using the term they came up with for their plugin, to refer to their plugin.
We are all for the improvement of the Maths tools as part of the rebuild of the editor, we think it is pretty important, that is why our survey included some test steps covering the equation editor. We haven't tested them all yet, but we are actively looking at other equation editors, and have considered writing one that takes the best of all the options and merges them in to one.
Before that happens though, we need to decide on an editor to host the equation tool in. So we will focus on that first, then raise questions about the tools required for the maths tools. Please, don't panic, you aren't being pushed aside, we will make sure your voices are heard at the time they can do the most benefit to the project :D
Just while we are making comments about this. I notice that
http://docs.moodle.org/dev/Editor_2.7
lists Paintweb as a candidate for picture editor. I would add two other candidates.
I recently released PoodLL Anywhere for TinyMCE. That adds icons for audio / video recording, webcam snapshots and a whiteboard. There are three whiteboards available, the PoodLL whiteboard (flash only), drawingboard.js and Literally Canvas.
The PoodLL one is a bit of a dinosaur now, because its in Flash. The other two both have their merits. But really Literally Canvas would be my choice. It has support for shapes, and text and a good api . It also can save the drawing data , so that it would be possible to load it up in a different session and continue the drawing activity. It uses BSD license which , I think, is compatible with Moodle.
