On Jellypotato...



  • I know we have onload for images (ew.), but does any modern browser fire off an event precisely the moment it determines a picture's dimensions?

    If so, we could hook in a listener that automatically shoves you up/down x pixels when the image reports its dimensions.

    e.g. link to post 8 in some topic, topic loads, and you are sent 500px down. Image in post 7 is 350px, and right when it starts loading, browser fires off "hey, img in post 7 is 200x350", and NodeBB kicks you down 350px so now your scrollTop is 850px.

    Can't use onload 'cause it only fires after the asset is loaded completely. So if you're on a bad connection or the asset is huge (hellooo 16mb photos), then onload fires way too late.



  • Maybe I can play with some documentFragment or off-screen element shenanigans to pre-load the image and then add it to the post... hmm...



  • @julianlam I looked into this a few days ago and it looks like there's no event for it. You'd have to grab all the !complete images and requestAnimationFrame until the naturalHeight property is set.



  • More off-the-wall ideas

    • Maintain a LRU cache of image urls and their heights
    • If image is in cache, set min-height styling on image
    • Otherwise, proceed as normal (send html that may cause jellypotato) but request image from server (in background) and save height to cache...


  • @julianlam I'm no html wizard, but why not have a default width and height for all images, set in the img-rag. If the inage is smaller than these, you'll detect it during upload, and can adjust the tags accordingly. This way you don't have to wait until the image loads, just the page with the tag.

    ... As a user I also do not have to be bombed with a gigantic yoghurt man, which must count as a plus.


  • Winner of the 2016 Presidential Election

    @Mikael_Svahnberg said:

    @julianlam I'm no html wizard, but why not have a default width and height for all images, set in the img-rag. If the inage is smaller than these, you'll detect it during upload, and can adjust the tags accordingly. This way you don't have to wait until the image loads, just the page with the tag.

    ... As a user I also do not have to be bombed with a gigantic yoghurt man, which must count as a plus.

    Yeah that's actually not a bad idea. And it could be used for the plugins too - keep track of the height of the image/onebox and just render a div of that size. Obviously more difficult for the iframely plugin because arbitrary size, but the only things that would take a while to load for that would be images and videos, both of which you should be able to keep track of the size for


  • Winner of the 2016 Presidential Election

    @sloosecannon actually I think nodebb limits maximum size of images (cc @julianlam?) in posts so you could just make a container of that size for the image (and modify that for user-specified sizes/classes like class='emoji')



  • @sloosecannon not to my knowledge, and even then, there's the ability for a user to specify an image via direct image link, so that's more difficult.

    We limit a picture's size by width only as far as I know



  • @julianlam said

    there's the ability for a user to specify an image via direct image link, so that's more difficult.

    This is not the default use case, though. If you fix the default, you will have removed 99% of these reasons for jellypotatoing.


  • Winner of the 2016 Presidential Election

    @julianlam said:

    @sloosecannon not to my knowledge, and even then, there's the ability for a user to specify an image via direct image link, so that's more difficult.

    You could try to get some preliminary post sizes using PhantomJS. As in, when a post is made render it in Phantom and grab the sizes from its DOM, then save it as post metadata. Tested it once, it was damned close but insufficient for a complete solution, but it could work for correction purposes only.

    The question of course is: is it worth the overhead?



  • @Onyx The moment you suggested PhantomJS, I noped out. The overhead is insane and requires a ton of dependencies, some of which require compilation... that in and of itself is a non-starter and I didn't even get to the overhead of maintaining the logic :smiley:

    You bring up a good point however, in that I had not considered that some pictures would have their height adjusted if their width was greater than the post container, and then now we're getting into browser viewport and mobile responsive issues :laughing:


  • Winner of the 2016 Presidential Election

    @julianlam Yup, responsive is where it gets tricky without insane hacks. Well, you use only two layout, yes? That does make it a bit easier at least, if you had separate ones for md and sm as well... ugh!



  • @julianlam we could have an "I hate jellypotato" mode were all images are forced to a certain size no matter what happens. Maybe with a button to unleash them into normality. that would break image emojis


  • sockdevs

    @julianlam The best I could find is essentially polling to see if the document size changes (which it will as images load), but that'd just kill mobile batteries



  • Make the images a fixed size and if someone is curious pop into a new window on click. A lightbox if you want to annoy me.

    Also make the width of the image relative to the width of the post. Its retarded to see pictures or videos that expand past the screen egde and you can't scroll to see the whole thing on mobel.



  • @julianlam You'll save yourself a lot of headaches by thumbnailing things with click to expand. Set a max height to a typical empty post size (250x250, 300x300 px or so?) and load the image into a placeholder div so you don't shuffle truffle all over.

    People will appreciate (in general) not having mega super sized images that move the entire topic, and still have easy access to the full size image if they want to look at it. You could even make it a profile option if you're feeling frisky to allow the truffle shuffle (IE: do not restrict image size by default)


  • :belt_onion:

    @Matches said:

    thumbnailing things with click to expand. Set a max height to a typical empty post size (250x250

    this.

    @Matches said:

    You could even make it a profile option

    win win.

    • jellypotatoless mode


  • How about using a default size until the image is loaded, then adjusting if necessary at onload? A max size is still a good idea IMO, but you don't want to enlarge 30x30px images into a default size.



  • you can make image onload reset or set a timer, and after 500ms without shuffling scroll to the desired post


  • sockdevs

    @fbmac So the user has to wait for all the images to load (which could take several seconds) before seeing the post they want to see? If anything, that's worse than what we have now!



  • This post is deleted!


    • Render the entire page server-side
    • Adjust for height as needed (interrogate user's height/width and serve to a cookie-setting web service. Fire this check on window resize)
    • serve up images as inline data:image instead of external image requests

    Done. No additional js fuckery needed, aside from the webservice.



  • @Lorne-Kates

    • Everything's broken because some people have browser zoom turned on

  • sockdevs

    @fbmac Right, what you're saying is it's quick for you, so fuck everyone else



  • @RaceProUK no, thats your shoulder aliens. I'll delete that post you didn't like



  • @RaceProUK it could be combined with the other things people suggested to mitigate it



  • @Matches said in On Jellypotato...:

    @julianlam You'll save yourself a lot of headaches by thumbnailing things with click to expand.

    This is genius. I quite like that, though smaller images will still jellypotato unless we... use flexbox to make it centred vertically!

    I imagine it would apply to block styled images only.



  • @Onyx said in On Jellypotato...:

    responsive (...) without insane hacks

    E_DOES_NOT_COMPUTE



  • Is it possible to make an off screen post be in a fixed height div and then take the height off once it is visible?


  • Discourse touched me in a no-no place

    Jellypotato needs to become the industry standard term for this behavior.

    That is literally all I have to say about it, because I don't do UI's.



  • @boomzilla said in On Jellypotato...:

    Is it possible to make an off screen post be in a fixed height div and then take the height off once it is visible?

    Only if you wait for all it's remote content to be loaded.



  • @PleegWat Why the need to wait? Honestly, I'd expect that most of the time people wouldn't scroll up so out would never be an issue.

    I guess I should clarify, only do that for posts above where you came into the thread.



  • @boomzilla I think I see what you mean. The problem (referenced upthread) was that as long as not all external resources have loaded, the rendered height might still change.



  • @PleegWat While stuff is higher on the page where you can't see it, who cares? Put it in a fixed height div with overflow set. If the user scrolls up, take that styling off and let the browser do whatever it wants at that point. Because at that point you'd want the content you're viewing to push stuff down.

    I know discourse had some sort of knowledge of what was visible for read tracing purposes, but I'm not knowledgeable enough to know how that works exactly. Or how well dynamically messing with styles would work.



  • @boomzilla @julianlam this idea looks like the best one imo



  • Two other forums that I'm on have some clientside logic. Whenever you post an image (through [img]), they'll do a clientside GET of the image URL and then determine it dimensions. Shortly before the post contents gets submitted to the server, the image gets replaced by a version that has width and height attributes on it if none were present before.

    It works like a charm and prevents a lot of jellypotatoing.



  • @AlexMedia i know discourse did it because when i referenced images from a network that had its url blocked the post would show wrong sized for everyone


  • Discourse touched me in a no-no place

    @Matches said:

    Set a max height to a typical empty post size (250x250, 300x300 px or so?) and load the image into a placeholder div so you don't shuffle truffle all over.

    This is a good idea, but it should use sensible breakpoints for different devices.



  • @AlexMedia said in On Jellypotato...:

    ... [T]hey'll do a clientside GET of the image URL and then determine it dimensions. Shortly before the post contents gets submitted to the server, the image gets replaced by a version that has width and height attributes on it if none were present before.

    That was my original idea, but that has two serious problems:

    1. You're assuming the submitter's viewport is of a standard, sane size, and is identical to everybody else's (e.g. 800px width image scales down to 400px width when it is added to page, but user B loads and gets a 400px width image when his 2560px megaUltraLumixHD monitor can accommodate all 800px)
    2. You're implicitly trusting user reported data, which is a no-no. Someone like @Lorne-Kates might mimic the call with their browser and set the image width to 9999px and height to 99999px, and then you're in troublethe fun begins :smiley:

    Edit: I picked the name out of a hat, don't hurt me.



  • Just to take a step back here, why is there content above the target post at all? You're already sending us to the post before the one we were looking for (a decision I agree with btw, I'm not complaining), couldn't you mitigate 99% of the :sweet_potato: by only having 0 or 1 additional posts present before that?



  • @julianlam but @boomzilla idea seems like it would work



  • @fbmac You're right, that's much simpler to mock up and test for viability.

    Good :bike::house: everybody! Let's do this again sometime...



  • @julianlam said in On Jellypotato...:

    You're implicitly trusting user reported data, which is a no-no. Someone like @Lorne-Kates might mimic the call with their browser and set the image width to 9999px and height to 99999px, and then you're in troublethe fun begins :smiley:

    If you're really worried about it, you can check the submitted image dimensions and scale them if they're large.
    But I think you're worrying about something irrelevant. What's there stopping me from just hotlinking to a 1x99999 png?



  • @julianlam said in On Jellypotato...:

    Edit: I picked the name [Lorne Kates] out of a hat, don't hurt me.

    It's more likely to be one of my Dwarf Fortress screenshots that contains the entire 200 year history of a fictional world.


  • Winner of the 2016 Presidential Election

    @Salamander said in On Jellypotato...:

    @julianlam said in On Jellypotato...:

    You're implicitly trusting user reported data, which is a no-no. Someone like @Lorne-Kates might mimic the call with their browser and set the image width to 9999px and height to 99999px, and then you're in troublethe fun begins :smiley:

    If you're really worried about it, you can check the submitted image dimensions and scale them if they're large.
    But I think you're worrying about something irrelevant. What's there stopping me from just hotlinking to a 1x99999 png?

    No, it's a bad idea in general - What if the image file you're linking to has a size change?

    I think the "restrict thumbnail size and click to see full-size image" idea is much better and probably simple to implement - without those kinds of gotchas



  • How often does an image's size change without also getting a different URL? Extremely rare in my experience, and it's usually because the image itself was completely changed. I've only heard of it happening when one site links to another site's images without permission.
    Your suggestion, having to click each image to see it normally would get very tiring very quickly. If I wanted RSI that badly I'd play those clicker games instead.
    Boomzilla's idea has neither of those issues, but instead requires more effort to determine if something is visible, which so far seems to be best tradeoff.



  • @Salamander @Lorne-Kates would like to show you his favorite XKCD comic.



  • @ben_lubar said in On Jellypotato...:

    @julianlam said in On Jellypotato...:

    Edit: I picked the name [Lorne Kates] out of a hat, don't hurt me.

    It's more likely to be one of my Dwarf Fortress screenshots that contains the entire 200 year history of a fictional world.

    Ok, so it's not 200 years, but here's part of a world's history:
    https://what.thedailywtf.com/topic/19496/world-history



  • @ben_lubar It's extremely relevant.



  • @julianlam said in On Jellypotato...:

    @Matches said in On Jellypotato...:

    @julianlam You'll save yourself a lot of headaches by thumbnailing things with click to expand.

    This is genius. I quite like that, though smaller images will still jellypotato unless we... use flexbox to make it centred vertically!

    I imagine it would apply to block styled images only.

    Big thumbnails, then. Otherwise: no more memes.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.