Follow-up for #2924391: how to remove override and revert back to the inherited/original metadata

I believe #2924391: [media entities] Regardless of @EntityEmbedDisplay plugin, Media entities representing a `image/*` MIME type should be able to have a per-embed `alt` and `title` actually introduced a usability bug. If you create an override, currently there is no way you can restore the original text (i.e. un-override what you did) from the same place you did it.

One way of solving it would be to expose something like a link or button "Revert/Remove override" (or better wording) that removes the overridden value and populates the form element with the original alt text?

If alt isn't required, you can simply remove the text in the alt in the dialog and it will go back to displaying the original. But this isn't possible if alt is required. It's also not documented. I think a button next to the alt and a button next to the title [Restore] would work. There is a work around, which is to remove embed and re-embed it.

Now that I think about it, I think a button is awkward. The original alt can just be added to the form somewhere hidden, and with javascript, it will be restored when you tab way from the field and the field is empty.

This is the exact same problem that media in core will (have to) solve in #3023807: Override media fields from the reference field, eventually.

Quoting #3023807-9: Override media fields from the reference field, on the UI aspect of it:

Each overriddeable value will follow what we termed the "machine name pattern", in that the default value will be displayed as a label, with a link or button that says "Edit" (or "Override" -- the jargon is not fleshed out yet) next to it. When you click that button, the value will be instantly displayed in a form field instead, allowing you to change it, and the Edit/Override button will disappear and be replaced by a "Restore default" (or "Revert" or something...again, don't worry about terminology yet) button that, if clicked, will disappear the form field and display the original value as text.

I wonder if we can't experiment with the same approach here, which would be also valuable for validating the approach for media in core?

Now that I think about it, I think a button is awkward. The original alt can just be added to the form somewhere hidden, and with javascript, it will be restored when you tab way from the field and the field is empty.

There may be legitimate use cases where users might want an empty alt. I'm not sure however how often in real life an image would have an original alt set, but editors would want it to be decorative in some places (the example for having an empty alt)... It's true that we could inform them that something like "" can be used to convey the meaning of "I want to override the original with empty alt here", but maybe an explicit action is clearer?

Here's a patch where upon tabbing away from alt field, if you have left the field blank, it restores the original alt. The same thing with the title field.

Oh, and by the way, if want to leave the alt empty, you can put in two double quotes.

Adding test coverage.

Here's an update that changes it to use the placeholder attribute. It really isn't any different. I thought maybe we should only restore the alt or title if that field is required, but I think it unnecessary, since on the backend it will be doing it anyway. By restoring it in the dialog you make explicit what was previously implicit. Where if the title is not required and they empty it out and it displays the placeholder, but doesn't set the value back to the placeholder, then the UX may be giving the false sense that it won't display the original. It's an easy change to check if it's required and only restore it if it's required.

Another approach would be to not set the placeholders to the values until mousedown on the "Embed" button.

Here's a version with the approach proposed in #15. Although this begs the question, "Why is alt marked required, if it will be set to the fallback when left blank?" Shouldn't we just not make it required?

Even though the field is required on the original image field, perhaps it shouldn't be in the entity embed dialog, since it will fall back to the original value anyway.

Here's a different approach based on this notion in #16:

Why is alt marked required, if it will be set to the fallback when left blank?

This patch removes the required attribute, and simply adds a placeholder. The switching back to the original doesn't need to be in javascript, as it's already happening on the backend.

Oh dang. I knew there was a '#placeholder' attribute. I was searching the codebase but was searching for 'placeholder' (with single quotes wrapped around the word).

• Adds #placeholder
• removes unrelated change
  

  -      // Setting empty alt to double quotes. See ImageFieldFormatter.
  -      if ($settings['title_field_required'] && $title === '') {
  -        $title = static::EMPTY_STRING;
  -      }
  

• Takes the idea of #17 (not setting default values, but keeping them in the placeholder) even further. We don't need to set the value either.
  

  -      $alt = isset($attributes['alt']) ? $attributes['alt'] : $entity->{$image_field}->alt;
  -      $title = isset($attributes['title']) ? $attributes['title'] : $entity->{$image_field}->title;
  +      $alt = isset($attributes['alt']) ? $attributes['alt'] : NULL;
  +      $title = isset($attributes['title']) ? $attributes['title'] : NULL;
  

  The placeholder is clear enough.

🎉Thanks Nate and Wim! 👏