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

Motivation

Editor Profiles

We need to support multiple editors, and multiple editor configurations.

• TinyMCE is a capable editor, but depending on the application, there are equally if not more appropriate alternatives out there. Current WysiwygPlugin contains quirks and work-arounds to deal with TinyMCE specifically. When we finally get around implementing alternative editors, we need a way to target these work-arounds to specific editors, instead of all editors all the time.
• Multipe editor configurations: It should be much easier than it is for users to add plugins and re-arrange the toolbar.
  • Toolbars/plugins: xattr buttons, wordcount plugin, Sven's ComponentEditPlugin
• WysiwygFormFields - need their own toolbar layout, plugin list, init params, etc.

Different layout/appearance and even deeper customisations of the INIT parameters to a given editor may be needed when it comes to implementing WysiwygFormFields: event callbacks, textarea selections, extra or different cleanup/validation parameters, etc

Content Policies

See WysiwygContentPolicies

TinyMCEPlugin offers some nice layout and formatting possibilities that cannot be translated into acceptable TML. We already know that it's generally better not to contaminate our topics with too much CSS and HTML. But sometimes, even if it's just on a specific topic or web, it is appropriate to stop crippling TinyMCE's output.

• Make it possible to increase strictness where necessary, Eg. always convert html tables to TML.
• Make it possible to relax strictness where necessary, Eg. class/style attributes.

Description and Documentation

Original work based on slightly modifying semantics of WYSIWYGPLUGIN_STICKYBITS can be found at rev 7. This proposal has been completely reworked.

Content Policies

Define named policies in LocalSite.cfg hashes under WysiwygPlugin. Users may select policies and tune them using topic preferences.

Four base profiles to start from:

• strict
  • No XHTML mark-up at all, except:
    • <del> (should SupportLineThroughFormatting convert <strike> and <s>?)
      • No attributes
    • <u>
      • No attributes
    • <blockquote>
      • No attributes
    • <img/>
      • src
      • alt
      • longdesc
      • align
      • style =
        
        • float: (right/left....)
      • width
      • height
        
• normal
  • Based on strict.
    • Goal: try to keep the topic free of HTML for most every day editing, but permit it for common cases where users have used the editor to apply some formatting or styling that can't be represented in strict. Don't want to allow everything, basically just what we have in the current 1.0.x WYSIWYG
  • Tables
    • Give up/fall back to HTML when the following can't be represented
      • alignment
      • width
      • border
      • Nested tables
  • Preserve attributes in some cases?
    • <div>
      • class
      • style
        • float: (right/left ...)
      • id
        
    • <span>
      • Colours
• full
  • Defined by the editor plugin, Eg. TinyMCEPlugin.
    Goal: a set of rules that would match the full capabilities of the default editor configuration. In other words: allow anything that's possible with the editor in its configured state. This might vary depending on what plugins are loaded into said editor, so this might require the editor plugin to "register" with WysiwygPlugin during init
• open
  • Lossless. Never strip/remove any markup.

Editor Profile

GeorgeClark has written about some room for improvement in our WysiwygPlugin/TinyMCEPlugin implementation in Tasks.Item2200.

Problem:

• WYSIWYGPLUGIN_STICKYBITS doesn't protect the editor from markup which it will corrupt or misbehave on; Eg. <center> tag passed in to TinyMCE is dropped in the output.
  • (EDITOR)_(UN)SUPPORTED_MARKUP (proposed new preference variable) should function as the definition of the markup which is acceptable to the editor in use.
• WYSIWYGPLUGIN_STICKYBITS needs to be easier to work with. Users should be able to only add to or override instead of replace the default STICKYBITS policy.
  • WYSIWYGPLUGIN_STICKYBITS should function as the definition of the markup which is considered acceptable in the topic content.

So create new preference variables...

Variable	Default	Description	Example
WYSIWYGPLUGIN_STICKYBITS	(no change)	Set by WYSIWYGPLUGIN_STICKYBITS_POLICY, unless WYSIWYGPLUGIN_STICKYBITS is set somewhere.	As per existing implementation
WYSIWYGPLUGIN_STICKYBITS_POLICY	normal	Selects a default WYSIWYGPLUGIN_STICKYBITS profile, to easily vary the tolerated level of HTML tag pollution for a given topic/web etc. strict: try to prevent any HTML tags entering the topic. normal: essentially our current default WYSIWYGPLUGIN_STICKYBITS, but some parts (eg DIV centering?) might deserve moving into the next policy... liberal: Enable as much of the feature set of the editor as possible, Eg. <div> centering, <p> indents, and so on. Probably, the liberal policy should be set by the editor. none: avoid stripping any HTML tags/attributes at all. Also it would be useful to have policy modifiers: stricttables: If added to a policy above, would strip all table markup to ensure pasting from Excel, MS-Word etc. will end up as TML tables.	normal,stricttables
WYSIWYGPLUGIN_STICKYBITS_TUNE		Override or add elements to WYSIWYGPLUGIN_STICKYBITS	P=align,style;BLOCKQUOTE=cite; (would override the attributes for P and BLOCKQUOTE elements only)
TINYMCEPLUGIN_SUPPORTED_MARKUP	TBD	Designed to protect the editor from markup sent via WysiwygPlugin that would otherwise be corrupted or cause misbehaviour. This is a whitelist of all acceptable markup in the style of the existing _STICKYBITS setting. This variable is overidden by _UNSUPPORTED_MARKUP(_TUNE).
TINYMCEPLUGIN_SUPPORTED_MARKUP_TUNE		Overrides parts of, or adds to the _SUPPORTED_MARKUP preference. It's intended that if users need to adjust _SUPPORTED_MARKUP, they should do it through this variable.	CITE=cite,id;
TINYMCEPLUGIN_UNSUPPORTED_MARKUP	TBD	Counterpart to _SUPPORTED_MARKUP, but this variable takes precedence. This is a blacklist of unacceptable tag/attribute combinations that the editor will mangle/crash/glitch with.
TINYMCEPLUGIN_UNSUPPORTED_MARKUP_TUNE		Overrides parts of, or adds to the _UNSUPPORTED_MARKUP preference. It's intended that if users need to adjust _UNSUPPORTED_MARKUP, they should do it through this variable.	DD=.*;NL=datetime;KBD=.*;TABLE=caption,summary;

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

WIBNIF TinyMCEPlugin could grey out buttons that won't have any lasting effect upon inspection of the WYSIWYGPLUGIN_STICKYBITS in force.

Discussion

• Copied from SupportBlockquoteAndIndenting
• Also see Tasks.Item2183 Unable to center text, and Tasks.Item2200 for comments on the documentation regarding STICKYBITS and WysiwygPlugin tuning.

---

-- PaulHarvey - 19 Nov 2009

GeorgeClark is developing these ideas over at Tasks.Item2200.

After reviewing that task, it seems this proposal is incomplete.

-- PaulHarvey - 19 Nov 2009

It's probably more appropriate to cover this in a feature proposal instead of a task. I committed documentation changes under the task, recording how the current settings actually work. Should we close it as a documentation update and continue with the feature work in this topic?

-- GeorgeClark - 20 Nov 2009

Yes. Updated the proposal.

Needs more specifics about how WysiwygPlugin is going to detect which editor is making tml2html calls, so that it can apply the correct _STICKYBITS_POLICY[liberal]/(UN)SUPPORTED_MARKUP policies.

-- PaulHarvey - 20 Nov 2009

Okay. Need to rework the proposal again. Productive discussion on IRC.

• The editor plugin making calls to tml2html needs to both identify itself, and set its "supported tags" (and attributes, attribute values) in LocalSite.cfg hash, which WysiwygPlugin can use.
• For conversion back html2tml, the STICKYBITS functionality - WysiwygPlugin needs to test a simple policy variable, WYSIWYGPLUGIN_POLICY, as described above. However, the policies themselves (tag/attribute/attribute values) should also be set in LocalSite.cfg hashes.

• Need to consider multiple formfields. POST to tml2html should contain new header fields, Eg:
  • X-FoswikiEditor: TinyMCEPlugin
  • X-FoswikiEditorPolicy: formfields

The important change in direction for this proposal will be a move away from configuring STICKYBITS as a user preference variable.

It seems no users tend to adjust this value, and the fact that the documentation has been neglected probably indicates that this move is a reasonable one.

-- PaulHarvey - 20 Nov 2009

I'm still thinking about this, but lack time to work on it.

-- PaulHarvey - 17 Feb 2012

Commenting is disabled while not logged in

• Set NOWYSIWYG = 0