-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement the do–it–yourself type of an editor #873
Comments
Assembled and Composed 👎 – semantically, nothing's composed or assembled there. DIY 👍 – it best describes what it is, but I'm not sure whether the Detached 👎 – this is not the right word – "detached" is about https://github.com/ckeditor/ckeditor5-core/issues/64. Bricks – quite fine; but DIY works better for me. |
More proposals (not saying that any good, but let's see):
|
That's not a very common idiom and I wouldn't know myself what it means. It wouldn't also ring any (correct) bells in my head. |
👍 for |
Other options: |
|
I'm for Also this editor looks like a |
After googling might be: https://en.wikipedia.org/wiki/Custom_software.
Edit: less cool: |
Please, do not go with |
PS. |
No one expects, that the editor you downloaded from the CDN/website/npm is already tailored. This should be clear to everybody that we do not read your mind and if you need something tailored you need to do some final steps. I really like |
Yeah, I changed my mind. In this specific context people should not be confused. So, I'd personally choose from these two:
|
+0.5 |
My suggestions:
Or make it a flag in |
After thinking of
|
|
It does not make sense because |
Additionally, https://github.com/ckeditor/ckeditor5-core/issues/64 is just a completely different scenario. You can have no replacing and still have the classic UI. |
Maybe we could refer to the state of the UI here? E.g. |
Maybe |
Huh... |
|
I once again propose
In |
I'd be careful with proposing too complicated/long names (e.g. |
One more idea – |
Or |
Generic/Universal suggests some general/universal feature set instead of focusing on the flexibility of the UI. |
I think that if we'll be that pedantic, then we won't find any name ;) Sure this word can be understood this way. But pretty much any word here can be misleading. Every word suggests something. But you need to stay at least a bit open when you learn about these things. For now, the only other name I liked was |
In other words, let's try to find a "good enough" name. Something easy, not overengineered, not overthought, not confusing, and not too popular (so it doesn't appear too often in other contexts in our docs) |
OK, so, let's sum this up. We've got two proposals:
Let's have the final vote: 👍 if you want |
It's Question about the configuration. ATM I resurrected the DecoupledEditor
.create( '<p>foo</p>', {
plugins: [
...
],
image: {
toolbar: [ 'imageStyleFull', 'imageStyleSide' ]
},
ui: {
toolbarContainer: '.doc-editor__top',
editableContainer: '.doc-editor__editable'
},
toolbar: [
'headings', '|', 'fontsize', 'fontfamily', '|',
...
]
} ) we could go deeper DecoupledEditor
.create( '<p>foo</p>', {
plugins: [
...
],
image: {
toolbar: [ 'imageStyleFull', 'imageStyleSide' ]
},
ui: {
decoupled: {
toolbarContainer: '.doc-editor__top',
editableContainer: '.doc-editor__editable'
}
},
toolbar: [
'headings', '|', 'fontsize', 'fontfamily', '|',
...
]
} ) or quite the opposite DecoupledEditor
.create( '<p>foo</p>', {
plugins: [
...
],
image: {
toolbar: [ 'imageStyleFull', 'imageStyleSide' ]
},
decoupled: { // ?
toolbarContainer: '.doc-editor__top',
editableContainer: '.doc-editor__editable'
},
toolbar: [
'headings', '|', 'fontsize', 'fontfamily', '|',
...
]
} ) or even DecoupledEditor
.create( '<p>foo</p>', {
plugins: [
...
],
image: {
toolbar: [ 'imageStyleFull', 'imageStyleSide' ]
},
toolbarContainer: '.doc-editor__top',
editableContainer: '.doc-editor__editable',
toolbar: [
'headings', '|', 'fontsize', 'fontfamily', '|',
...
]
} ) Which one is best? |
🎉 As far as config is concerned, I am for |
I would not put |
Feature: The first implementation of the decoupled editor. Closes #1. Closes ckeditor/ckeditor5#873.
This kind of editor is required for us to showcase the document editor (build) like we used to in v4.
UI
This kind of editor (creator) will not render per se but instead provide the crucial building blocks for the developers to use in their application, e.g.:
They will be available as
editor.ui.view.toolbar
andeditor.ui.view.editable
, where theeditor.ui.view
is a direct, element–less extension of theEditorUIView
class.Data
The editor will not replace an existing DOM element but it will obtain the initial data as an argument.
Config
The editor will support a configuration allowing a quicker configuration (positioning) of the UI elements in DOM, e.g. (config names WIP):
The above will basically do the following:
once they are ready.
Naming
That's the biggest problem so far. The name should express the nature of the editor — it provides the building blocks bound together as a whole (which is easy for developers) but does not force any DOM structure.
Ideas so far:
DIYEditor
,AssembledEditor
,ComposedEditor
,DetachedEditor
,BricksEditor
The text was updated successfully, but these errors were encountered: