The width, height and duration properties are basically required for the redaktor client.
Reasons:
width, height
We do not want to disrupt/tatter/break the aspect ratios of esteemed users images by putting them in a square and for a masonry layout, we need at least to know, if it is “landscpe”, “square”, “portrait” – and:
For performance benefits (e.g. in card stream or row overview), the media is loaded via Intersection Observer.
So, for a pleasant visual experience it is required that the concrete aspect ratio is known in order to paint the box.
duration
If we have media without metadata like in WebVTT, we can also load Audio/Video by Intersection Observer and setting preload="none" – but we would still like to show the duration above the post …
So:
If any of those arrives at redaktor server, it can measure and enhance the object.
It might be supernice, if we know it in advance (I agree with 99.9% of the protocol but this would have been a must for me …)
How about other servers?
@grishka @bashrc
How do other client devs handling this?
I get the dimensions for such images when I first download them, which happens when the user first sees that post. The unfortunate side effect of that is that if an image is not downloaded yet and didn’t have width/height, it can’t be laid out properly and so is assumed to be square. So you see a post with cropped images, then you refresh the page and then you see them properly laid out. I of course do always send width/height for my own images.
I don’t properly support any form of video yet. I simply put whatever URL there is in the object into a <video> tag so video posts aren’t empty.
1 Like
I see.
The redaktor nodeJS server did measure for each incoming image and then “enhanced” the objects.
Just for this 3 properties.
And I am thinking about if it should really enhance the objects (technically it’s just adding info which is basically already in the post, just not in text but it also “changes” the original JSON).
It’s easy for me — I don’t store the original JSON anywhere. I parse it immediately and from then on only work with my own internal representation, ignoring whatever parts I don’t understand. For when I need an ActivityPub object, I generate the JSON on the fly. This does show in places like Accept{Follow} — I won’t return any custom fields you put into the Follow for example.
Currently, Epicyon does not try to do anything with attachments on inbox posts. These are links, and are displayed as links. So it doesn’t attempt to download or cache images (except for avatar images), it just displays them directly from their original source.
Metadata about dimensions could be added to the post at the time of upload.
1 Like