Kick-ass image support: integration for AE's Image + CaptionedImage plug-ins

Spark meta issue: #1721840: [META] As a content editor, I want to be able to add basic images to my post through the WYSIWYG..

Goals

The most simple way possible to provide inline image handling, with:
- the most loosely coupled (not depending/specific to any of the image-related Drupal modules), yet nicely integrated image search as possible
- the most minimal UI possible
- the best possible "true WYSIWYG" experience
- the most "semantically HTML correct" way of dealing with image captions and alignment
- the most reliable way to deal with image captions and alignment (no custom syntax anymore!)
- the retained ability to have clean "source mark-up" in the DB
- the retained ability to disable a filter and have the resulting output comply with that, e.g.: disable the "image caption" filter and instantly all image captions will disappear; re-enable it, and they will instantly reappear

Interaction

Step 1 is inserting an image. That's already been described above. It will search the files_managed table. If we also allow status = 0 files to be inserted, then we can even make it possible to immediately insert images that have been uploaded as part of e.g. an Image field, even without saving the node/entity first.

Step 2 is selecting an image somewhere in the content.

Step 3 is modifying the attributes of the image.

UI for modifying of image attributes

There will be the following UI components in the WYSIWYG UI (toolbar) — powered by Aloha Editor, in the following order:

• row 1: a "URL" textfield
• row 1: "left", "center", "right" and "none" alignment buttons
• row 1: a "toggle caption" button (the caption text cannot be entered in a textfield, but rather it can be entered directly below the image, as it has been in previous Spark demos)
• row 2: a "title" textfield
• row 2: an "alt" textfield
• row 2: "width" and "height" textfields (changing one will update the other; aspect ratio is maintained — later we can do fancier image resizing)

(If there's not enough horizontal width, it will wrap into more rows automatically.)

Results of modifying image attributes

The above UI will allow you to modify the following <img>attributes:

<img src="<image URL>" title="title" alt="alt" width="" height="" data-align="(left|right|center|none)" data-caption="Caption text." />

This is the "source mark-up", i.e. the mark-up that will end up in the DB. As has been discussed in past issues, the advantage of opting for data- attributes is that if you disable the filters that will generate the desired mark-up, the end result will be graceful degradation: you just end up with the images, it's easy to migrate content/mark-up, and so on.

By default, data-align and data-caption are not set, the others will be (width and height are necessary for browsers to be able to lay out pages immediately, without having to wait for the image to load, thus they should be set automatically; legacy content would be updated automatically and wouldn't cause breakage anyway). data-align="none" will never be visible in practice, it equates to no data-align attribute being set.

When data-align or data-caption are set:

1. on the client-side (when editing): Aloha Editor will call a render callback (in JS) that can wrap the img tag in whatever way desirable. If only an alignment is specified, it's also possible to do no wrapping, but simply set a class attribute on the img tag (but this class attribute will never make it back into the source mark-up!).
2. on the server-side (when viewing): Drupal's filter system (in PHP) will perform the exact same transformations as happen in the render callbacks.

This has already been implemented in the Caption module that is included in the first alpha release of Aloha: the code is virtually identical in PHP (theme_caption() and JS (Drupal.theme.caption()).

Implementation

This will be a combination of Aloha Editor's common/image and extra/captioned-image plug-ins.

Notes

• I'm well aware that this isn't a "Northstar UI". However, I think it's still simpler yet more intuitive than most other UIs, including that of Wordpress. Please let's try to keep the UI/UX as simple as possible here. No modals, for example.
• Fun note: this means that e.g. image_resize_filter can be enabled for instant profit: enabling it will cause an image scaled to the defined dimensions to be generated and served to those who are merely viewing, not editing. (The image_resize_filter looks at the width and height attributes of an image, if they differ from the dimensions of the file it points to, it generates a new image and changes the URL to point to that new image.)

Having looked at this, it looks feature complete.

Yay :)

We need URL and ALT, the other features seem to be nice to add, but need to be configurable - keep in mind there are many sites especially larger ones that don't want to give that much image control to their editors. I am not really sure about captions, that seems like a feature not used by 80%.

Can you expand on that? URL and ALT are essential, you say. Does that mean TITLE, WIDTH and HEIGHT are not essential? (ALIGNMENT and CAPTION are clearly not essential, since they're not part of HTML img tag.)

In general: it needs to be configurable for sure.

I'd like to add a note, somehow "Nortstar UI" has become a synonym, for the never to be achieved design. What we want is a design that is highly usable, if that requires models - that is what we will do. However in this case, the aloha design direction has always been to incorporate all its stuff in the top bar. I don't think it makes much sense to defer from that, because I imagine in the testing that was done on this it validated this approach?

They have done usability tests, yes. They evolved their UI over time to become more usable.

The reason I'm explicitly stating "modals" is that in Kevin's Northstar design, he assumed there would be the ability to 1) upload an image from your computer, 2) select an image from elsewhere on the site, 3) select it "from the web". #2 & #3 would trigger a modal. But modals are still a controversial thing, so I'd like to avoid that bikeshed. By reducing all that UI complexity into a single, "smart" textfield, we both keep it simple/not overwhelming yet powerful.

I hope that sounds reasonable?

#6: Thanks for pointing me to that issue! :) Such bugs will be fixed for sure, and it actually looks like it's already been fixed in D8 (#30) and D7 (#33)!? The issue is just open for follow-up clean-up, the actual bugs have been solved.

The major question here is whether you support the concept?

RE: copy/pasting images into browsers: I agree that that is a very important UX feature. However, it goes beyond the minimally viable. Maybe I didn't explain it clearly enough, but the idea is that you can continue to upload files through file fields and image fields, but also Media and whatnot. You can then reference these files by typing parts of their name.
In other words: the approach I described works with (or at least: aims to work with) any existing Drupal way of dealing with files/images. I believe what you're describing should be a follow-up issue? It's 1) a major new feature, 2) it seems like it might move some file handling responsibility into the WYSIWYG editor, whereas in the proposed approach it remains decoupled.
Again, I'd *love* to see this, and would love to work on it as well, but I think that it's a "nice-to-have" rather than a "must-have".

#7: Really? :O So you're saying we should *not* allow content creators to provide a meaningful ALT description? From a UX POV, this would be better: less UI. I doubt it'd be better from an a11y POV. I'll ping Everett Zufelt about what you're saying. It's definitely interesting.
EDIT: I misinterpreted your message. Sorry. Of course I agree that ALT should be mandatory, that's why I listed it in my proposal in #2 :)

Initial round. Consider this an MVP with rough edges.

We have URL and TITLE here. Bojhan said the MVP is URL and ALT, and I agree, but unfortunately the Image plug-in doesn't come with ALT support out-of-the-box, but obviously it's easy to support, and to default to ALT instead of TITLE. There are still plenty of rough edges (e.g. no ability to delete an image, and most annoyingly: the image captions don't play well with it yet), but it is working. It's an initial view of what the MVP can look like.

When you start typing in the URL ("Source") field, it'll search the Drupal site for existing images :) Meaning that if you want to upload + insert an image: 1) upload it (not just select, but also actually upload — you *don't* have to save it!), 2) you can insert it by typing part of its filename.

Only tested on D7.

First commit is a new build of Aloha, which includes Image plug-in bugfixes, second commit is to make it work inside our custom UI:
- D8: http://drupalcode.org/project/aloha.git/commit/4835144 + http://drupalcode.org/project/aloha.git/commit/823db5d
- D7: http://drupalcode.org/project/aloha.git/commit/10cf23e + http://drupalcode.org/project/aloha.git/commit/8eb438d

Marking as NR so we can get early feedback from Bojhan.
@Bojhan: to test, you can install latest D7 Spark and replace that Aloha module with the current one.

FWIW, this is what it currently looks like:

The most minimal approach possible has Bojhan's approval. Postponing; this is a post-feature freeze thing.

.