>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1617670. --> Reported by: [wim leers](https://www.drupal.org/user/99777) >>> <p>With Aloha's community support growing in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/spark/-/work_items/1580210" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/spark/-/work_items/1580210</a></span>, we &mdash; Th&eacute;odore "nod_" Biadala, Nate "quicksketch" Haug and I &mdash; had a technical call yesterday with the Aloha Editor developers, to figure out whether Aloha Editor really is a good match for Drupal. </p> <p>There's a <a href="https://docs.google.com/a/acquia.com/document/d/1HcXgMd5iWTuwvicvlH7TI1Cxf5HT1iGdOIwfbmk9NYk/edit#">Google Doc</a> (everybody can comment, not edit) with lots of notes and a bunch of links.</p> <p>Highlights:</p> <ul> <li>Input filters: tokens/media.module/&hellip;, but also images/image alignment/image captions: we should use <a href="http://aloha-editor.org/builds/development/alohaeditor-0.21.0-dev-SNAPSHOT-source-20120404-000134/src/demo/block/">Aloha Blocks</a> for this. Aloha Blocks requires DOM nodes to function, so upon editing, "[site:name]" should not be rendered as "drupal.org", but as e.g. "<code>&lt;span class="some-class" data-token="[site:name]"&gt;drupal.org&lt;/span&gt;</code>". The point: we'll need well-defined transformations to support this, but it seems doable. This is already being discussed at <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/spark/-/work_items/1605412" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/spark/-/work_items/1605412</a></span>.<br> Overall, it seems this would work pretty well.</li> <li>Flexibility: Can Aloha plug-ins let us do everything we need to do? Hard to answer conclusively, but it definitely is very flexible. Aloha Blocks, for example, is just another Aloha plug-in.</li> <li>Security/pasting from Word: extensive filter system. Pasting from Word works well (according to Drupal people in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/spark/-/work_items/1580210" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/spark/-/work_items/1580210</a></span>). The sanitization system should allow us to reliably prevent XSS attacks.<br> On a sidenote: things like oEmbed can also be implemented this way &mdash; maybe we can use this for automagic Media module integration, i.e. paste a link in the body and it becomes part of the Media library?</li> <li>Custom UI: well-defined API in place (in the jQuery UI branch), they also use this to implement the default jQuery UI-based UI .</li> <li>Size: Aloha is getting <em>much</em> smaller; <a href="https://docs.google.com/a/acquia.com/document/d/1_xYF1oZs0Mj9PpzLV67-MbtrYi04NNCr57ZZudX4zmY/edit">the numbers</a> are from their yet-to-be-pushed jQuery UI branch.</li> <li>Tests: another branch has moved most tests "back in the green".</li> <li>Mobile: becomes the point of focus once the jQuery UI migration + follow-up clean-up is done.</li> <li>Timeframe: jQuery UI branch by beginning of July, "very good version" by end of August.</li> </ul> <p><strong>For the sake of the discussion at hand: please assume that Aloha Editor is going to be adopted into Drupal 8 core by, say, October. Clearly, this would need a <em>lot</em> of integration work. But that's not the point. The point is: <em>could it work?</em>, <em>does Aloha Editor have a future, i.e. is it the right long-term WYSIWYG choice?</em>, etc.</strong></p> <p><strong>What are <em>your</em> concerns?</strong></p>