Consider feature parity for "Image Details" TinyMCE functionality

[getsource]

Right now, there are a few things remaining for parity with the current "Edit Image" functionality present in core.

This modal (screenshots below) is accessible within TinyMCE when mousing over an inserted image, then clicking the edit button.

The features from this modal that seem to not have equivalents in Gutenberg at the moment are:

• Edit Image Title see Consider feature parity for "Image Details" TinyMCE functionality #7504 (comment).
  Note: Title edit is available in Gutenberg, but changes title globally in library, rather than per inserted image, and does not appear to insert this title into the title attribute, like the current feature.
• Link Rel (Add link rel and link class to image block inspector (see #7504) #7771)
• Link CSS Class (Add link rel and link class to image block inspector (see #7504) #7771)
• Open Link in a new tab ([Enhancement] Introduce Link Target in Image Block #9520)

Screenshots

Additional context

• The Edit button looks the same, but does something different, flow-wise, in Gutenberg to what users would have expected in TinyMCE.
• Core tried removing some of these options in 3.9, but ended up adding them back after user feedback. I'm personally not opposed to trying to change what is offered again, but figured it'd be a good idea to discuss, so that anything removed is done with intentionality.

[karmatosed]

Core tried removing some of these options in 3.9, but ended up adding them back after user feedback. I'm personally not opposed to trying to change what is offered again, but figured it'd be a good idea to discuss, so that anything removed is done with intentionality.

@getsource would you mind some context as to what was tried to be removed and the general outcome there? I see you say some, it could be good to know which.

[danielbachhuber]

Previously #4007 #5309

[getsource]

@karmatosed Per my recollection (this was a while ago), it was everything that is under the advanced options section in the modal, and informed primarily by WP.com user testing (actual rollout and rollback) and statistics.

[getsource]

Related: #5309

[designsimply]

Removed the Good First Issue label because this issue looks a bit complex for someone new to tackle. If you feel strongly about adding it back, please add it back with a comment or ping me to discuss!

[karmatosed]

Looking at this it's an advanced setting over something to surface at the sidebar level. What about this?

This doesn't really change much. It does remove open in new window as that is assumed in this case.

[getsource]

Sorry, I'm seeing this comment a bit late. Yes, the sidebar seems like a perfect place to surface it.

[Ipstenu]

Related to this... You can't use attachment_fields_to_edit for Gutenberg.

Which means if you need to add in a required field to an image, it won't show up in the Gutenblock sidebar.

[danielbachhuber]

Which means if you need to add in a required field to an image, it won't show up in the Gutenblock sidebar.

attachment_fields_to_edit doesn't currently add fields to this UI:

Once an image is inserted into the post_content, it's de-coupled from the attachment stored in the database. All of the fields in the image shared reference <img> attributes directly.

To summarize, we need the fields defined in the issue description, but they'll simply modify the <img> HTML in the block.

[Ipstenu]

Just to show what kind of thing you can add in, this is what you see from Add Media on Classic:

It doesn't show on the gutenberg sidebar nor (as Daniel pointed out) the details UI. That said, you don't get to that details UI very easily on Gutenberg either!

[getsource]

Per request by @antpb, double-checked to confirm, and all of the features mentioned in the issue description are still not present in Gutenberg.

Edit: Wondering if it makes sense to split these into separate issues for discussion and decisions on whether they belong/will be added for 5.0?

[antpb]

I'd like to identify the different parts to split out here. @getsource thanks so much for doing the discovery work here. I believe you mentioned recently that you have notes on the way we can split this out. If you could share here, I'd love to go that route.
Also I would imagine pull 7771 would be it's own issue too: #7771

7771 is really close to being merged but does not solve everything in this one. I think we should be tracking that bit separately.

[getsource]

#7771 is most of this ticket.
It includes both link rel and link css class settings.

• Open Link in New Tab now exists (added in [Enhancement] Introduce Link Target in Image Block #9520), so it doesn't need to be tracked by this anymore.
• "Edit image title" I don't think needs to be added anymore (or ideally isn't added), due to feedback from the accessibility team (See: https://wordpress.slack.com/archives/C02RP4X03/p1540501890000100).

Unless I'm missing something, I believe this means the only thing not handled there is attachment_fields_to_edit, which I think could use its own ticket for consideration.

[karmatosed]

After chatting in Slack today one potential solution now would be to avoid having everything in sidebar (it's getting busy there now) and have if required fields it open the media library. This isn't a perfect flow. What else could we do?

[getsource]

Thinking about this a bit more, I think having the fields in the media library might be problematic because we don't want them to appear to apply to all instances of the inserted image.

"Edit Image" before was that place for instance/post specific data to an image.

Edit: referring to rel and link css class above, not to attachment_fields_to_edit, which I agree could be handled with opening the media library. Apologies -- I think I misunderstood the context initially.

[getsource]

@Ipstenu created #11333 to split discussion for the attachment_fields_to_edit portion of this.

[gziolo]

#7771 was merged which adds link rel and link class to image block inspector.

[gziolo]

"Edit image title" I don't think needs to be added anymore (or ideally isn't added), due to feedback from the accessibility team (See: https://wordpress.slack.com/archives/C02RP4X03/p1540501890000100).

It seems like all issues were addressed in such case.