Feature Request: Per-Variant Custom Code Injection (CSS & JS)

Allow users to attach custom CSS and/or JavaScript to individual A/B test variants, so the code only executes when that variant is served to a visitor.

The Problem

Optibase's A/B testing is built around element visibility toggling — showing/hiding HTML elements per variant. This works well for swapping headings, images, CTAs, and sections. However, it does not support a common testing scenario: conditionally applying custom CSS or JavaScript per variant without changing the page structure.

Real-world examples where this is needed:

Testing a CSS animation or transition effect on an existing element (our current use case — a typing animation on the homepage hero heading)
Testing a different font treatment, gradient, or visual effect that requires custom CSS
Testing a scroll-triggered interaction or micro-interaction that requires custom JS
Testing a dynamic content enhancement (e.g., a countdown timer, live counter, or personalized greeting) that runs via JS on an existing element

In all these cases, the page structure and HTML elements remain identical between variants. The only difference is CSS and/or JS that either runs or doesn't.

Why the Current System Can't Handle This

Optibase's display:none toggling mechanism does not prevent CSS or JS from executing. This is a browser-level behavior, not an Optibase limitation per se, but it means users cannot use the existing A/B system to conditionally load code:

CSS inside a hidden element still applies globally. Placing variant-specific styles in a hidden embed does not scope them — they affect the entire page regardless of the parent element's visibility.
Script tags inside hidden elements still execute. The browser runs JavaScript on page load regardless of whether the containing element is set to display:none.

The only workaround currently available is to use a dummy trigger element as an Optibase variant, then write a custom MutationObserver script that detects when Optibase toggles the element's visibility and conditionally injects the CSS/JS. This works, but it's fragile, undocumented, and adds unnecessary complexity for what should be a straightforward test.

Proposed Solution

Add optional Custom CSS and Custom JS fields to each variant in the Optibase test configuration. When a visitor is assigned to a variant, Optibase's script would:

Inject the variant's custom CSS into the document <head> as a <style> tag
Execute the variant's custom JS

This would happen at the same point in the lifecycle where Optibase currently toggles element visibility — after variant assignment, before the page is visually rendered to the user.

UI Suggestion

In the variant editor (where users currently set the variant name and connect elements), add two optional code input fields:

Custom CSS — a text area for CSS rules (injected as a <style> tag)
Custom JS — a text area for JavaScript (executed after variant assignment)

Both fields would be optional. Existing element-based A/B tests would continue to work exactly as they do today. The code fields would simply be an additional capability for users who need it.

Benefits

Unlocks a major category of tests that currently require workarounds or alternative tools (VWO, Optimizely, Webflow Optimize)
No breaking changes — purely additive to the existing variant system
Keeps testing centralized — users don't need to maintain separate custom scripts alongside Optibase
Competitive parity — most enterprise A/B testing platforms (VWO, Optimizely, Google Optimize before deprecation) offered per-variant code injection as a core feature
Reduces churn risk — users hitting this limitation today may migrate to more expensive tools that support it natively

Current Workaround (For Reference)

We are currently using the following approach, which works but demonstrates the demand for a native solution:

A dummy div element is added to the page and connected to Optibase as a variant (hidden by default for Variant B)
A custom MutationObserver script watches for Optibase's visibility toggle on the dummy element
When the observer detects the variant B element becoming visible, it injects the CSS and executes the JS
Optibase still handles traffic splitting, cookie persistence, and conversion tracking

This is functional but adds ~40-60 lines of custom code, introduces a dependency on Optibase's internal DOM manipulation timing, and is not documented or officially supported.

Optibase