Feature Proposal: Implement a rational way for mere mortals to adjust the level of HTML contamination permitted into their topics
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
- 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.
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.
- 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
Description and Documentation
Original work based on slightly modifying semantics of
can be found at rev 7
. This proposal has been completely reworked.
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:
- No XHTML mark-up at all, except:
- 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
- Give up/fall back to HTML when the following can't be represented
- Nested tables
- Preserve attributes in some cases?
- 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
- Lossless. Never strip/remove any markup.
has written about some room for improvement in our WysiwygPlugin
/TinyMCEPlugin implementation in Tasks.Item2200
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...
could grey out buttons that won't have any lasting effect upon inspection of the
- 19 Nov 2009
is developing these ideas over at Tasks.Item2200
After reviewing that task, it seems this proposal is incomplete.
- 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?
- 20 Nov 2009
Yes. Updated the proposal.
Needs more specifics about how WysiwygPlugin
is going to detect which editor is making
calls, so that it can apply the correct
- 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
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
The important change in direction for this proposal will be a move away from configuring
- Need to consider multiple formfields. POST to
tml2html should contain new header fields, Eg:
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.
- 20 Nov 2009
I now have different ideas about how to tackle this. Also, different priorities (FoswikiDOM
- 17 Feb 2012