Skip to end of metadata
Go to start of metadata

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.

rationale

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.

Rationale

It's very hard to support content editors as they most often input in visual, while things are easier to fix from HTML. also, more importaint, if small javascripts / flash movies / iframes etc. are used in content, the visual editor will most often destroy these.

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:

http://www.google.com/search?q=tinymce+paste+from+word

Possible ways to solve this

The end result should be

  1. only two editor choices, plain HTML or visual
  2. not have the visual editor conflict with the plain html editor = never lose or transform content just because content creators use different editors.
  3. 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.

Solution

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.

Possible issues

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

see also http://www.google.com/search?q=php+strip+html

----------------------------

Older links and discussions

  • No labels

6 Comments

  1. re: the spec now says that "HTML editing does not convert newlines to BRs". this is solved in Wordpress. single newlines are converted to BRs and double to P. you can have single newlines / BRs within Ps. Triple+ newlines are (I believe) changed back to double / paragraphs again.

    I am not good at reading code but I believe you will find the function(s) used to do this by examining the file wordpress/wp-admin/post.php (download from http://wordpress.org/download/ ir view trac http://trac.wordpress.org/browser/trunk or ask developers in the forums: http://wordpress.org/support/ or at irc.freenode.net #wordpress).

    you will also find the javascript used to manage the quicktags to (marked) content by examining that file in Wordpress.

  2. We are using TinyMCE because we were able to work with them to develop an authoring tool that is both accessible, and generates accessible content. I do not know how Wordpress is in this respect, but it is unlikely we would change editors. We might perhaps provide wordpress as an option, though there isn't really any motivation for us to provide that option.

    Also we would prefer to  not to make our own ustomizations to third party applications, but rather have the developers themselves make the adjustment.  Making such customizations make upgrading more difficult if we have to make our customization with each upgrade. The best approach would be to contact the TinyMCE developers and suggest  to them the changes.

  3. You misunderstand.

    Wordpress is not an editor, and is not ment to (or can) replace TinyMCE in any way. Wordpress is however blogware / a CMS that uses both TinyMCE and a plain HTML editor, just like Atutor. the difference is that they have resolved the issues Atutor has with these editors. It's only a matter of some PHP and some javascript.

    In other words, you could check out how Wordpress has resolved the following issues:

    • making TinyMCE and the HTML editor validate / close tags when you save. This is perhaps not even an issue in Atutor?
    • making Quicklinks work in the HTML editor (very small javascript issue)
    • making newlines convert to BRs in the HTML editor, as Joel says it cant.

    and then, getting rid of the plain text editor option in Atutor..

  4. Okay. I understand now. We'll add it to the list of things to investigate

  5. I do not think we can get rid of the plain text editor just yet. Despite TinyMCE being built to be accessible, it is only accessible to those with relatively current screen reader. When WCAG 2 finally arrives, we can reconsider it then.

    For now we could combine html and visual editors to just "HTML editor". Users can edit the HTML markup directly through the view source feature in Tiny.

  6. I believe you can, but don't know how. I have been a heavy Wordpress user for many years and these problems are infact solved. I will try to digg deeper into it myself and post more information here.

    the plain text editor is what we (or, I) wish to remove, not the different HTML modes.

    (BTW: editing HTML source through the view source feature in Tiny has caused me many problems earlier..)