If you inspect the page with the developer console (F12) it shows that they’re using 4 separate elements – one for each border;
- div 1 = top border,
- div 2 = bottom border,
- div 3 = left border,
- div 4 = right border
They’re initially hidden off-screen with transform: translate3d()
These styles are inline in the elements themselves, so most likely, they’re using JavaScript to watch page scroll position, and also (re)calculate each (new) translated position and write it inline, on the fly. This is what makes the border bars move in and out as the user scrolls.
I wrote a “Add Class to Target-Element when Trigger-Element is Scrolled into View” script which can be used to achieve something similar, although it doesn’t incrementally alter the border movement at each tiny scroll change. It either moves it in, or moves it out when triggered (no middle ground).
Here’s the blog and script demos http://blog.fofwebdesign.co.uk/41-add-classes-to-an-element-when-scrolled-into-viewport
And here’s a makeshift moving border demo using a simplified version of the script https://codepen.io/anon/pen/vaXqbX
