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 &nbsp; 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 &nbsp; 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 &nbsp; there

  • Set NOWYSIWYG = 0


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

-- PaulHarvey - 17 Feb 2012
Topic revision: r2 - 17 Feb 2012, PaulHarvey - This page was cached on 17 Aug 2019 - 19:14.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy