h5bp/Effeckt.css

Using MutationObserve (or any kind of DOM changes detection)

wellingguzman opened this issue · 5 comments

If we watch changes on class attributes to detect when a class is added or removed to trigger a effeckt instead of waiting for a click event, this will be more productive.

Let me explain: Modal wait for a click event to show ( add display: block; ) effeckt-modal-wrap then do everything that has to do to performance the animation, and this is what happens with almost every effeckt. why no just wait for a class name to be added (maybe the end-user create a javascript event that adds a class to show the modal or what if the modal wont going to be trigger by a click event) and this way no matter how it was trigger the important thing is that class name was added.

This way I believe we are going to write less JavaScript and do less interaction outside CSS files, and all this type of events will belong to demo.js

what you guys think? Am i clear?

I'm not sure that we can rely on watching the dom change as such — MutationObserver is not well supported

Ultimately, whatever you put in the demo page will probably be used verbatim by users of this library. So whatever it is, it should probably be a known… cowpath.

@benschwarz I'm aware of that, we can implement a solution to just "watch" class (and maybe data-effect-*) attributes only. But the main idea of what I'm trying to say is not to rely on our own events.

You're right, on demo page will probably be used as it is by the users, but the core library I believe need this kind of way to handle "Effeckt on/off" stuff.

This is an example of what I'm saying: http://youtu.be/wH81RA3JtF8

@wellingguzman Cool, thanks for the demo. I get what you mean now :-)
…but using a setInterval isn't going to scale past our demo page… I'd be concerned about using it on the demo, because I can see people dropping it into their sites too.


I spent some time thinking about MutationObserver, and looked at the polyfill that exists under polymer, but its a pretty huge dependency to drop in (perhaps not insurmountable, though?).

I also considered using a live element list (getElementsByTagName) and Object.observe, but again, support for Object.observe is poor and the polyfill is rather large.

Anyone have any thoughts to offer here?
ping @paulirish @SlexAxton @addyosmani

I think if you're triggering these effects by some other means than a click event, the chances are you're going to be aware of the MutationObserver pattern and be able to implement the effects using that method.

For the purposes of exposing people to a robust set of "standardised" effects, I think using the existing click events is perfectly fine.