Start at the top of the page and very slowly scroll down until you see the two MacBooks sitting back-to-back. Consider that the graphic of those MacBooks is visible on the page but slightly dimmed, and as you scroll down the page, even from the point where you can barely see but 1mm of that graphic, it starts to brighten. I’m curious how to accomplish this in Blocs because when I use Fade In it takes a fair amount of scrolling down the page before the Fade In starts, and then in fades in rapidly. In other words, it’s quite different from what you see on the Apple MBP page.
Consider also the official Mac Mini web page here:
Look for “Part racehorse. All workhorse.” as you very slowly scroll down. Note there’s no dead space (space with no content) but the text is dimmed and then as you scroll down enough, it fades in to full brightness. Again, I am thinking how to accomplish the same in Blocs.
Why am I thinking about this? Because right now I see a lot of dead space (no content) before my Blocs Fade In kicks in. That’s true even on the otherwise fabulous template made by Eldar Gezalov here:
@Eldar please tell us why this works?
You start by adding padding and than by taking away the exact same account in the margin. Wouldn’t that bring it back to the same state?
Well, technically speaking, I am not removing the space after adding it. I am adding the space, and then moving the row with the content above. Basically it is overlapping the content before it, but because it is a simple blank space, it’s not interfering with it visually.
I haven’t tried it but the same could likely be achieved by adding a negative bottom margin to block above. I can tell one of them are relative and I’ll guess it’s the top one.
I say this because it’s something developers commonly do when we change the position of an element to relative in an otherwise block layout.
A practical and common use case
Let’s say you have a button and you want to move it up or down by some amount. Depending on your html getting the perfect distance for your design might be a little challenging, but many front end dev will change the css “position” property of the button to relative and move it up or down using ex. { top: 30px; margin-bottom: -30px} this effectively lets you move the element and also remove the white-space that’s created when you changed it’s position.
That’s right! when you move an object with relative positioning the dom actually holds that original space and you’ve got to remove it with negative margins.
@Eldar, I am impressed how say you don’t know code but you do my friend!
@Eldar I think this even makes it better on the mobile side. I love the scroll fade, especially on the desktop. With that said, some of the slower scroll fade effects on the small phone I didn’t like, it almost seems like the bloc is almost gone before it really fades in. This has led me to not use it as much as I’d like to. With this tip, it works a lot better.
I’ve already changed a couple of sites that I had turned off the scroll fade.
Well, I guess I can say that I know how to code, but only using the Google Translator, which is Blocs in this case. If you just tell me your technical explanation, I wouldn’t understand what’s happening, but if you tell me in Blocs language to ‘make some element bigger and move it’, I would do.
That’s nice to hear! I guess if we all agree that the timing of fade in effects is too late, maybe @Norm will adjust it in the future version of Blocs.
I spent a lot of the day yesterday fiddling with the padding and margin. The trick works, but it is quite fiddly to get it to work properly. In the course of my testing though, I found what seems to be a bug. I’ve written Norm about it, but he hasn’t been replying to me since last Friday, so maybe he is on vacation. As such, I’d like to post the problem here to see who else might have seen it.
I have a late 2015 5k iMac. Using “Fade in” or “Scroll in” on one of my JPG images triggers this bug which I will now explain, but only when Previewing in Blocs or the browser on a 5k iMac running with the standard 5K resolution. Shrinking the Blocs app window or browser window or decreasing resolution fixes the problem.
The bug occurs when scrolling down the page. My graphic should Fade in, but it doesn’t. Instead, the graphic just suddenly appears. The same thing occurs when I use Scroll in instead of Fade in. But if I make the window smaller, the problem vanishes and the graphic fades and scrolls in as expected. The same thing happens in Safari. Making the browser window smaller fixes it. And if I decrease my screen resolution to say 1080p, that too fixes the problem. The problem only affects LG mode. If I change to MD, SM or XS, there is no problem at all. It’s really boggling my mind.
Now here’s the real kicker. I didn’t have this problem when I first built my web page. But in the course of altering it as per this thread, saving, quitting and relaunching Blocs, the problem just appeared all of the sudden. I had been playing around with padding and margin using custom Classes, but even after I deleted all those classes, the problem remains.
I’d appreciate hearing your thoughts, especially from you 5K iMac users who can replicate the conditions I describe.
Yet another problem with the Padding=500, Margin=-500 fix/hack is that any text links in the Bloc above will often be covered up by the expanded row below and therefore become unclickable in SM and XS modes much of the time. It’s frustratingly unfortunate that we cannot apply Scroll FX like Fade In by breakpoint. In other words, it would be wonderful if we were able to enable “Fade In” for LG and MD but disable “Fade In” for SM and XS, as that would be a fix for this problem.
The only way I know to get around this problem (of my text links being covered up by the padding/margin hack) is for me to duplicate my Bloc and make the original display only in LG and MD and enable Fade IN for that, then make my duplicate Bloc display only in SM & XS and disable Fade IN for that. But when I have a huge amount of text in such a bloc, if I later want to edit, I must edit two Blocs which is messy and undesirable!
Of course, the best solution of all would be for @Norm to fix the root problem that causes Fade In to kick in too slowly, such that we don’t need to resort to the Padding & Margin hack at all. It’s especially problematic in the XS breakpoint, where I find my text fading in after I’ve scrolled through a large chunk of it – which means I cannot see the first paragraph or so of text!
I’m not very good with coding, but looking around I’ve seen that animdelay it suppose to take negative values too…using a negative would allow us to anticipate the animation, so we shouldn’t need anymore the trick from Eldar, that as other says it’s a solution but it’s causing other problems!
Do you think this would be possible to implement in the app??
If you need this now, I have released Scroll FX Extras, a bric that gives you additional animation options and great control over such things as delay, offset and duration. Additionally, if you’ve ever wanted to try different animations across an entire page (let’s say all your h2 tags) or all images in gallery etc… I think you’ll find it useful and potentially a nice time saver.
I’m addition to fade animation, you’ll add Slides, Zooms, and Flips to your arsenal.
Hi @casey1823, Yes, I will definitively provide some form of demo soon. I’ve been traveling and I return tonight. Hopefully I can have something to share within a few hours.
I second the need for a demo, but I propose that you consider joining forces with @Eldar to bring us a demo version of his Mac Mini template that has your brick incorporated, such that it more closely resembles the actual Apple webpage in terms of when the effects trigger as you scroll down the page. That would be very helpful for me to clearly see the practical usefulness of your bric, and I have little doubt it would greatly help others as well. Thank you.
