Checking the "Mark as decorative" checkbox discards existing alternative text and caption #82002

Activity

1. cbirdsong

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   [Block] ImageAffects the Image BlockAffects the Image Block

   on Aug 24, 2026
2. cbirdsong commented on Aug 24, 2026

   

   cbirdsong

   on Aug 24, 2026

   Author

   More actions

   Separate but related, it is also a bummer that clicking the caption button in the floating toolbar discards the caption:

   CleanShot.2026-08-24.at.17.22.18.mp4

   Maybe the solution to this could solve both?
3. Mamaduka commented on Aug 25, 2026

   

   Mamaduka

   on Aug 25, 2026

   Member

   More actions

   Separate but related, it is also a bummer that clicking the caption button in the floating toolbar discards the caption.

   I vaguely remember a related issue and discussion (unfortunately, can't find it now). The button works "Add/Remove Caption" and not as visual toggle, which can be the source of confusion. cc @ntsekouras
4. t-hamano commented on Aug 25, 2026

   

   t-hamano

   on Aug 25, 2026

   Contributor

   More actions

   Checking a checkbox should not immediately discard user content without warning.

   This concern was discussed when this checkbox was actually implemented. #78064

   I will quote some opinions regarding this.

   I like that the alt text field gets disabled if toggled. Do we need a confirm? You can always undo, yes? Mostly worried with confirm dialogs creeping in where we don't absolutely need them, they can be quite intrusive and are most useful if an action is truly destructive.

   There are other equally destructive actions in the editor that don't currently follow the proposed confirmation pattern making this inconsistent with how the editor already behaves.

   If it's that much extra work, it's certainly not worth it. And yes, there are other destructive paths that are similar - e.g., changing the number of columns in a columns block, that can have equally destructive consequences. Although I can't offhand think of an example that has equivalently non-obvious consequences - e.g., noticing that a link has been removed could be quite subtle, where noticing that a column of content has been removed is pretty obvious.

   cc @joedolson @jasmussen
5. t-hamano

   added

   [Status] In discussionUsed to indicate that an issue is in the process of being discussedUsed to indicate that an issue is in the process of being discussed

   on Aug 25, 2026
6. jasmussen commented on Aug 25, 2026

   

   jasmussen

   on Aug 25, 2026

   Contributor

   More actions

   I've no strong opinion on what the solution is, and would therefore recommend the simplest path forward, and defer to Joe if he chimes in.

   With that important deferral to stronger opinions, I nevertheless stand by what I said previously, which to unpack, can really boil down to this: undo works.

   

   In that sense we could be reductive and apply this overall issue as mapping to numerous similar flows, where checking a box, toggle or selecting an option in a segmented control is "destructive" insofar as it unsets a previous setting. The thing is, so long as undo works, and even revision history, those two in combination arguably serve as the generic solution to all of such cases.
7. joedolson commented on Aug 25, 2026

   

   joedolson

   on Aug 25, 2026

   Contributor

   More actions

   I think it would be helpful if unchecking the toggle restored any information removed by checking it, so that the data is restorable using the same mechanism that was used to remove it, as well as via undo.

   But I think that the removal of the information is correct. If the image is marked as decorative, then it must not have any content information, so the only appropriate action is to remove that content.
8. cbirdsong commented on Aug 25, 2026

   

   cbirdsong

   on Aug 25, 2026

   Author

   More actions

   Obviously it should not include any content in the front end while the checkbox is checked, but ideally it would store it somewhere so it can easily be restored later?
9. t-hamano commented on Aug 26, 2026

   

   t-hamano

   on Aug 26, 2026

   Contributor

   More actions

   I noticed that there are clear criteria in the design system for deciding whether to introduce a confirmation for destructive actions.

   https://wordpress.github.io/gutenberg/?path=/docs/design-system-patterns-destructive-actions--docs

   1. Does the action have an immediate visible result on the frontend?

      • If no → No confirmation needed
      • If yes → Continue to question 2

   2. Can the action be easily undone?

      • If yes → Use confirmDialog
      • If no → Use Modal with destructive button

   Even if the checkbox is checked, the alt text does not disappear immediately on the front end. Also, we can immediately restore the deleted alt text with Undo. Considering this, confirmation seems unnecessary.

   👍React with 👍1Reacted by George Mamadashvili
10. joedolson commented on Aug 27, 2026

    

    joedolson

    on Aug 27, 2026

    Contributor

    More actions

    I think that this situation could be a little different from what's documented in the design system. While those are true, I feel like they presume that the destruction consequences are obvious. In the case of an image with alternative text but no caption, there is no visible change, and a user does not know that this data has been removed. The fact that the alt textarea is removed from the view when the toggle is triggered doesn't actually inform the user that the text has been removed; it's common to conceal a field without removing the data from it.

    Maybe switching the textarea to disabled and removing the content would make this more apparent?
11. t-hamano commented on Aug 28, 2026

    

    t-hamano

    on Aug 28, 2026

    Contributor

    More actions

    Maybe switching the textarea to disabled and removing the content would make this more apparent?

    This is doable. In fact, this idea was initially implemented but was later disabled and removed during a review.

    #78064 (comment)
12. joedolson commented on Aug 28, 2026

    

    joedolson

    on Aug 28, 2026

    Contributor

    More actions

    And I think I probably would have agreed with that argument, but I hadn't really thought about the need to signal that this information has been removed.
13. t-hamano commented on Sep 5, 2026

    

    t-hamano

    on Sep 5, 2026

    Contributor

    More actions

    Maybe switching the textarea to disabled and removing the content would make this more apparent?

    We cannot express that the disabled textarea is currently disabled due to an unintended bug. I plan to try this approach once the issue is resolved. See #82454
14. Mamaduka commented on Sep 5, 2026

    

    Mamaduka

    on Sep 5, 2026

    Member

    More actions

    I think we can also leverage the setAttributes arg as a callback method and locally store previous values, then restore them on toggle. A bit more code, but probably cleaner than doing it as a side effect.

    We're doing something similar in packages/block-library/src/social-links/edit.jsx. It's only handled via an effect because blocks don't have direct access to the Styles toggle.

    👍React with 👍1Reacted by Aki Hamano
15. ntsekouras commented on Sep 5, 2026

    

    ntsekouras

    on Sep 5, 2026

    Contributor

    More actions

    The thing is, so long as undo works, and even revision history, those two in combination arguably serve as the generic solution to all of such cases.

    Personally @jasmussen 's rationale resonates with me. I think it would be fine to leave as is. That said, if we want to have a minimum fallback for in-session toggles, @Mamaduka suggestion seems good:

    I think we can also leverage the setAttributes arg as a callback method and locally store previous values, then restore them on toggle. A bit more code, but probably cleaner than doing it as a side effect.

    For the DataForm path (Block fields experiment), setValue already gets the current attributes in item, so it can read the old values. and maybe a new attribute with role: local (e.g. decorativeBackup) could work for both inspectors, so we'd have a single helper instead of a custom Edit for the field.
16. t-hamano commented on Sep 5, 2026

    

    t-hamano

    on Sep 5, 2026

    Contributor

    More actions

    I think it would be fine to leave as is. That said, if we want to have a minimum fallback for in-session toggles, @Mamaduka suggestion seems good:

    +1. I don't have a strong opinion on whether to implement the minimum fallback.
17. joedolson commented on Sep 8, 2026

    

    joedolson

    on Sep 8, 2026

    Contributor

    More actions

    +1. I also don't have a strong opinion; I can see arguments both for and against the minimum fallback.

    My previous arguments are on the for side; and I think those are valid. It's useful for a user to be able to reverse an action from the same place that they made the change, and it might help with awareness.

    On the other hand, it might give people the impression that they can reverse that action at any time - e.g., save their post, come back later, uncheck the box, and get the alt text back. E.g., that this is more of a "use alt text" toggle. Even that impression isn't all that harmful, though, because the information is still recoverable from revision history, if really needed.

    👍React with 👍2Reacted by Joen A. and Nik Tsekouras
18. ntsekouras commented on Sep 9, 2026

    

    ntsekouras

    on Sep 9, 2026

    Contributor

    More actions

    Thanks all for the discussion! It seems there are no strong opinions either way and both approaches have some trade-offs, so I think it's fine to leave this as is. Closing for now, but we can reopen if more folks feel we need the fallback.

    👍React with 👍1Reacted by Aki Hamano
19. ntsekouras

    closed this as not plannedon Sep 9, 2026