HypeIntersectEnabler_test.hype.zip (19.6 KB)
I deleted some code from the drag-and-drop-enabler and the result should be a “HypeIntersectEnabler”.
Works without custom coding.
When an intersection of two hype elements is false or true a Hype-custombehavior (defined by a data-attribute) will be triggered …
Usecase could be to start an animation, switch a scene, load some additional data … and so on …
On a targetelement set two data-attributes:
data-intersect -> true
data-intersecttarget -> className of a sourceelement ( -> the elements on which an intersection with the target should be checked ...)
On a sourceelement set a
corresponding class and two data-attributes:
data-intersectcustombehavior -> name of a Hype-custombehavior to be triggered //optional
data-intersectoffcustombehavior -> name of a Hype-custombehavior to be triggered //optional
if you’re unsure while testing please check the browserconsole which logs the intersection-events …
Should work in newer browsers supporting intersectionObserver.
If you don’t know about Hypes custombehaviours: it’s a builtin eventsystem. you can use it to run Hypebehaviours or catch the event and script some action -> powerful tool. Read it up in the Hype-documentation -> search the forum and find some useful extensions @MaxZieb wrote for it.
Note: you should not misuse the HypeIntersectEnabler as a collision-detection for games … it would be to slow/overload. Instead go with MatterJS then …
I may cleanup and refactor this to add some more features in the future.
Nice. You could probably store the intersection instances in the IIFE. Apart from that, I am giving it a try later today and maybe some more feedback then. I didn’t write it as an extension yet because of the needed polyfill but it is certainly good to have as a Hype wrapper to make it usable with ease. I guess Tumult would be using it already too if it hadn’t been for the poor Safari-Support. Safari is really becoming the new Internet Explorer 9 these days.
that’s true, it’s been a habit to use hypes customData.
Interestingly the intersection on the left element only doesn’t seem to work on Firefox 76.0.1 for me.
This circumstance worked for me… and the circle converted to a drag object (no motion path) intersecting the left element worked also… was there an update?
Oy, I meant my “other left” (aka it is the right one that does not work):
Huh, weird. I did test running the timeline via button action and confirmed that the timeline itself was capable of running properly. I guess we can see if @h_classen is able to reproduce.
my version is 76.0.1 (64-Bit) and it works fine. can a difference in the behavior be related to the OS¿
sidenote: a few days ago i experienced a wired behavior with z-index in FF which did only work on a second execution or by clicking anywhere in the viewport … is z-index blocked by transformations?
I am running macOS 10.15.4 GM, though it is unlikely this is the cause just given how little Firefox likes to rely on the OS.
I started isolating as many factors as I could. When I turned off my ad blocker (Ad Guard) it suddenly started working. However, turning it back on it continues to work. I’m not really sure if it was coincidence or some sort of configuration issue related to that.
Anyways, I can no longer reproduce the problem, so I guess just call it a ghost in my machine .
I had run the above example before and discussed with @h_classen about getting odd results and we came to the conclusion it must be my Mac.
But I just ran the example again.
I had noticed a while back that some website would load and shrink once loaded. Always found it odd and a little irritating but never gave it enough thought to chase it down.
So when I just ran this example, it hit the firstinteraction and worked but while it was on its way to the second the page shrank?. And it broke. All reloads failed.
So I went hunting.
What I found was in Safari prefs the is a Page Zoom pref. Never knew it was their but it is what is making my pages shrink and it appears breaking the intersections.
(The Page Zoom pref only lists open pages.)
Not sure why urls from 127. was set to 85% ? but changing that fixed it.
Similar size/position changes could possibly be interfering for others. ( not sure how adblocker works)
Yes, of course: Just a Shot to the near Future
@h_classen, it’s a great approach and New York Times and other outlets use it for scrolling stories. In that sense it is the future and worth fixing and deploying workarounds. Only downside ist that Apple is such a big player that missing support gets in the way. In general a browser acceleration on intersection is totally what we need and want!
I haven’t looked at the code, so assuming a polyfill for Safari and my visual read on it:
It does look like the polyfill for Safari just looks at midpoints to see if they intersect, whereas Chrome looks at the bounding box. The page zoom changes the layout of the items because of how they use flexible layout, so the midpoints do not intersect anymore when zoomed out.
It is interesting the the polyfill is so different than the implementation!
Here is the polyfill I used back in 2018 for HypeLama
Here are the options and the readme
Maybe it is different? Or have you been using this one yet?
HypeIntersectEnabler_W3C.hype.zip (33.0 KB)
so lets test with the w3c-polyfill …
Cannot test on the weekend duo to lack of proper computing device. Does it work? Did anybody check? I am curious…
I get the same behaviour if I do the same tests I did above