OriDomi inaccurately alters width of element

[crowjonah]

Hi there! I've been having quite a bit of fun with OriDomi – thanks for making it available to us. I have, however, encountered an issue with one implementation in particular that I was hoping to execute: I would like to have an OriDomi overlaying another aligned element, such that folding it up would more or less seamlessly reveal what's beneath. Unfortunately, after OriDomi has done it's magic on my overlay DOM element, it no longer aligns with what's beneath. You can see more specifically what I'm talking about in this fiddle: http://jsfiddle.net/crowjonah/8vn7r/

You'll notice that if you comment out the OriDomi JS, the vertical columns line up perfectly.

Let me know if you have any suggestions for me!

[dmotz]

Yeah this is a known issue and a side-effect of what OriDomi does to compensate 3D transform glitches. When rotating two elements that are aligned flush with each other, you'll see small 1 pixel gaps between the two at certain rotation values which ruins the illusion of the composition being a single contiguous element being folded. Even with the compensation OriDomi does to counteract it, you can see this behavior more often in Firefox with a lot of the demos.

OriDomi nudges each panel 1 pixel back so it overlaps its predecessor sibling to prevent these gaps. You'll notice in your own example that the offset gradually increases with each panel.

Here's the relevant spot in the source (notice the translate variable): https://github.com/dmotz/oriDomi/blob/master/oridomi.coffee#L665

If you change it to zero, you'll notice the "gap effect" much more often.

I don't have a good solution for this issue right now. It's currently a tradeoff between dimension accuracy and avoiding this ugly effect. I might make the nudging amount configurable in the API if that would help your situation.

I'll keep this issue open if anyone has an idea for a solution.

[dmotz]

As a simple hack-based workaround, you could manually set the width of the overlaying OriDomi element to be slightly larger than 100% of the element underneath so it correctly lines up.

[crowjonah]

I forked the code and started to hack at it after posting this issue – I had an idea to conditionally skip the translate[X/Y] +/- 1 if the angle was 0, thinking that the aforementioned gaps wouldn't occur when the transformation was flat, but then the width of the OriDomi element and its panels was actually more (rather than less) than the original! If I have a moment, I might keep digging on that.

[Gabrielmtn]

Can anyone watching this flesh out an idea I had on fixing the flicker / gaps. I was wondering if / how border animations to each section to allow the gaps to appear less obvious?

[dmotz]

@Gabrielmtn What are the details of your idea?

[Gabrielmtn]

To quote the solution the folks who created the HexaFlip project: "You may notice that the height is set to 100.5%. This is done to add some extra “bleed” to the size of each face to mitigate a common issue seen during 3D CSS transforms where edges don’t match up perfectly and “cracks” appear in the object. Each face is given absolute positioning so they stack on top of each other before they’re transformed in 3D space."

So the idea would be to create some kind of border bleed for each panel to distract from the gaps.

(referenced project) http://tympanus.net/codrops/2013/03/07/hexaflip-a-flexible-3d-cube-plugin/