V4: Inline editing - No ability to display toolbar in other location than content area

[Jakub Ś]

CKEditor v3 had shared spaces sample that allowed to display toolbar in location specified by user.

For example: editor had extra configuration options

sharedSpaces :
				{
					top : 'topSpace',
					bottom : 'bottomSpace'
				},

in which id of DOM elements were specified

<div id="topSpace"></div>
other code...
<div id="bottomSpace"></div>

This makes its V4 equivalent - inline editing not complete.
I think it would be good idea to allow defining toolbar location in inline editing.

[Aldo Sarmiento]

I read that sharedSpaces feature has been removed in favor of the floating toolbar (ticket #9377). However, I don't think the floating toolbar solves the same problem as sharedSpaces.

There are a lot of UIs out there that have an omnipresent toolbar fixed at the top with editable fields clearly marked (e.g. ​http://jejacks0n.github.com/mercury/). In my opinion, sharedSpaces is a good feature because users can clearly see that they are in an "edit mode" without having to interact with contentEditable fields to get feedback.

[dmachis]

We took a serious look at V4 - Inline editing, and would like to use it as soon as soon as toolbar display can be directed to a div we position, e.g., sharedSpaces implemented. Floating toolbar does not work for our requirement.

[Dinu]

Me too, waiting on this.

[jonesjunior3]

inline editing is great but has its limitations, it would be great if you could specify where the toolbar is positioned, seperating the toolbar into its own element which could be postioned relative to a container instead of the body would solve the issue we are having.

[Blaine Garrett]

I would also very much like this feature.

[Jakub Ś]

#9778 was marked as duplicate.

[Jakub Ś]

#9793 was marked as duplicate.

[RosemaryONeill]

I would also prefer to have something similar to SharedSpaces implemented.

[Frederico Caldeira Knabben]

Pushed ​t/9387@cksource. Sample included.

I have glued part of the floatingspace and the original code for sharedspaces from v3 into a new plugin called sharedspace. The v4 code was well designed so it was really a piece of cake.

The nice thing is that it was possible to make it a standalone plugin, so it'll not disturb those who are not interested on it.

[Wim Leers]

From ​d.o:

Will this also allow us to force the UI to remain visible even if the cursor is not currently inside the editable area? In the case of the Edit module, we want to control when the UI is visible.
(I should have made this more clear — sorry for not explicitly stating this earlier.)

[Frederico Caldeira Knabben]

From ​d.o :)

Yes... btw, I've just pushed this feature at #9387. It does more than what you expect, because I've ported a CKEditor 3 feature... but it does exactly what you want.

[Josh S.]

Just tested the sharedspaces plugin with gpEasy CMS and it's working great!

[Wim Leers]

Glad to hear it works well for gpEasy CMS :)

I forgot to report it here, but over a week ago I reported to @fredck and team that it's also working perfectly for Drupal, and specifically for integration with the Edit module (see the screenshots at the top of ​http://drupal.org/node/1824500 if you want to learn more).

So it would seem this is ready to go.

[Wim Leers]

Quite a few people have played with CKEditor + shared spaces in Drupal now, no problems have been reported. It'd be great if this would be (one of) the first patch(es) to be merged into the 4.1 branch, so that we could start testing against the 4.1 branch. This is the most elementary thing we need, without it, we (at Drupal) cannot use CKEditor's "inline editing" mode.

[Piotrek Koszuliński]

Hi Wim. Sorry for the long waiting - I was completely absorbed by the #9829 for last two weeks :).

I force-pushed branch rebased on master + added commit fixing coding style issues.

I've found some issues:

• Maximize feature doesn't work (no UI spaces in maximize mode) for themed editors, but button is displayed. Initially it is hidden, but that's because toolbar for inline editor is displayed, so you need to focus themed editor first.
• Resize handler is displayed and:
  • For themed ui it works, but this is strange and cool feature at once - I drag here, but it resizes somewhere else :). It even worked with resize_dir='both'.
  • Dragging handler for inline editor throws JS errors.
• Once per N refreshes I've got this (on FF and Chrome):

• When switching between themed and inline editors bottom space changes height.
• I saw in samples that floatingspace plugin is removed, but for me everything worked fine with it loading.
• Showblocks is switched off when blurring inline editor. This makes sense with floatingspace, but when toolbar is constantly visible it is inconsistent with themed editor.
• Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.

[Wim Leers]

Replying to Reinmar:

What I failed to mention in comment:20 and comment:21, is that we're removing the elementspath plugin, i.e. we don't get the bottom space, thus also no resizing handle. This is the most current integration patch for CKEditor in Drupal to leverage this ticket btw: ​http://drupal.org/node/1873500#comment-6930746.

We also only use it for CKEditor's inline editing mode, so the maximize problem and the switching problem are non-issues for us. We are removing the floatingspace plugin as well, so I assume that you were also able to reproduce these problems with that plugin removed, because otherwise that might be the cause?

Sad to see that there are still significant blockers to get this in the 4.1 branch; I was under the impression that was at least one fixed gap!

[Frederico Caldeira Knabben]

Replying to Reinmar:

• Maximize feature doesn't work (no UI spaces in maximize mode) for themed editors, but button is displayed. Initially it is hidden, but that's because toolbar for inline editor is displayed, so you need to focus themed editor first.

That's by design... Maximize is not compatible with shared-spaces (in v3 as well). It was just a sample issue, fixed with ​git:ba414bc.

• Resize handler is displayed and:
  • For themed ui it works, but this is strange and cool feature at once - I drag here, but it resizes somewhere else :). It even worked with resize_dir='both'.
  • Dragging handler for inline editor throws JS errors.

It was a sample issue as well. The resizer should not be available there. Fixed with ​git:ba414bc as well.

• When switching between themed and inline editors bottom space changes height.

I'm not able to reproduce this now, because of #9960. In any case, this should not be a blocker.

• I saw in samples that floatingspace plugin is removed, but for me everything worked fine with it loading.

That's just to show that the floatingspace plugin can be safely removed if shared-spaces is used.

• Showblocks is switched off when blurring inline editor. This makes sense with floatingspace, but when toolbar is constantly visible it is inconsistent with themed editor.

Hum... I have mixed feelings about this. I'm imagining a page full of inline editor instances and I think it would be ok to make it behave in the very same way as it would do if floating spaces would be used instead. In fact, many times, this features will be used to not make the float toolbar float (like having it at the top of the viewport).

Note that we're mixing inline and framed editors in the sample just to showcase the power of shared spaces. Still this situation is very unlike to happen in the real world, so we don't need to make inline and framed behave in the very same way, just to satisfy our sample.

---

The following are under investigation right now, but still this feature is really close to be ready:

• Once per N refreshes I've got this (on FF and Chrome):

• Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.

[Frederico Caldeira Knabben]

Replying to Reinmar:

• Once per N refreshes I've got this (on FF and Chrome):

Fixed with ​git:6569029.

• Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.

Gotta love that browser :)

I've checked the sample, which has not been made with IE7 in mind, and in fact things are messed up. Still it is possible to confirm that the feature works on it.

I would ask to not block this feature because of the sample file. The sample issue can be fixed on a separated ticket, if someone would ever care about it.

---

We should be done with the pointed out issues.

[Wim Leers]

comment:24 and comment:25 are very helpful — thanks!

[Piotrek Koszuliński]

Ok. Code looks OK, feature works, R+ :).

[Frederico Caldeira Knabben]

Committed into ​major with ​git:091cb61.

[Brian Ernesto]

It would also be nice, to enable this to work across frames (iframe) too similar to how you could a few versions back.

[Jakub Ś]

@bernesto this works with both iframed and inline editors. You can check it by getting 'major' on github as explained in comment:29.

[Piotrek Koszuliński]

@j.swiderski: bernesto asked about something different. It'd be cool if toolbar could be in other frame than editors. We're thinking about this feature, but we're not planning to have it on 4.1.

[Jakub Ś]

Let's wait for @bernesto comment but by saying "to how you could a few versions back" I think that he means having it work just like in CKE 3.x (few iframed editors and one toolbar).

[Dinu]

He's definitely talking about location:out, I remember not supporting this anymore was a design decison in CK3 but can't remember the specifics. There definitely is a ticket in here somewhere but with 20 searches I can't find it.