You are here: Foswiki>Tasks Web>Item726 (02 Jun 2009, CrawfordCurrie)Edit Attach

Item726: WYSIWYG Documentation/Help/errata

pencil
Priority: Normal
Current State: Closed
Released In:
Target Release:
Applies To: Extension
Component: TinyMCEPlugin
Branches:
Reported By: TimotheLitt
Waiting For:
Last Change By: CrawfordCurrie
The protection regions are not well documented in the editor help, or anywhere else that I've found.

Neither I nor my users really understand their use models. And there are several other unexpected behaviors...
  • Protect on save - When would I want to protect something only on one save but not forever? Isn't this just asking for trouble when the next person edits a topic? Is the assumption that when the topic is next read, some protection will be automagically applied? If so, this has not worked consistently for me. Formatted search, IF & INCLUDE macros have been especially problematic.
  • 'Using a Macro' in help says to 'assign the PROTECTED style to it before you save'. Which protected style - on save? Forever?
  • Literal - I don't see <literal> in any HTML spec. So it (and <verbatim>) must be some internal pseudo-markup.
All this discussion is inside-out. What a user really wants to know is what to do to effect their intent. So I think this needs to be written up something like:
  • When you save a topic, the editor will encode what you write so that when the topic is displayed, it will look the same as it does in the editor. But it doesn't keep exactly what you typed. Sometimes, this isn't what you want.
  • If you want to embed HTML commands - for example, a form definition or formatting not supported by the editor - select those commands and apply the ?LITERAL? ?Protectonxx? style to them. This will ensure that they are not encoded.
  • If you want to display a code or command example, apply the VERBATIM style. This will ensure that no macros are expanded, will preserve line breaks and will display your text in a monospace font. The VERBATIM style can only be applied on line boundaries.
  • If you want to enter TML code or advanced macros that aren't automatically protected (and we really should automatically protect everything, right?), apply Protect forever. (And how does this differ from LITERAL?)
Anchors:

The anchor on the left, named "fred" was entered with the anchor editor icon. It expands to
<a name="fred" title="fred"></a>
But TML uses
#fred
And things like the comment plugin don't work with these anchors.

But if you have a topic with #anchor lines, save often seems to insert a leading space, making the anchor unusable. I've noticed that expecially with TML sequences like
#anchor

---+++ heading

Verbatim:

I tried to use verbatim on part of a line in the previous examples, but selecting any part of a line makes the whole line verbatim.

Colors: I tried to color a letter in this line. (Internet explorer 7). I get a font color window with 8 rows (the last box is pink). It looks like there should be more rows, but resize is disabled on the pop-up. If I change the zoom to 50%, I can see that there are 5 more rows.

Firefox:

I tried to edit foswiki.org Sandbox TestTopic3 with firefox. I get an empty edit box and can't put the focus in the edit box. None of the edit buttons (like bulleted list) work. If I try to enter a table, the table dialog comes up, but Insert doesn't do anything. Internet explorer works fine.

Safari:

If I use Safari, I get the font color popup with a scroll bar -- and the window is resizeable. However, the error console reports "Refused to set unsafe header Content-length" on the main edit window - I think there's some discussion about this elsewhere.

Tuning/correctness:

I highly recommend the Safari Develop/inspector tools for making sure that foswiki output is clean. It also (under Network) has an excellent display of page load performance - and will provide hints for improving performance. See also CACM vol 51 no 12 p. 36 "High-performance web sites" for some very useful hints on optimizing output for performance. (Firefox inspector/error console is also helpful).

Bad empty paragraph tags

Also under safari, virtually all pages report "XML self-closing tag syntax used on <p>. The tag will not be closed." See section C3 of the XHTML 1.0 specification for why. (You have to use <p> </p> for an empty paragraph.)

Perhaps this should be multiple items - but at least I captured them.

-- TimotheLitt - 10 Jan 2009

elevating to urgent in the hope we can make it so

-- SvenDowideit - 10 Feb 2009

To anyone starting on this. There are some wrong content above.

Anchors done as TML must be wikiwords. #anchor is not seen as an anchor. #MyAnchor is a valid anchor written at the beginning of a line.

-- KennethLavrsen - 10 Feb 2009

Yes, I know that TML anchors must be wikiwords; I use them a lot in real life. Sorry about the poor example. FredAnchor would have been a better choice. I fixed the example - the bad behaviors were experienced with proper anchors. I verified that the editor creates non-TML anchors with wikiwords. FredXxx shows this.

Preview Broken In testing the preceeding comment, I clicked Preview. The topic was not marked preview, and there was no button to commit it. Browser Back button made me refresh, but there was still no way to save. So Preview is broken. (I also note that edit is giving raw edit, even though there's still a raw edit button. So perhaps the confusion is that Foswiki partially thinks it's in WYSIWYG mode...) IE6 this time.

-- TimotheLitt - 10 Feb 2009

We had to remove preview when editing with Wysiwyg because in FF going back meant loosing all you keyed in. And what is preview worth if you cannot go back and improve things.

Here in Tasks web the Wysiwyg is not working. Someone decided to turn it off. Something I am less happy about because it means we get less test covereage of Wywiwyg frown, sad smile

It is not correctly turned off because there is still both an edit and Edit Raw. That is a problem with the special Foswiki.org skin.

-- KennethLavrsen - 10 Feb 2009

Since noone feels like updating Wysiwyg plugin and this has been open for a month I downgrade to normal.

There is lately an inflation in calling bugs urgent.

-- KennethLavrsen - 13 Feb 2009

This report targets the WysiwygPlugin, but I just checked the documentation on that plugin and it doesn't mention literal or sticky (except in the change history) so I assume it actually applies to TinyMCEPlugin. Further the first section applies to the quick help.

I really can't cope with multiple problems being reported in a single problem report, so I'm just going to address the first one - the quick help - here. For the other problems, several of them seem to be repeats of existing reports - it would take me too long to check this, though.

So, I have improved the quick help. I'm closing this report; please raise individual reports for the other issues.

-- CrawfordCurrie - 01 Jun 2009

ItemTemplate edit

Summary WYSIWYG Documentation/Help/errata
ReportedBy TimotheLitt
Codebase
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Extension
Component TinyMCEPlugin
Priority Normal
CurrentState Closed
WaitingFor
Checkins distro:c81f474dcda8
ReleasedIn
Topic revision: r10 - 02 Jun 2009, CrawfordCurrie
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