| 1 | | There are some cases that we want to prevent ACF from removing something, which may appear to be junk html. |
| 2 | | |
| 3 | | Consider following UC for ''media embed'' plugin:[[BR]] |
| 4 | | Gist uses spans with custom classes for syntax highlighting, for instance: |
| 5 | | {{{ |
| 6 | | <div class="line" id="LC204"> |
| 7 | | |
| 8 | | <span class="nb">document</span> |
| 9 | | <span class="p">.</span> |
| 10 | | <span class="nx">removeEventListener</span> |
| 11 | | <span class="p">(</span> |
| 12 | | <span class="s1">'DOMContentLoaded'</span> |
| 13 | | <span class="p">,</span> |
| 14 | | <span class="nx">onReady</span> |
| 15 | | <span class="p">,</span> |
| 16 | | <span class="kc">false</span> |
| 17 | | <span class="p">);</span> |
| 18 | | </div> |
| 19 | | }}} |
| 20 | | |
| 21 | | We want to keep classes for spans. |
| | 1 | == Cases we need to solve == |
| | 2 | |
| | 3 | 1. Integration with styles applicable to widgets. See #11297. |
| | 4 | 2. Disabling ACF in body of some widgets - e.g. mediaembed. See #10925. |
| | 5 | 3. Filtering pasted widgets. See #11115. |
| | 6 | |
| | 7 | == Cause of problems == |
| | 8 | |
| | 9 | 1. ACF filters data before widgets are upcasted. Therefore for example mediaembed cannot notify ACF that children of some elements should not be filtered and it's not possible to create allowed content rule based on a widget name and style properties allowed on that widget element. |
| | 10 | 2. In pasted or dropped content we have the upcasted and initialized HTML of a widget. Therefore we cannot filter it, because ACF is applied to the data format. |
| | 11 | |
| | 12 | == Solution == |
| | 13 | |
| | 14 | === ACF after upcasting === |
| | 15 | |
| | 16 | The advantage of this solution is that ACF would know everything about widgets, so it could make precise decisions. Additionally, while filtering pasted content there would be no problem at all, because it would be the same case. |
| | 17 | |
| | 18 | However, there are two problems which makes this idea incorrect: |
| | 19 | |
| | 20 | * Assuming that we've got some complex widget like image2, which makes a lot of transformations while upcasting, how would ACF filters the upcasted image? How could it strip, without breaking widget, `figcaption` and `figure` if they are not allowed? It's simply impossible, without some special actions from the upcast method. It could theoretically ask ACF if specific components of widget are allowed, but it's tricky and still doesn't solve this issue completely. |
| | 21 | * Moreover, when ACF would filter upcasted version of widgets it would be impossible or a lot harder to define ACF rules. One would have to know internal widget structure to define those rules. In my opinion this makes the idea totally wrong. **ACF filters data format** and that's a foundation we have to keep. |
| | 22 | |
| | 23 | === ACF filters data === |
| | 24 | |
| | 25 | Previous section proved that ACF needs to be applied to data, not to inner HTML. This means that the current way of processing is the only correct one, but on the other hand we still have those three cases, which are listed at the beginning, that have to be solved. |
| | 26 | |
| | 27 | 1. Integration with styles applicable to widgets - a solution has been proposed in http://dev.ckeditor.com/ticket/11297#comment:8. It may not be 100% precise in some cases, but there's another ACF's characteristic which we have to keep in mind. It's not meant to be a security filter. It's meant to ensure good UX in as many cases as possible. Therefore when uncommon constellation of element and its attributes slips through its hands it's not a blocker. |
| | 28 | |
| | 29 | 2. Disabling ACF without a possibility to communicate through element's attributes. In this case the only possible solution is a callback executed by ACF which will notify it about how it should proceed. For example mediaembed will add a callback which will tell ACF that all descendants of element should be skipped if element has mediaembed's class. Callback will return binary flags, because we may need more options in the future. Example of flags that we may need to implement: |
| | 30 | |
| | 31 | * `DISABLE_ON_ELEMENT` - skips only this element (continues on descendants), |
| | 32 | * `DISABLE_ON_DESCENDANTS` - skips descendants, |
| | 33 | * `CONTINUE_ITERATION` - continue iteration - used with `DISABLE_ON_DESCENDANTS` could inform ACF that it should look for a descendant that reenables filtering, |
| | 34 | * `ENABLE` - reenable filtering. |
| | 35 | |
| | 36 | But of course for now we'll need just one of these flags, so only one should be implemented. |
| | 37 | |
| | 38 | 3. Filtering pasted widgets. It's not possible to filter widget's upcasted version - only its source version can be filtered. If we had full control over clipboard we could downcast selected data on cut/copy and then filtering on paste would work like filtering on data load. Unfortunately, we don't have full control over clipboard and won't have even after #11437, because of IEs. |
| | 39 | |
| | 40 | Therefore, the only solution might be to look for upcasted widgets in pasted data, extract their HTML, find out from which editors they came from, use those editors to downcast them, and replace their upcasted version with downcasted one in pasted data. This could be based on unique editors' ids and `data-cke-widget-editor-id` attributes marking widget wrappers. This won't work when copying between window tabs or frames or when editor instance has been destroyed in the meantime and I'm not sure what should happen in such situation. |
| | 41 | |
| | 42 | Similar solution, maybe more straightforward and more reliable would be if editor, on `cut/copy/dragstart` if it cannot override the content, could retrieve widgets' HTML from selection, downcast them and store in the `CKEDITOR` object, so all other editors will be able to replace pasted widgets with their downcasted HTML stored in that object. Of course widgets have to be marked with unique ids to make this possible. This option is better than the previous one because widget's HTML will be kept even after editor is destroyed. We can also reuse the same mechanism in drag and drop for IEs in which we will need to store the data for a while. As the mechanism will be public 3rd party code will be able to integrate with it. |
