Fluid also with height size
Opened this issue · 18 comments
Could we set the heigth at 100% like width and grid area would be calculate to fill all the area without blank ?
I am going to leave this open because I think this is interesting and a possibility. Would need to work through how things would work...
Now that 2.0 has been released I am going to start working on an enhancements branch and see about getting this functionality in there.
I'm interested in a similar possibility. I would like it to fill the height of the screen and be able to scroll horizontally through more photos.
Drew - Should I check out 2.0 then? I am having a similar issue. I am finding the grid is redrawing all fillerboxes, when a new grid container is appended with boxes and mason is ran on another container. I made an addition. I randomly make the grid container float left or float right to change which side of the container the boxes align. It makes it slightly more randomized.. I wonder if this is making it redraw the fillers. Also, opening developer tools causes a window resize vertically, which redraws the fillers, but it doesn't need to because the height doesn't change the number of fillers, just width. Is that in 2.0?
I see that width is important, in re redrawing fillers, but is there a way to limit it to only when its needed, as in, only when the grid container changes width? Is that in 2.0?
Lazy loading with posts inside is SUPER HARD! Especially if you need to maintain any sort of order throughout each of the grid containers in the lazy load. It took quite a bit of AJAX. I am nearly there. Counting the fillers and getting the right amount of posts, and skipping the right amount of posts for non-fillers, is pretty darn hard.
dickendd - I recommend using the lazy load/infinite scroll demo, which is inside the project. Then adjust your "grid containers" to stack left to right, instead of top to bottom. Then the first grid container, match your page wrapper width and set a height, and make every grid container thereafter match that width and height. Rerun that on resize. Then setup whatever scroll functionality you need on the wrapper surround all grid containers.. i.e. allow yourself to scroll through grid containers.
http://www.localnationalnews.com/url-test/
Finally, got the posts in the right order. Counting and resizing definitely difficult. I had to use setTimeout's over and over..
thanks unaomnia, I will try that. for now I actually ended up setting the classes of the boxes for their image background via JavaScript and changing it every 15 seconds to filter through some different images and different layouts automatically. of course this requires destroying aand setting up the mason again each time.
Wow.. that is actually a really good idea! Empty and fill the same grid container and trigger resize! I love it. You wouldn't have scrolling in that case right? Height would change but not width?
I.E. Showing more or less pictures depending on the boxes inside the grid container?
For example if you use promoted sizes, the fillers change depending on the position of the promoted sizes.
Also, as I was trying to suggest to Drew earlier, you could try to randomize the promoted sized boxes dimensions as well. As in randomly sized promoted boxes. You could combine the two, achieving randomly placed and randomly sized boxes. But that goes all over the place with counting divs etc.
Also resize of grid container always triggers redrawing of the custom fillers. I.E. anything that causes the grid container to change size or position seems to be causing a resize. I am not 100% sure about this. But I did notice that floating the grid containers causes a lot of resizing. I am not sure if anyone else is seeing that?
Counting boxes and filling posts didn't work well for me.. I switched to putting post IDs (WordPress) into value attributes on hidden inputs, and then using JS to make arrays of those IDs, then turning those arrays into strings, of only unique numbers, and sending them over AJAX via
This seemed to work faster. More reliably. When I did counting and setTimeouts, it seemed like event if I made every setTimeout 10-20 seconds, it still wouldn't work reliably. Plus even 3-5 seconds is long during a lazy load.
I am not 100% sure how I could keep them in perfect order on window resize, when the columns change from 4 column to 3 column to 2 column to 1 column wide on the parent containers. The number of filler boxes and therefore number of posts would have to change, and the AJAX calls ran again - I suppose. For now I think I will let posts be duplicated (if more fillers are needed on resize) or skipped (if less fillers are needed on resize)...
I am noticing an issue on larger tablets such as the ipad when swiping downward. There is image flickering and it seems link the blocks themselves are shuffling positions.
Also is there a way to change the block sizes on a media query range like how you can set columns: for example [780,1080,3] and add 1,1 image sizes after the 3?
Thanks and let me know if I can clear anything up.
Hey @KTPH That is something I have noticed as well and it's how iOS7+ seems to change the viewport size so it's triggering a window resize, even thought it isn't. I am thinking about adding something that maybe sniffs this out and puts a hold on resize events for iOS devices until a full rotation is done which would fix this issue... I think ;)...
As for the ratio change / media query - this is actually very doable and an elegant solution would be to bundle it with the array that get's passed in so -
columns: [
[0,480,1],
[480,780,2],
[780,1080,3],
[1080,1320,4],
[1320,1680,5]
],
would become
columns: [
[0, 480, 1, 1.5],
[480, 780, 2, 1.5],
[780, 1080, 3, 2],
[1080, 1320, 4, 3],
[1320, 1680, 5, 3.5]
],
and if a ratio isn't supplied it would default to using the originally given ratio.
I am going to do some playing around and see about this and any issues that might come up from it.
Hey Drew that was fast. A desk warrior I assume! For the first part I will watch this git and see what you come up with, thank you and happy coding! As for the second part, I was more talking about adding the size values not the ratio.
So for example [480,780,2] I have 2 columns, and I would like to change all image sizes to 1,1 size so [480,780,2,1,1] so each row has 2 images side by side.
Right now it gets the 2,2 and 1,1 images I set, so some images are 100% width and others are 50%/50% side by side. I wanted to goto a more formal grid at the smaller device/screen sizes. (edited comment).
Thanks!
@KTPH ha you caught me at the perfect timing :)
I might be missing it, and correct me if I am wrong - but what if you set it to '[480, 780, 1]' that would mean that it's technically a 1 col grid and all elements will fall into that, or do you have a mixed use grid and not all elements are images?
I misspoke, I edited my previous comment.
Ahh so you're using promoted as well?
Speed in general could be better.. it is very slow loading overall for me..
Ted
312-292-6931
unaomnia.com
On Wed, Jun 3, 2015 at 12:33 PM, Drew Dahlman notifications@github.com
wrote:
Ahh so you're using promoted as well?
—
Reply to this email directly or view it on GitHub
#30 (comment).
Speed is on you, and your assets - the script is very small 4.573 kB
I find the callback sometimes fires when I don't want it to. That could
also be the "flickering" folks talk about. So, I think my goal has been to
use the destroy method. But can you should an example of how you would do a
lazy load that "destroys" the callback on the previously loaded grids, BUT
STILL allows for the fluid re-sizing effect?
That has been my main speed issue. The script is small but all it does is
make boxes, therefore I need to add more to make it useful at all. Loading
posts into the boxes, and adding any other styling or effects, is where
most my speed issue comes in. Mostly, I have to make scripts wait for other
scripts to finish, and usually the lazy load versus redrawing versus
resizing versus destroy etc, is where my timing gets confusing. So, I guess
an example that address the lazy load, resizing, and destroy method would
be cool.
Ted
312-292-6931
unaomnia.com
On Wed, Jun 3, 2015 at 12:38 PM, Drew Dahlman notifications@github.com
wrote:
Speed is on you, and your assets - the script is very small 4.573 kB
—
Reply to this email directly or view it on GitHub
#30 (comment).
+1