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.

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.