Content Rules

Content Rules is a module that facilitates global HTML content restriction across Aloha Editor. It is designed as a single point of configuration that will provide a contract to uniformly effect editing interactions and the user interface in cohesive way.

1 Informer not enforcer

Plugin developers should note that there are myriad ways to insert content into an editable and Content Rules does not provide a mechanism to forcibly prevent this. It remains the responsibility of all implementations to use Content Rules to check whether the content that is to be inserted in a given editable is permitted according to Content Rules configuration.

2 Configuration

If not Content Rules configuration is provided then all elements will be considered permissable with regards to Content Rules. The same is true for any editable which does not match any configured selectors.

3 Whitelists

Whitelist configuration explicitly specifies which type of elements are to be permitted in editables.

For example, the following configuration stipulates that all editables which match the selector * are permitted to only contain the elements <b>, <i>, and <u>.

Aloha.settings.contentRules = {
whitelist: {
'*': ['b', 'i', 'u']
}
}

It is possible to combine whitelist settings across different selectors. All settings whose selectors match an editable will take effect when checking Content Rules.

The configuration below permits all editables to contain <b>, <i>, and <u> elements, as in the example before. In addition, however, the second selector matches editables with the class name longform. Since any editable matching the selector .longform also matches the selector *, this editable will not only be allowed to contain <p> and <h2> elements, but will also be allowed to contain <b>, <i>, and <u> elements.

4 Blacklists

In cases where only a few elements are to be disallowed in an editable, it would be cumbersome to have to specify every single element that is permitted, since this would require writing out most of all the HTML elements.

This is where blacklists are useful. Blacklists are opposite to whitelists in that elements that are specified in a blacklist are the only elements that are not allowed in a matching editable.

The configuration below declares that no editable is permitted to contain <script> or <style> elements; all other elements are permitted.

5 Using blacklists and whitelists together

It is possible to combine both whitelists and blacklists as follows:

In the case below, all editables are permitted to contain all the elements specified in the whitelist array for the selector *. The blacklist setting for .title forbids the a subset of the lists permitted in the whitelist.

This means that an editable with the class name title will be permitted to contain all elements whitelisted against the * selector, but unlike other editables, it will be further restricted to only allow only those elements that are not blacklist specified in .title.

isAllowed() does not indicate whether an element is allowed in an editable based on HTML schema rules, but simply on arbitrary Content Rules configuration.

8 translate()

Given an editable, and a node name, this function returns a translation of that node name into another, according to configured Content Rules. If no translation has been mapped in the settings, than none will be done by translate(), and the same node name will be retured instead.