Data and features activation based on configurations

[Frederico Caldeira Knabben]

The basic idea is introducing filtering that acts on the HTML accepte by the editor and the feature available in it.

1. An as easy as possible way to configure the elements, attributes and transformations (e.g. <b> to <strong>) that the editor should support.

2. By default, this configuration is defined by the plugins available in the editor. E.g. remove the link plugin and <a> will not any more be accepted.

3. Developers can define this configuration. At that point, plugins, or part of their features, get enabled/disabled based on the configuration.

4. All data input (especially paste) in the editor will be then filtered, based on the configuration. Transformations first and then elements/styles checks.

5. Input data normalization will take place before filtering, bringing to an acceptable DOM structure.

6. Special pasting plugins, like Paste from Word, will be reviewed to use the normalization+filtering system.

7. Selection context participates on filtering as well. A <h1> editable should restrict the editor features accordingly. Another example, a selection inside <a> should not permit <a> elements being inserted.

As a result only allowed HTML will reach the contents and only allowed plugins (or their features) will be enabled.

[Wim Leers]

I would +9000 if I could, but I'll just stick to a +1 :)

---

The first three bullets make total sense.

Can you clarify what: "filtering" in the fourth bullet and "input data normalization" in the fifth bullet entail precisely?
And why isn't "transformations" mentioned in the sixth bullet, just normalization & filtering? If a Word doc contains the equivalent of a <b> tag, it should also be possible to transform that to a <strong> tag.

Overall, it seems you have several concepts in CKEditor: "transformations" and "elements/styles checks" which together seem to form "filters", as well as "normalization".

I need to understand this before I can give useful feedback.

I apologize if this is to be found plain and clear somewhere in the CKEditor docs, but if you could reply with links, then I can be certain I'm reading the best docs. Thanks.

[Piotrek Koszuliński]

Hi Wim :) I would +9000 too. As pasting and data insertion are apples in my eye I was looking forward to finally add this feature to the editor. I'm really thrilled about it (omg... I'm a geek :D).

Answering to your question about filtering and data normalization. Filtering is what this ticket is all about. This means stripping elements (just tags, not content) and styles/attributes that are not allowed in content of the editor and transforming not allowed elements into accepted ones. For example - we've got small parts of this feature already implemented:

• basing on DTD (​CKEDITOR.dtd) we're stripping elements that can't be inserted into specific editable. We needed that because since 4.0 editor can be initialized on elements like headers, pre, address, etc (entire list - ​CKEDITOR.dtd.$editable). So e.g. if table is pasted into editor initialzed on header, then table and all tr, td, th tags are stripped and contents of their children are joined together. This part of filtering is done by ​editor.insertHtml() (in fact inside editable.insertHtml().
• pastefromword is currently performing elements transformation basing on styles settings. E.g. it replaces <b> and <span style="font-weight:bold"> with <strong> if bold style is configured this way. We'll review Word filter in this ticket, because we'll be able to remove that parts (see 6.).

But before we're able to transform data, we need to normalize (fix) them. This is done differently depending on input source. The most important part of normalization is done by ​htmlDataProcessor. It can fix really, really bad HTML. However, Word generates such a mess (or rather browsers generate mess for messy Word data in clipboard) that we need some special pre-normalization, specific for this input - this is done by pastefromword plugin. Another example of specific input is normal pasting (especially in Webkit), for which we have some preprocessing in clipboard plugin.

[Frederico Caldeira Knabben]

Reinmar gave a full overview of the things that we have now. Just to not make it confusing, this ticket is all about redesigning this entire system, in a simpler and more efficient model. We still have to put details on paper.

Btw, when I said "normalization+filtering", I've combined "transformation+filtering" into "filtering".

[Frederico Caldeira Knabben]

Reinmar said something important: the system is also aware about the editable or selection context. I'm adding point "7" in the list for it.