Closed Reinmar closed 7 years ago
The use case is full page editing with editing enabled areas and one toolbar at the top.
It's fine to have the toolbar with all features enabled depending on the schema. This is a must anyway for inner editables so nothing new on this.
It's fine to have a single undo stack as the whole page is seen as one entity. In fact, undo should move selection among editables. This is in fact desired, otherwise multiple editors would be used.
As for today, this should replace the hacks people do with the "shared spaces" feature.
Full page editing makes sense.
So, a related question – do you think that CKEDITOR.create()
should accept elements also in an object format { name: element }
so the creator could be configured to know which element is which.
I see multiple editable as similar feature to nested editable, but with uneditable template.
One may have a special tools for manipulating that template, adding or sort editable blocks, but you can not edit the whole template as you can edit text.
Another case is a toolbar to the top of the page which allows you to editor parts of the page: title, menu, article. Similarly, these are editable parts of uneditable root.
In both cases there is one editor for all editables. It means one toolbar and one config. If you want to have some buttons disabled in some fields it is possible the same way some buttons are disabled in nested editable. But one should not expect different editors behavior in different editables, if he use single editor for all of them.
As for CKEDITOR.create()
's first argument we found use cases for specifying elements in a simple HTML collection (with an algorithm for creating editable names for them base on their id
or data-editable
attrs) or an object. The former will be useful if you have an HTML template with editable parts marked in some way (so you can use a querySelector()
to retrieve them). The latter may be useful if you have a dynamic website (some SPA) where you don't want to edit your views (so there are no ids in them), but you have the list of elements in your app's state.
I've been trying to create a manual for such an editor test and stuck on this, because it turns out that the number of use cases is quite limited.
There are two important aspects:
So I just wonder what use cases do you see taken these limitations?
Note: You can always create multiple editors, so it's absolutely up to you when to use multiple editables. It just seems that it will be a feature useful only in a very specific scenarios.