Feature Proposal: Formalise TML/HTML conversion requirements on a per-editor basis

Motivation

TinyMCE already has some specific quirks coded into WysiwygPlugin. With alternative editors, we will need to have specific targeting of quirks and work-arounds in TML2HTML and HTML2TML. Eg.:

• TinyMCE has a habit of ending up with <p> wrapping all content in table cells where the return key has been pressed, and the P cannot be removed
  • However, it could be argued that a better work-around would be to write a javascript MCE plugin that hooks into the ForceBlocks object and checks that a <p> is being created unnecessarily (ie. parent node = <td>).
• Light-weight editors suitable for some applications of WYSIWYG formfields Eg. jwysiwyg cannot deal with some elements, eg. tables.
  • Although it could be argued that it's the wiki app developer's responsibility to ensure that the editor of choice has a content policy appropriately tuned to its capabilities.

Description

It might be necessary for WysiwygPlugin's HTML2TML and TML2HTML to provide call-backs so that some details can be taken care of in the EditorPlugin's code.

In general though it might just be a matter of providing a way for EditorPlugins to turn certain quirks and work-arounds on and off. Examples:

• Wrap all content in a <div>
• In TML2HTML, create a common div container around any TML table or list with any text that is on a line immediately before after (otherwise TMCE wraps stray text nodes in a <p>, which introduces unwanted newlines in HTML2TML). In HTML2TML, eat/flatten the inserted div.
• Ensure list items aren't null or only contain whitespace; replace with   instead

Implementation

Each quirk (call them requirements) should be named. Perhaps it can be named as a ItemNNNN topic name. But each should have a unique topic at foswiki.org, if not a ItemNNNN topic then a foswiki.org/Tasks/WysiwygRequirementName.

How's this:

• Tasks.Item2605 gets filed as a result of a bug. A new translation requirement is needed to solve it.
• Tasks.WysiwygNoEmptyListItems is created, which references Tasks.Item2605 and vice versa.
• NoEmptyListItems becomes a key in an options hash used by WysiwygPlugin (which will have to know which EditorPlugin is calling it so that it may lookup the appropriate preference for that editor)
• {EditorPlugin}{Requirements}{NoEmptyListItems} will itself be a hash of further key:value pairs, which may be necessary to provide editor agnostic work-arounds. For example let's assume empty/whitespace list items are a problem on all editors because Firefox is buggy. Let's pretend   isn't an appropriate solution across all editors. So it may be desirable to specify the dummy value to be used on a per-editor basis. For example:
  • {FckEditorPlugin}{Requirements}{NoEmptyListItems}{Enabled} => 1
  • {FckEditorPlugin}{Requirements}{NoEmptyListItems}{DummyValue} => '<!-- -->'
  • {TinyMCEPlugin}{Requirements}{NoEmptyListItems}{Enabled} => 1
  • TinyMCEPlugin doesn't specify a DummyValue, so maybe the NoEmptyListItems requirement will assume   there

• Set NOWYSIWYG = 0

---

I have different priorities now, and different ideas on how to solve this (FoswikiDOM). Parking.

-- PaulHarvey - 17 Feb 2012