One of the pieces of feedback from Jess/xjm's review of #1809702: WYSIWYG: Add Aloha Editor to core (unfortunately communicated via IRC and not posted to the issue), was that she found it alarming that she could neither see nor edit the "true" HTML version of what was in the text field. While she could see from Firebug that it was merely changing her existing HTML and not adding a bunch of crap, and I verbally re-assured her as well that this was what it was doing, she nonetheless really wanted the ability to view the "naked" version and edit it directly.
I'm not 100% sure if we want to do this, at least in the initial patch, and even in core altogether. It seems like both a legacy artifact of the fact that other WYSIWYG editors are terrible, as well as a "power user" thing. But wanted to lodge it as a feature request nonetheless so we capture it and discuss it.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | aloha-plugin-htmlsource.png | 122.34 KB | wim leers |
Comments
Comment #1
xen commentedOne issue with a 'edit source' option is that it'll have to deal with faulty HTML in a sane way. But I think a workable option is to create a plugin that provides a button that pops up a window with a text field with the source. Which should be quite do-able in a contrib module, so it can be left out of core.
I'd support keeping it out of core, I get an odd feeling when I see that button in RTEs in different places. It really is a legacy from old times...
Comment #2
moshe weitzman commentedFWIW, I was surprised by this too. Another way to solve this would be to provide an on-demand, on page way to disable Aloha in favor or a plan textarea.
Comment #3
wim leersThis is a sample plug-in that provides a "View HTML source" button. It uses a jQuery UI dialog to show the HTML source. I'm not saying this should be the final answer to this need. It's a possible answer.
Screenshot attached. Temporarily providing an online demo of this: http://dev.wimleers.com/aloha/aloha-plugin-htmlsource/example/.
Comment #4
wim leersWe can address this post-feature freeze for sure.
Comment #5
wim leersComment #6
jamesbisset commentedCan we confirm that, not only will we always have the facility to edit the html source, but that the markup will be sanely formatted?
I note that Wim's example uses whitespace and new lines in the source when generating markup, although I'm not sure it follows any standard I'm familiar with.
But I also see the standard Drupal behaviour with WYSIWYG plugins on Webchick's demo - i.e. switch to plaintext and get a textarea of markup soup without any formatting whatsoever.
I think what I'm asking for is the same righteous approach to generated markup as Drupal has for coding standards. Is that already in the spec, or have I just asked for a Feature?