Changes between Initial Version and Version 3 of Ticket #10276


Ignore:
Timestamp:
Jun 5, 2013, 10:29:15 PM (7 years ago)
Author:
Wim Leers
Comment:

This, or something like it, is (AFAICT) necessary for https://drupal.org/node/1936392. I discussed this in that context with @Reinmar on March 27, I think slightly before this ticket was created.


Thinking purely conceptually and logically, I think there might be a case to be made for "whitelisting only" from a WYSIWYG editor perspective.

Having only a whitelist, you must enumerate all allowed tags, attributes, styles and classes. That might seem like more work, but this also ensures that you fully define the universe of all possible uses and values. For example, rather han being able to exclude (blacklist) e.g. just the target attribute on <a> tags, you'll have to allow (whitelist) all of the attributes you want to allow: href, hreflang and rel. More work, but also more certainty, more control. It's probably worth it.

Since a WYSIWYG editor's job is to generate markup, and it's easy to abuse it (or plugins for it) to generate unwanted markup, it makes a lot of sense to demand that the whole universe of allowed values is well-defined.

So, whitelisting only, allowedContent only, makes sense for CKEditor.


Replying to wwalc:

I think disallowedContent may not be necessary, since there's not really a use case for blacklisting tags. But there is a clear use case for blacklisting properties (attributes, styles, classes). What if CKEditor would just have to allow that?

Besides attributes and requiredAttributes, you could have forbiddenAttributes. In the string notation, you could use the ^ character for marking forbidden attributes, similarly like ! for required attributes. (Why ^? It could be another character of course, but ^ is used for negation in regular expressions.)

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10276

    • Property Status changed from new to confirmed
    • Property Cc wim.leers@… added
    • Property Keywords Drupal added
  • Ticket #10276 – Description

    initial v3  
    1 We have config.allowedContent being a whitelist.
     1We have `config.allowedContent` being a whitelist.
    22
    3 But real life cases often require also being able to define blacklist. Therefore we should introduce config.disallowedContent.
     3But real life cases often require also being able to define blacklist. Therefore we should introduce `config.disallowedContent`.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy