Total Estimated Cost: $?? CDN - Contribute
Problem to be solved
Input editors should be iproved both to ease the creation and maintaining of course content for content producers, and to create better formatting options to users and thus better overall usability.
For content editing
Component of solution: remove plain text choice
- goes for all content + announcements
Merge the plain text editor choice with the plain HTML editor. Remove the plain text choice completely and add the filters from this one to the plain HTML editor. that is, make the plain HTML editor convert carriage returns and newlines to BR or P. 1 CR = 1 <br />, 2 CR = 1 <p>
Add a small filter that
- ignores several carriage returns / newlines, so 4 carriage returns will not produce more than one <p>
- ignores this conversion if the HTML the user inputs contains <br />-s and <p>-s allready.
The plain text editor only does one thing, which is converting newlines / CRs to HTML, and strips all other HTML. This should be done directly in the HTML editor. Having three choices in editors where the difference between two of them are almost indistinguisable is not neccessary.
In daily use this would mean that one could copy directly from Word documents to the plain HTML editor, lose the Word styling bu at the same time preserve the line breaks. Inexperienced users could then add additional formatting with the WYSIWYG editor.
Components of solution: Fix seamless switching between HTML mode and WYSIWYG mode
Currently, if inputting HTML in the plain HTML editor, and switching to WYSIWYG and back, this renders all the HTML to one big blob of text. That is, all line breaks in the HTML are removed, which makes it very difficult to work with the HTML again, and worse: renders inline scripts and applets useless, for instance scripts used to insert flash movies. see screenshot:
In addition, links are treated differently. this input in HTML mode: "/atutor/get.php?JKHDJKHKJKJH" are rendered to only "JKHDJKHKJKJH" after switching to visual and back, which sometimes renders these links unusable.
Components of solution: Add pasting from Word possibility to the TinyMCE tools
People are creating content in Word, and expect to be able to paste this into the visual editor, so we need to make that as good as possible. There are several plugins and hacks to TinyMCE that allows this, so it should be checked out which of them we could use:
Possible ways to solve this
The end result should be
- only two editor choices, plain HTML or visual
- not have the visual editor conflict with the plain html editor = never lose or transform content just because content creators use different editors.
- a possibility to paste from Word
as for # 2, most applications (for instance Wordpress and Drupal) have solved this today, but in slightly different ways. A good explanation on how Drupal does this, and why, is found here: http://www.lullabot.com/articles/drupal_input_formats_and_filters
Wordpress is similar, but does not have the same choice of filters, see http://codex.wordpress.org/How_WordPress_Processes_Post_Content and http://www.google.com/search?q=wordpress+content+filter
For user input
- this would go for all forum posts and messages, allthough it's most important for forums.
The formatting available to forum posts are not very usable, and has different lay out than the rest of the editors.
Remove the old formatting and include a stripped down profile of TinyMCE instead. The allowed HTML (and this corresponding editor buttons) should be: strong, em, ul, ol, li, a and a small selection of emoticons. In addition there should be a filter stripping out MS Word code.
This would allow for HTML as allowed input from users, which can be insecure. There are several tools in PHP to filter out all but the allowed HTML, for instance strip_tags: http://no.php.net/strip_tags