Hey Greg, Just wondering if when you click into the text area, do you see the popup menu?

Hey Irvin, yeah I get the pop menu, but I’m thinking more about the content area - rather than being ‘just another text box’ with some editing capabilities, it used to ‘feel’ more like a word processor. I’d like to be able to give our users that same experience if I can.

My gut tells me that Skuid moved from the Classic to the Inline UI.

http://docs.ckeditor.com/#!/guide/dev_uitypes

Hmmm yeah I see what you mean. I wonder if there’s any way to switch between the two…

I wanted to dig into it further this morning but darn meetings, ya’ know.  Maybe Skuid devs can advise?

Sorry for delay on this one.  Our Rich Text Guru is out of the office.  (Tho he now hates that title…)  We’ll have a better answer for you next week.  

Hi Rob, just wondering if there was any progress on this CKEditor issue? Thanks.

Greg,

Apologies for the delayed response, but the answer required some time to think through and discuss.

Why is the UI different?

We switched from using CKEditor’s iframe mode to its “inline” mode.

Why are you using the “inline” mode?

Like most rich text editors with some history, the standard CKEditor was originally developed to support IE 5 and was thus heavily dependent on iframe elements for displaying and editing documents (unlike newer editors which were developed for “modern” HTML, CSS and Javascript standards). While this worked well with the initial versions of Skuid, we started running into major issues when components were temporarily removed from the DOM and then displayed again, such as in table drawers or in the mobile experience. We tried to find workarounds, but were eventually forced to conclude that CKEditor’s inline mode was the only viable solution.

Why isn’t the toolbar always visible when using inline mode?

In short, CKEditor doesn’t support it. The longer explanation is that CKEditor’s inline mode is designed to be more flexible. Rather than having a dedicated iframe into which a toolbar can be injected, inline mode works by directly editing the contents of an HTML element with the “contenteditable” attribute. The problem is that CKEditor can’t inject a toolbar into the element you are editing (otherwise the toolbar would become part of the content and would itself be editable) and it can’t reliably inject a toolbar above or next to the editable element, since there’s no way to know how that injected toolbar will render. Rather, CKEditor uses a floating toolbar that aligns itself with the editable element, but this toolbar cannot be permanently displayed because it obscures the page underneath.

Why can’t I set the height?

According to CKEditor’s documentation, the height and width config properties are ignored when CKEditor is using inline mode. This has to do with the idea that you are editing a “live” page, where height and width are set by CSS rules.

How do I get back to the old CKEditor?

We’ve had some internal discussions about this. While I’d like to just add a checkbox to enable the old mode, the problem is that there are an increasing number of scenarios where the iframe-based CKEditor simply would not work, and it’s not always easy to predict or communicate where and when it would be appropriate. For that reason, I don’t expect that we’ll be adding a feature like that anytime soon.

We’ll update this thread if there’s any change to announce, but for now I’m afraid that the old experience is no longer supported in Skuid.

Appreciate the thoughtful response.