Partially hide really long comics and infographics

Not sure if this has been brought up before or not.

Some posts, which merely consist of an image and a couple paragraphs of text will be partially hidden, prompting the user to “show more”. Meanwhile, very long image posts such as comics and infographics (which can be very popular to re-share) are always in full view.

Can we implement a trigger of some sort, based on the height of an image in pixels, that would partially hide a post?


Note: This discussion was imported from Loomio. Click here to view the original discussion.

I totally back this. I am so tired of trying to scroll past this crap. I have noticed that if you view it once then refresh your page it ends up in a “Show More” thingy sometimes though.

This only happens for long graphics embedded with Markdown as they usually take so much time to load that the code determining the height of a post has already run before the graphics finished loading. When refreshing the page, the graphics are loaded from cache and though are fast enough that Diaspora can determine their height, notice them being to high and hiding them.

https://github.com/diaspora/diaspora/issues/4646

I think the intended behaviour is that these images are hidden behind the ‘show more’ bar, at least on second and subsequent viewings, so I don’t think there’s a need for a Loomio discussion/vote in order to pass this - it just needs someone to code it. (I’m not saying you did something wrong in starting this discussion, just that I don’t think it’s necessary to have a long discussion before taking action on this.)

what about a kind of spoiler, optional?

That’s really interesting what @trollischmittlauch says about the causes of this. I’ll post a link to that comment on the Github issue for anyone who wants to fix this.

I’d like to know what exactly triggers the “show more” link when a single image is posted. Is it about the height or the file size? Where is the threshold?
I find really odd to have reasonably sized picture (500-800px) partially hidden when kilometer high strips always get full display. I’m not saying that the latter should be banned or anything (I like some of them) but there’s obviously a problem here, especially when browsing D* on a phone.

Xophael, see the earlier comment from Trolli Schmittlauch.

The ‘show more’ bar is implemented if the height of the post is greater than a certain point (I think it’s 200 pixels - I dug around in this code a while back but my memory is now hazy). Trolli explains - and this seems reasonable to me - that these long comics are shown in full because the code to determine the height of the post runs before the image has loaded.

My personal preference - and I think this is how the code is intended to work - would be for all posts to be shown in full the first time they are viewed by a particular user, but on subsequent page loads by that user, all posts over the max length are collapsed behind the ‘show more’ bar.

It is this function here:

the code is always executed after the post is rendered. small images that load fast enough or come from the browser cache are already loaded at that time, thus their height is known. If a huge image like infographics take longer for loading, their height is not known, therefore the post is not collapsed.

Hm, I’ll do some testing and see if I can find some working crossbrowser css/javascript solution that cuts all posts as they grow bigger than x pixels. An optimal way would however be to check the dimensions of the fully loaded post and its images and provide those when saving to the database - if developed pretty we could then get rid of the “jumping stream” that occurs when one is in the middle of a stream as the images load too. These ideas are on a theorethical level so far though.

If it is possible to fetch the dimensions of an image before downloading it, that could be used to calculate the height of a post before the collapsing is run.

It isn’t possible as far as I know. Some image types may have flags in the beginning so that one could read the dimensions before the whole image is loaded, but that would require some sort of manual image loader, which would be a whole new project by itself.