Krang::BulkEdit::Xinha::Config - Class to configure Xinha-based bulk editing


Krang::BulkEdit::Xinha::Config - Class to configure for Xinha-based bulk editing


This module represents the default configuration of Xinha-based bulk editing as implemented in pkg('BulkEdit::Xinha').

You may modify this configuration by subclassing this module.



Note that by the time the incoming HTML is passed to html_scrubber() the browser-specific markup (e.g. Gecko's BOLD tag) has already been normalized (e.g. to STRONG). So there's no need to include B, EM or SPAN in the list of inline elements. See Krang::Markup, Krang::Markup::IE, Krang::Markup::Gecko and Krang::Markup::WebKit.

Also note that in order to override the default behavior re: <script> tags (which is to strip them), you must do the following: 1. call HTML::Scrubber's special script() method, i.e. $scrubber->script(1); 2. specify acceptable <script> attributes in the rules arrayref, e.g. [..., script => { '*' => 1 }, ...]


Be careful with your legacy data. It may contain, say, HTMLTableElements coded into some textarea 'paragraph' element. If you pass this through the default configuration of html_scrubber(), you will see the table in Xinha, but when done bulk editing, html_scrubber() will happily strip away the TABLE tags, leaving you with the bare text content of all table cells concatenated without whitespace!

     Know Your Data!

Also, nothing prevents users from typing a HTML table into a 'paragraph' textarea. They will be surprised to see the TABLE tags gone when passing this textarea's data through Xinha's bulk edit.

Why are tables disallowed? Because the available Xinha ignores a decent way to handle tables.

Consider that the configuration or Xinha's toolbar and the set of allowed HTMLElements are somewhat interdependent. No automagic is provided to keep them streamlined. E.g., if you configure Xinha's toolbar to not show the button for 'Ordered List', the 'ol' tag should be disallowed - although users might of course paste ordered lists in...