Editor's features should unify input data basing on defined transformations

[Piotrek Koszuliński]

1. Editor has features like Bold, Italic, Link, Image, Table, Heading 1 format, etc.
2. Some of these features (or rather "their instances", but I'll use the shorter form) may be represented by more than one HTML form. E.g. <strong>, <b> and <span style="font-size:>500"> mean bold.
3. We know most of features' forms and we can prioritize them (e.g. strong, b, span) and we know which form developer prefers if he set allowedContent (#9829).
4. Based on these informations we should unify features' forms in input and output (because of #9909) data.

[Piotrek Koszuliński]

Pushed ​t/9989 and tests (both based on ​t/9829) on review.

What's done?

• Tables' and images' size is set by attributes or styles depending on which format is allowed by allowedContent.
• All known forms of basic styles are now unified into the preferred forms (defined in config.coreStyle_*). So e.g. you can paste <strong>, <b> and <span font-weight="bold"> and even <span font-weight="777"> and all of them will be transformed to <strong> or other preferred format.
• These automatic transformations are based on new properties: feature.contentForms and feature.contentTransformations and methods in CKEDITOR.filter.

You can observe this on editor 2 and editor 3 in filter.html sample. Editor 2 allows only img[width,height], so this format will be used. Editor 3 allows only 'b' and 'i', so all <strong> and <em> elements are properly transformed.

However, transformations affect input and output only. They don't change the way how editor's features work. So e.g. bold button always applies style defined in config.coreStyle_bold. So if 'b' is the preferred form, still, by default 'strong' will be created and it will be transformed to 'b' when switching to source mode or getting data. In the meantime 'strong' will be present inside editor.

[Piotrek Koszuliński]

Rebased branches on major.

[Frederico Caldeira Knabben]

Wonderful job!

[Piotrek Koszuliński]

Merged to major on ​git:a896e92 on dev and dbd4db0 on tests.

[Wim Leers]

Wow, great work indeed!

The documentation on addTransformations is also lovely!

---

However, I wonder if the first example is intentionally nonsensical?

I.e.:

// First group.
[
  // First rule. If table{width} is allowed
  // executes {@link CKEDITOR.filter.transformationsTools#sizeToStyle} on table element.
  'table{width}: sizeToStyle',
  // Second rule shouldn't be executed if first was.
  'table[width]: sizeToAttribute'
],

If I understand this correctly, the first rule would convert <table style="width: 500px;"> to <table width="500">, whereas the second rule would do precisely the opposite. Hence, if you would toggle CKEditor's source mode (which causes transformations to be applied), you would see the underlying HTML being toggled as well?

[Piotrek Koszuliński]

This is an example taken directly from image plugin :D.

It means:

• if 'table{width}' is accepted apply 'sizeToStyle' transformations and stop applying other rules in this group.
• if 'table[width]' is accepted apply 'sizeToAttribute'.

So only the first accepted transformation is applied.

And yes - this change is visible in source mode. You can check this on editors 2. and 3. in filter sample on image. Set size for the image in one of editors, check source mode, copy this image to the second editor and check that size was transformed.