-
Notifications
You must be signed in to change notification settings - Fork 396
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
MSC4230: Flag for animated images #4230
base: main
Are you sure you want to change the base?
Conversation
|
||
## Proposal | ||
|
||
We add an optional boolean flag, `ia_animated` to the `info` object of image events indicating if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify, this field would be allowed in the info
on msgtype: m.image
and type: m.sticker
events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess just images for now: clarified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason not to allow it for stickers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure to be honest, which is exactly why I'm leaving it for someone else to propose if they think it's appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that stickers are ~renamed images, I agree with Sumner that the same should apply to stickers.
We don't have extensible events yet, but MSC3552 goes in the same direction about the images and stickers relation ship.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, let's do it for stickers too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid I am somewhat drowning with other commitments at the moment. If anyone would like to propose an update to this that would encompass stickers then please go ahead, otherwise I will put this on the back burner for a bit.
Co-authored-by: R Midhun Suresh <[email protected]>
|
||
Clients may lie about the flag which would cause unexpected behaviour, for example, an image which | ||
was not presented might then animate when the user clicks to enlarge it, allowing for 'jump scares' | ||
or similar. Clients may wish to prevent images from being animated if the flag is set to false. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be sensible for an implementation to use this flag only as a hint as to whether it should preload the original, and probe the media regardless of when it was downloaded to confirm the animation? I feel like this MSC is recommending a client behaviour that is a tad too "trusting".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They could do that if they saw a need to. I've tried to be specific though and call out a distinct case where clients might want to take care over. I don't think it's really the spec's job to enumerate every detail that clients might possibly mess up, although we can certainly give more hints if you think there's something else worth calling out.
|
||
## Proposal | ||
|
||
We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to bring it up, we could also give this flag a more general name prefetch_original
to express "you might wanna prefetch this", and apply it optionally to any attachment type. A client might assume based on the attachment type, mime type, flag, and other metadata combinations, whether it wants to prefetch, e.g. to play an animated image/gif without delay. Then again I fail to come up with other reasons you might want to hints about prefetching attachments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I'm more persuaded by the idea of giving information about the media rather than trying to second guess what the client might want to do.
Co-authored-by: Will Hunt <[email protected]>
This is implemented in Fractal too as of today: |
As per discussion on element-hq/element-web#28311 and since this now has 2 impls, I'm going to @mscbot fcp merge |
Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands. SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable. Checklist:
|
@mscbot concern Checklist incomplete (I haven't attempted to pre-populate it this time, sorry) |
If this flag is `false`, receiving clients can assume that the image is not animated. If `true`, they should | ||
assume that it is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The strength of these statements is not quite clear to me in relation to the SHOULD when sending images. Do you intend for "can assume" and "should assume" to translate into "MAY assume" and "SHOULD assume" in the spec?
|
||
## Proposal | ||
|
||
We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated thread: how would this work with inline emojis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
emojis are not animated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Emojis can definitely be animated. Might be better to leave adding a new attribute like data-mx-animated-emoticon
to a different MSC though (perhaps MSC2545, or a completely new one, or reuse the data-mx-emoticon
attribute by giving it a value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be that we're using different definitions of "emoji". Are they not just a unicode codepoint? (Which, sure, a client can animate if it wants to be cute, but that's not something we need to represent in an event body)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming the question was about custom emojis, which are inline images (<img>
tags in formatted_body
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was definitely not clear from the question! But yes, that sounds like a question for another MSC, given that such things aren't yet specced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also seems irrelevant since there would be no thumbnail support here anyway.
Since animated images are thumbnailed to a still image, clients need to download the full | ||
image in order to display it animated. However, there is currently no way of telling that | ||
an image is animated without downloading the original image. This means that clients wishing | ||
to display the image as animated must download the original image for any image format which |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does "display the image as animated" mean? An annotation in the UI? Or actually making an animated thumbnail?
Either, I guess. Would be good to be clearer though.
image in order to display it animated. However, there is currently no way of telling that | ||
an image is animated without downloading the original image. This means that clients wishing | ||
to display the image as animated must download the original image for any image format which | ||
is capabale of being animated. This means they download the full size image for non-animated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is capabale of being animated. This means they download the full size image for non-animated | |
is capable of being animated. This means they download the full size image for non-animated |
|
||
## Proposal | ||
|
||
We add an optional boolean flag, `is_animated` to the `info` object of `m.image` events indicating if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
emojis are not animated?
## Potential issues | ||
|
||
Clients may lie about the flag which would cause unexpected behaviour, for example, an image which | ||
was not presented might then animate when the user clicks to enlarge it, allowing for 'jump scares' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"was not presented"?
|
||
## Proposal | ||
|
||
We add an optional boolean flag, `ia_animated` to the `info` object of image events indicating if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, let's do it for stickers too.
Other than the nit-picking, this looks good to me, except that I agree with the "let's extend this to stickers" thread. |
Proposes adding a boolean flag to images that indicates whether they're animated.
Impl: element-hq/element-web#28513
Rendered
Disclosure: This is presented wearing my, "Element Employee and Element Web Engineer" hat.
FCP tickyboxes
MSC checklist