Item1535: "Typewriter" applied to bold text does not work

If I select ordinary bold text and click the "typewriter text" button in the WYSIWYG editor, then the editor shows the text as bold. When I click save, the text reverts to bold.

However, if I select ordinary typewriter text, and click the "bold" button, then the editor shows the text as typewriter and this formatting is saved correctly, too.

Similarly, if I apply "typewriter" to "italic" text, it does not work. But applying "italic" to "typewriter" text does work.

Here is the result from applying typewriter, bold and italics, in different orders:

      * <span class="WYSIWYG_TT"> __bold, then italic, then typewriter.__ </span>
      * <strong><em>bold, then typewriter, then italic. </em><br /></strong>
      * <span class="WYSIWYG_TT"> __italic, then bold, then typewriter.__ </span>
      * <strong><span class="WYSIWYG_TT"> _italic, then typewriter, then bold._ </span></strong>
      * <em> ==typewriter, then bold, then italic.== </em>
      * __typewriter, then italic, then bold.__

-- MichaelTempest - 27 Apr 2009

I looked to see what WysiwygPlugin receives if I select bold text and click the "typewriter text" button in the WYSIWYG editor, and then save.

TinyMCE produces

<strong class="WYSIWYG_TT">X</strong>

WysiwygPlugin seems designed to handle

<strong><span class="WYSIWYG_TT">X</span></strong>

w3c validator says both are valid and the WysiwygPlugin's documentation suggests that it is intended to work with a variety of HTML editors, so perhaps WysiwygPlugin should handle both variations of HTML.

At the same time, _nodeChange in editor_plugin_src.js expects the WYSIWYG_TT class to be applied to a span (line 176). This suggests that TinyMCE should not apply this class to a strong tag.

-- MichaelTempest - 01 May 2009

This problem shows itself in other ways, too. If I select a whole paragraph and make it typewriter text, TMCE applies the WYSIWYG_TT class to the p tag. And that is lost when I save.

-- MichaelTempest - 02 May 2009

After a discussion with CDot on #foswiki (slightly refactored here):

• CDot said the idea behind the "WYSIWYG_TT" class allocation is that TT on a P should turn into a PRE block. But it didn't work, because it added unwanted semantics (respecting linebreaks).
• CDot: ideally TT will work identically to <strong> and <em>
  • However, TMCE just uses the MIDAS commands
  • CDot: "Bold" and "Italic" are MIDAS commands. http://www.mozilla.org/editor/midas-spec.html Midas is awfully clever about how it re-arranges the HTML to support bolding selections over block boundaries, for example and there is (was) no mechanism in TMC to emulate that. The best I could do was to use the mceSetCSSClass command. Unfortunately that doesn't create a span if a suitable existing element exists. So you could argue it either way; WysiwygPlugin could support TT of all element types, or TMCE could be persuaded to generate a consistent construct for TT.
  • MTempest: That is what I found And I don't know which way is better, in the long run.
  • CDot: well, consider what happens when we plug in another editor (Xinha, FCK). A solution in WysiwygPlugin is better for that
• There is a knotty, problem, though. CDot: TML doesn't support a clean solution to <p class="WYSIWYG_TT">. You can't use =text=, because a <p> can contain linebreaks [and] you can't even use <code>, because a <p> may contain block elements, and <code> only works inline so you have to use <pre>, which adds unwanted semantics (respecting linebreaks).
  • CDot said TOM will not solve this problem.

-- MichaelTempest - 03 May 2009