jae

note: this change will live tomorrow morning; it's too late in the day for me to be comfortable deploying

we are changing how thumbnails are displayed in posts with more than one image. currently, the aspect ratio of thumbnails in a row is decided by your browser and can't be predicted by us. this can lead to the attachment flashing briefly, as well as increased bandwidth use. we're making a couple changes to fix these problems.

what's changing

in posts with multiple images, a given row of images will use the aspect ratio of the largest image (width/height, not file size) in that row. this behavior will be visible in the post editor, so you'll always be able to tell what's going to happen once you hit post.

an example: if you have a post with two images (200x200 and 100x200), both images will be square in the thumbnail (200x200 wins). clicking through will still show the full-size image.

contrived and barely useful visual example, featuring some cats

this has no impact for posts with only a single image, those will keep displaying with their native aspect ratio.

how we're doing this

we're not currently storing width and height data for attachments, which are required for us to determine all this when we're displaying a post. for new posts, we figure out the width and height in the post editor and send that information up with the post. for old posts, we update our knowledge of attachment sizes the first time a user sees that post.

this means that the first time a user sees and old post we won't know the dimensions yet. in all cases where we can't calculate an aspect ratio, we default to 16:9. however, for old posts, you should only see 16:9 images once.

why we're doing this

like i said above, bandwidth is a big component here. bandwidth costs us money and users money. we have more changes we'd like to make for bandwidth improvements going forward, but this is the starting point.

this also includes some display changes that will make implementing inline attachments much easier for us down the road. (it's a high priority item, promise). i am personally a big fan of making shit easier for myself later.

we'll make another post once these changes goes live. it should improve the overall situation with attachments for everyone without being disruptive. if you have any questions, you can post on the support forum or comment here (comment replies are best effort).

details for unofficial API users below the cut

the start attachment call (/api/v1/project/:projectHandle/posts/:postId/attach/start¹) will accept width and height fields, although these are optional to avoid breaking existing clients. attachments uploaded without these fields will be backfilled just like old posts.

for optimal experience (avoiding any 16:9 display), we recommend populating these fields with a measured width and height, but excluding them shouldn't break anything. and yes, we do verify these numbers are correct, so don't try any funny business. thank's

1. jesus christ i didn't realize how long that URL was until i typed it out here