Implement source view with rich text area (designMode=on)

[fredck]

Implement the source view as an IFRAME with designMode=on (using FCKEditingArea), instead of using the <textarea>.

This change would give us many new possibilities to enhance the source view, like source code coloring, automatic selection positioning, and other features that could be implemented by using the DOM only.

Before doing this, we need to discuss all pros and cons of it, and the real possibility to implement it on browsers.

[mjk]

A proposed implementation of this is in [279] and earlier checkins in the mjk developer branch.

I've verified this in IE6, IE7, and FF2 under Windows. It's slightly slower and heavier than using <textarea> because you have to properly escape things into HTML, but this can be mitigated (as the proposal does) by using regexes to do a lot of this processing. It also means that any plugins that depend on SourceView as a textarea will break, though given that there's not a lot you can actually do in a textarea, I'm not sure that this is an issue.

[fredck]

I've always had some problems to be thought about, regarding this feature. I didn't do a deep analysis of it it, but I'll throw some things here, mainly related to the fact that being in "rich editing" makes the browser accept "rich actions" from the user.

Drag and Drop

Users can easily drag and drop formatted text or images from outside to inside the editor.

In IE, we could find solutions for it, making the drop work most like the "Paste as Plain Text" (we have to do that anyway for the editing area).

I'm not sure that the IE solution can be done on other browsers too. Maybe we could block dropping to happen at all, but other than removing a current feature, I'm not that sure we can even do that with Opera or Safari.

Pasting

As above, users would be able to paste formatted text in the editor. This would be a much more very frequent issue, compared to the drag and drop.

We could provide the same solution as for drag and drop, forcing pasting as plain text. But again, this is doable with IE, not with other browser.

Also, while the current "Paste as Plain Text" dialog is acceptable in the WYSIWYG mode, even if users don't like it (including myself), in source mode it has no sense for the end user, because for them the editor is already in text mode while in source. Also, we have no dialogs today for it, so we would loose another current feature.

User Formatting

Users would be able to apply formatting by using keyboard shortcuts. We need to check if FCKKeystrokeHandler is enough to block it.

---

In other words, users must have the impression that they are really in a simple textarea, no matter what they do there. Let's see if we can find out solutions for all related issues.

[fredck]

Replying to mjk:

A proposed implementation of this is in [279] and earlier checkins in the mjk developer branch.

It seams that [279] doesn't have the complete implementation of it. Can you point us to other changesets?

Also, always in [279], you did some job to handle it inside a <PRE>. Is there any reason for it? Couldn't we simply use CSS formatting to have "mono sized fonts" there, like Courier New. Wouldn't it be enough?

Another point... to make it simple, we should use FCKEditingArea.

[alfonsoml]

I think that comment 3 sums up all all my concerns about using a rich text area for the source view. It's very interesting because it opens lots of possibilities in the future, but I did very little tests just pasting some content from another page or an email and the outcome wasn't successful as it preserved the formating and it was hard to know if I was in WYSIWYG or source mode.

Also we must remember that the access to the clipboard is more difficult in IE7, so we can't put too many barriers for the users.

[mjk]

[244] includes the rest of what's necessary for this feature to work correctly. Apply [244], then apply [279]. (Or, for a quick check, just grab the head of /developers/mjk/ and run it; while I've been trying to be fairly clean about dividing features into reasonable checkins, I've made *lots* of patches on my local copy, so this isn't as clean as it could be. Sorry, everyone!)

The <pre> wrap happens because IE6 (in particular) seems not to format correctly if you're using only CSS formatting -- among other things, spaces and tabs in the raw XHTML view don't get preserved with a CSS-only view. However, if someone can come up with a CSS-only solution, it would be vastly preferable. <pre> seemed to get the job done, though.

Pasting formatted text and dealing with drag and drop are both problems in the current implementation, and given that this was first implemented over 2.3.x, I decided not to deal with it at all until the new keystroke code in 2.4 stabilized. There are two possibilities for what to do with formatted text: (1) paste into an offscreen <iframe> (or paste then select the pasted region) and then reinsert the raw HTML source, or (2) convert to plain text. There are good arguments for both.

[alfonsoml]

As I said I wouldn't count on using any offscreen iframe as it can be very problematic to access the clipboard to paste there in everything except IE6.

[julia82]

I'm interesting in knowing more about this discussion!

[alfonsoml]

#2532 and #2613 have been marked as dups.