Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC1920: Alternative texts for stickers #1920

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@babolivier
Copy link
Member

commented Mar 8, 2019

@turt2live

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

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).

Incorporate wording suggestion
Co-Authored-By: babolivier <contact@brendanabolivier.com>
@Half-Shot
Copy link
Contributor

left a comment

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.


The current `m.sticker` event definition includes `body` as a description field for the
sticker. This allows clients to attach a short description of the sticker in an
event. So far this field has mainly been used to give a literal description of

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 10, 2019

Contributor

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.

## Proposal

Add a new optional `alt_text` field to the `m.sticker` event definition which

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 10, 2019

Contributor

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?


```json
{
"type": "m.sticker",

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 10, 2019

Contributor

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.

"w": 222
},
"alt_text": "The white Matrix logo over a black hexagon",
"body": "Matrix!"

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 10, 2019

Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 10, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.