A few options to consider,
- Continue to do what Parsoid is doing and put the class on the wrapper element. This will cause disruption when we enable the flag in T314318, as this task attests, but will keep the class in a selector friendly location.
- Move the class back to the media element. This should cause less disruption, since that's where the class used to be, but probably not no disruption, since we've changed the media structure. Specifically, we've added wrapper tags where none existed before and those may need to be factored in to previous selectors and logic. Since the class isn't in a selector friendly location, additional support may need to be added since :has() isn't widely supported, T287963#8198665.
- The idea from T287963#8205920. Put the class back on the media element, as in 2., but add an additional class to the wrapper element with a prefix (ex. mw-wrap-). This anticipates the problems of 2. and gets out ahead with a solution so that the entire structure can targeted if desired. It adds redundancy though, which may not be desirable.
- Do 2., but add a |wrapperClass= media option so that the wrapper can be targeted, if necessary, without all the duplication.
Note that doing anything other than 1. is going to break VE when ported to Parsoid, but that's not a blocker to rolling it out in T314318.
If we ultimately wanted the class option to be on the wrapper, as in 1., we could duplicate it there with a prefix, as suggested in 2. Then get all the wikis to migrate to explicitly asking for the wrapper placement with, |class=prefix-, and then eventually just drop the img class and cleanup all the prefixes.