Why Glopzi works on any website.

Most animation tools live inside a builder. Webflow Interactions only works in Webflow. Elementor’s motion effects only work in Elementor. Greenshift’s animations only work in Gutenberg. Each tool ties itself to a specific authoring environment.

Glopzi makes a different bet: the browser is the common contract. Whatever your builder produces, the browser receives HTML. JavaScript running on top of that HTML can animate it without knowing or caring how it was generated.

That bet is the entire foundation. Everything else in Glopzi follows from it.

The model from How Glopzi works, in one sentence: your builder owns layer 1 (the DOM), Glopzi owns layer 2 (animations on it) and layer 3 (injected objects on top of it).

The ownership boundary is strict. Glopzi:

• Reads the DOM (to find elements, measure positions, set up observers).
• Animates existing elements (transforms, opacity, filters, etc., applied via inline styles GSAP manages).
• Injects new elements on top of the DOM (WebGL backgrounds inside their own custom elements, future 3D objects in their own containers).

What Glopzi doesn’t do:

• Modify your existing markup. No class renames, no structure changes, no data attribute sprinkles (except the one optional data-glopzi-id you opt into).
• Touch your CSS files. Animation styles live in inline styles GSAP applies and removes. Your stylesheet is unchanged.
• Hook into your build pipeline. No plugin for your bundler, no CLI step. The runtime is a script tag on your live site.

The strictness of the rule is what makes the bet work. Any builder we’d “help” by modifying its output would lock us into that builder’s conventions. Tomorrow’s Elementor changes would break us. Bricks’s structure quirks would diverge. Webflow’s class system would need a special case.

By treating the DOM as read-only, we depend only on the browser’s contract. No builder can break us by changing how it generates HTML, because we don’t care how it generates HTML.

• One workflow across stacks. The Glopzi you learn on a WordPress site is the same Glopzi you use on a Next.js site. Same editor, same model, same outcome.
• Resilience to builder updates.When Elementor 4.0 ships and rewrites half its DOM structure, your animations don’t need an update. They target your CSS selectors; those still work.
• No accidental damage.Glopzi can’t accidentally break your responsive design, your accessibility tree, or your SEO meta tags. We literally don’t touch them.
• Easy removal. Want to stop using Glopzi? Remove the script tag (or deactivate the plugin). Your site is exactly what it was before. No cleanup, no migration.

The trade-offs the rule imposes, honestly:

• Selector stability is on you. If your builder regenerates class names on every save and your target leans on those names, the animation can break. Stable targeting mitigates this when you opt in.
• Complex layout interactions need care. Animating an element that breaks its parent’s layout (changing height, breaking sticky positioning) still happens because we’re editing live styles. Tools that own the DOM can prevent these by validation. We can’t.
• Animations don’t persist if you uninstall in a hurry.They run live on a runtime your site loads. Remove the runtime, lose the animations. That’s the cost of not modifying your stack.

• Stable targeting covers the one mitigation for the selector trade-off.
• Integrations shows the per-stack install: same idea, different placement.
• Declarative keyframes is the other big architectural choice.