Hi,
I've a problem with toolbar drop down menu like formats or font families. This menu is made of an iframe. But I can't have any iframe in my editor.
I work for Overblog, first european blog platform. We made a post writing interface based on semantical sections : text sections, pictures sections… which can be reordered by drag'n'droping them. When changing order, section content are moved into the DOM. Iframe doesn't like it and lose their content. To fix this problem, I've used CKe4 with inline mode. All is working fine now. All but the drop down menus in toolbar which are iframe too.
So I need a way to not use iframe for this menu or to redraw the menus after I move the Editor in DOM.
I hope I will not have to rewrite entirely the formats plugin :/
Thanks for your help.
I find a hint : here, in this
I find a hint : here, in this forum, as you can see in the screenshot I uploaded in first post, menu's element is appended in body's top level. So I can move editor where I want and menu will survive. In my integration, like you can see in this new screenshot, menu element is inside editor element. So, I only need a way to move this menu outside editor element.
Attachments:
What I see in the demo is
What I see in the demo is that iframe integration append the menus in end of body, but inline append the menus in ckeditor container. Please make possible to append the menu in body.
Hi Hadrien,
Hi Hadrien,
if you want to see a code change in CKEditor, you can submit a feature request on the Development site. Or you can make this change yourself and submit your patch, CKEditor development is now done at GitHub so feel free to contribute there.
Documentation Manager, CKSource
See CKEditor 5 docs, CKEditor 4 docs, CKEditor 3 docs, CKFinder 3 docs, CKFinder 2 docs for help.
Visit the new CKEditor SDK for samples showcasing editor features to try out and download!
I replied to your ticket,
I replied to your ticket, Hadrien.
I've got one additional advice regarding your case - I think that it'd be better if you reinitialize (destroy && initilize again) editor after moving it in DOM. This is just an intuition, but I guess that there may be more issues caused by changed DOM. Not only CKEditor isn't tested in such scenario, but also contenteditable very often turns out to be very fragile.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
Maybe a wise tip? Never use a
Maybe a wise tip? Never use a menu as an iframe?
It isn't wise at all ;) Why
It isn't wise at all ;) Why shouldn't we use iframes? Because it fails in
your caseHadrien's case? But it allows styling its contents using contents.css file what is crucial for format, styles and font dropdowns. Thanks to that they present identical styles as will be applied in framed editor. The results aren't identical in inline editing any more, but it still has great advantage over not sandboxed panels, because over the years none other way of targetting stylesheet for specific container received support in all important browsers.Perhaps in the future we will rewrite panels in non-frame way, to make them lighter, but it will require deep changes in a lot of places and will complicate many other things.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+