MSC1920: Alternative texts for stickers

[babolivier]

Rendered

[turt2live]

This looks pretty sensible to me. Might be worth considering how this looks like in an extensible events world, but that can also become a problem for extensible events and not here.

[rxl881]

Looks good to me too (thanks @babolivier).

As you suggest @turt2live it probably overlaps with extensible events, but I think we can probably ignore that for now (and leave it to be solved as part of the bigger case, in due course).

[Half-Shot]

I'm totally onboard with finally specifying alt text, but I think this is far too loose of a spec and it makes me sad that m.image/m.audio/m.video won't get the same treatment.

[Half-Shot]

It's unclear to me what the bodys role is now? You've stated that the body is used for something similar to alt_text but is not used exclusively for that. This implies that body needs to be more strict about what it cannot contain (not things that are suited for alt_text).

I worry this PR is going to leave people trying to support both body and alt_text, and without a clear seperation of what they are, will end up duping the values for both.

What I want to see is:

• What you think body should and shouldn't be used for?
• What you think the "alternative text" is for the image (if you want to reference alt from the HTML spec, please do but make it explicit that you are copying that.

[Half-Shot]

Was there a reason not to mirror alt of HTML. alt_text looks clunky next to body (as then I'd argue for body_text?

[Half-Shot]

By and large, I also think this spec applies to m.image and it's a shame we are going to skip it entirely, or spec the same thing identically. This is more of a crapness of having stickers be near identical clones of m.image where they should have really been a superset, and inherited it's kets.

[Half-Shot]

Small annoying nag, but "Matrix!" doesn't fit the spec of body "a message to accompany and further
describe the sticker". If we are going to include the sticker body, let's be consistent.

[Half-Shot]

Oh and I think we do need to consider this with extensible events, or at least include a comment as to why we aren't considering it in the proposal. (Yes extensible events are a proposal and not canon, but to pretend it doesn't exist is frankly silly given how much thought has gone into EE) It makes me slightly mad that extensible events are a prime target for including an alt type that could be used for many other types of events.

Anyway grumpy half-shot is grumpy over stickers.

EDIT To clarify, I'm mad over EE still not existing, not this proposal.

[babolivier]

Context on where this proposal comes from: when the Stakey stickerpack landed the other day, @rxl881 was enjoying how better it was that the body for most stickers in this pack are funnier and nicer texts than the neutral descriptions we have for most stickerpacks, and I was complaining that it was weaker accessibility-wise, because it was accompanying the visual message rather than describing it. Both of us agreed with each other's point and we concluded that it would be better to have one field for each type of text.

[dkanada]

I'd really like a flag in the message to hide the body as well to be honest. Line has stickers without associated descriptions and they work quite well in my experience. I use a few custom sticker packs without text added, so the alt text is super annoying to deal with on all the clients.