A custom HTML variation can improve a page, or break its layout in seconds. The difference is usually not the idea. It is the way the code is isolated, loaded, and tested.
Mida custom HTML testing works best when you treat each variation like a small software release. Define one hypothesis, scope every selector, check the page at multiple screen sizes, and validate the result before sending traffic to it.
Key Takeaways
- Start with a measurable test hypothesis, not a code fragment.
- Use a unique wrapper and scoped class names for every custom HTML variation.
- Keep HTML semantic, keyboard-friendly, responsive, and light.
- Add JavaScript only when the test needs behavior that HTML and CSS can’t provide.
- Test the variation against the original page before trusting conversion data.
Start With a Test Hypothesis, Not a Code Fragment
A custom HTML test begins before you open the Mida.so editor. Write down the page element you want to change, the user problem behind the change, and the metric that will determine success.
For example, your hypothesis might be: “Adding a short shipping message beside the product CTA will increase completed checkout starts.” That gives you a clear variation and a clear measurement. Changing the headline, button color, shipping message, and page layout in one test gives you too many variables.
Record the current experience first. Save a screenshot, note the existing copy, and identify the original element’s selector. Check whether the page already contains a similar banner or component. Duplicate elements can create confusing results when the test runs more than once.
The code you add should change only the intended area. Don’t rebuild an entire page inside a variation unless the test requires it. A smaller change has fewer layout risks and makes the result easier to interpret.
Mida.so account layouts and editor controls can change. Use the control that lets you add custom HTML or variation code, but don’t assume the exact label or location. If the platform provides separate areas for HTML, CSS, and JavaScript, keep each part in its matching area. If the available field accepts markup only, don’t assume that <script> or <style> tags will run.
Your first planning pass should answer five questions:
- Which page and element will change?
- Which audience should see the variation?
- What action counts as success?
- What existing code could conflict with the variation?
- What condition will make you stop the test?
The last question matters. Set a review date and a minimum amount of usable data before launch. Don’t change the variation halfway through without recording the change.
Build an Isolated HTML Fragment
Most website experiments need a fragment, not a complete HTML document. Paste the component that belongs inside the page. Avoid adding <html>, <head>, or <body> tags to a variation field.
Start with one unique wrapper. Use a descriptive class prefix that won’t collide with the website’s existing CSS. A data- attribute can identify the test component without becoming a styling hook.
Here is a small CTA panel. Replace the bracketed text with your real offer and update the link path for your website.
<div class="mida-test-pricing" data-test-component="pricing-prompt">
<p class="mida-test-pricing__eyebrow">[REPLACE WITH SHORT CONTEXT]</p>
<p class="mida-test-pricing__copy">
[REPLACE WITH YOUR OFFER OR BENEFIT]
</p>
<a class="mida-test-pricing__link" href="/pricing">
View plans
</a>
</div>
The href="/pricing" value is an example. Replace it with the correct internal route or approved destination. Don’t leave a placeholder link in a live experiment.
Use semantic elements for actions. An <a> element is appropriate when the user moves to another page. A <button> is appropriate when the page performs an action without navigation. The MDN button element reference covers the expected behavior and attributes.
Avoid duplicate IDs. A test can appear more than once during page updates, previews, or client-side navigation. Classes and scoped data attributes are safer when you need to select the component.
Don’t copy the site’s full navigation, footer, or tracking markup into the variation. The original page already owns those elements. Your test should add or replace only the content required for the hypothesis.
A clean fragment also makes removal easier. When the test ends, you can delete one component and its related styles instead of searching through a large document.
Scope CSS and Keep JavaScript Optional
Global CSS is one of the fastest ways to damage a test page. A rule such as button { ... }, .container { ... }, or a { ... } can change unrelated elements across the page.
Scope every rule under the wrapper class. Use a naming pattern such as mida-test-pricing__copy, then keep the same prefix for related elements.
.mida-test-pricing {
display: grid;
gap: 8px;
max-width: 520px;
padding: 16px;
border: 1px solid #d8dee8;
border-radius: 8px;
background: #f7f9fc;
}
.mida-test-pricing__eyebrow,
.mida-test-pricing__copy {
margin: 0;
}
.mida-test-pricing__copy {
color: #172033;
font-size: 1rem;
line-height: 1.5;
}
.mida-test-pricing__link {
width: fit-content;
color: #0645ad;
font-weight: 700;
text-decoration: underline;
}
.mida-test-pricing__link:focus-visible {
outline: 3px solid #ffbf47;
outline-offset: 3px;
}
@media (max-width: 600px) {
.mida-test-pricing {
max-width: none;
margin: 12px 0;
}
}
The media query keeps the component usable on narrow screens. The MDN @media reference lists the syntax and conditions you can use for responsive rules.
Don’t overwrite existing page styles with !important unless you have tested the conflict and have no safer selector. A more specific, scoped selector is usually easier to control. Avoid fixed widths that force horizontal scrolling.
JavaScript is optional. Use it only when the variation needs interaction that HTML and CSS can’t provide. Common examples include an expandable message, a dismissible notice, or a small form interaction.
Keep the script local and repeatable. Don’t create global variables. Don’t attach the same listener every time the variation initializes. This pattern protects against duplicate execution:
(function () {
var selector = '[data-test-component="pricing-prompt"]';
document.querySelectorAll(selector).forEach(function (block) {
if (block.dataset.initialized === "true") {
return;
}
block.dataset.initialized = "true";
var link = block.querySelector(".mida-test-pricing__link");
if (!link) {
return;
}
link.addEventListener("click", function () {
link.setAttribute("aria-busy", "true");
});
});
})();
The aria-busy line is only an example of local behavior. Remove it if the link doesn’t perform a loading action. Don’t add analytics calls to this script unless your measurement setup documents the correct event method. An invented tracking function can create errors without producing useful data.
If scripts are blocked, the HTML and CSS should still leave the page usable. A variation that fails when JavaScript doesn’t load isn’t ready for production traffic.
Check Accessibility, Responsive Behavior, and Performance
A conversion test still needs to work for users who navigate with a keyboard, zoom the page, or use assistive technology. Accessibility problems can also affect the wider test result. A visitor who can’t activate the CTA won’t become a conversion.
Check the following before launch:
- Move through the variation with the Tab key.
- Confirm that focus is visible on every interactive element.
- Use readable link and button text instead of “Click here.”
- Check color contrast for text, borders, and focus indicators.
- Test at 200% zoom without clipped content or horizontal scrolling.
- Confirm that screen readers receive the correct reading order.
- Make sure hidden content isn’t still available to assistive technology.
Use real semantic elements before adding ARIA attributes. A native link or button usually needs less code and behaves more consistently. The WCAG 2.2 quick reference provides testable requirements for keyboard access, focus, contrast, labels, and reflow.
Check at least three viewport widths. A desktop screenshot won’t expose a long headline that wraps badly on a phone. Test the page at a narrow mobile width, a tablet width, and the largest desktop layout your users commonly use.
Performance needs the same attention. Don’t load a large image for a small banner. Don’t import a font for one sentence. Don’t add a third-party library to perform a simple class toggle.
Keep custom code local. Avoid synchronous external scripts. If the variation needs an image, compress it and set its dimensions so the browser can reserve space. Review the page’s loading behavior after the variation appears. web.dev’s LCP optimization guide covers common causes of slow largest contentful paint.
A test that raises clicks while making the page slower can produce a misleading win. Compare the original page and variation under the same network conditions. Record layout shifts, console errors, and changes to the main CTA’s position.
Launch the Mida.so Test in Controlled Steps
Once the component passes local checks, add it to the intended page variation in Mida.so. Use the narrowest page and audience conditions that match the hypothesis. Don’t expose a pricing-message test across every page if the change only applies to a pricing flow.
The platform’s exact workflow and labels may differ. The operating sequence remains consistent:
- Save the original page state.
- Add the isolated HTML fragment to the variation.
- Add scoped CSS and optional JavaScript in the available code areas.
- Preview the variation on the target page.
- Check desktop and mobile layouts.
- Confirm that the original experience still works for visitors outside the variation.
- Start the test with the planned audience and success event.
- Monitor errors, page behavior, and conversion data after launch.
Previewing the page is not enough. Test the actual published URL if the platform provides a separate preview and live mode. Check a fresh browser session, a returning session, and a mobile device. Client-side experiments can behave differently after navigation or when a page restores from cache.
Watch for four common failure points:
- The variation renders twice.
- The original component remains beside the new one.
- A CSS selector changes unrelated page elements.
- The success event fires before the intended action.
If any of these occur, pause the test and fix the implementation. Don’t filter bad traffic later and call the result clean.
Keep a short change record. Note the code version, launch date, target page, audience, metric, and any edits made after launch. This record prevents a common mistake: interpreting data from several different variations as one test.
Review Results Without Losing Test Isolation
Conversion data only helps when the compared experiences are stable. Don’t edit the headline or CSS during the measurement period because the first result looks slow. Record a new version or start a new test when the hypothesis changes.
Review technical data beside the primary conversion metric. Look for JavaScript errors, broken links, mobile exits, form failures, and changes in page speed. A lift in CTA clicks means little if checkout starts fall after the next step.
Check segment results only when the segments were planned before the test. A result that appears strong for one small device group may come from limited traffic. Treat it as a follow-up hypothesis, not a final decision.
When the test ends, remove unused code. Delete old styles, scripts, data attributes, and temporary comments from the winning implementation. If the variation loses, restore the original component and remove the test code instead of leaving a hidden experiment in the page.
The cleanest winning implementation is usually smaller than the original test. Keep the content and behavior that earned the result. Rebuild the final version in the site’s normal codebase or approved content system when possible.
Conclusion
Mida custom HTML testing is safer when the variation stays small, scoped, and measurable. Build a focused fragment, isolate its CSS, use JavaScript only for required behavior, and check accessibility, mobile layout, performance, and duplication before launch.
A custom HTML test should never trade page stability for a short-term click increase. When the code is controlled and the hypothesis is clear, your result is easier to trust and easier to ship.
