Atomic Wind `flex` utility overrides responsive block visibility

[pirate-bot]

Summary

When an Atomic Wind Box uses the flex utility, Otter’s responsive visibility setting does not hide that block at the selected device breakpoints. The block is expected to remain hidden on the frontend wherever desktop, tablet, or mobile visibility is disabled, but it remains visible. This can expose content that an editor intentionally removed from the published layout.

Customer context

• Product / area: Otter Pro block conditions with an Atomic Wind Box
• Version: Customer version not provided; inspected repository version is 3.2.1
• Environment: WordPress site using Neve Pro; WordPress and PHP versions were not provided
• Integration / third party: Atomic Wind
• Reported error / symptom: Three event cards configured as hidden on desktop, tablet, and mobile remain visible on the frontend
• Impact: Content intended to be hidden remains published across the reported device sizes

Reproduction notes

Reported reproduction:

1. Create or edit an event card built as an Atomic Wind Box with the flex utility.
2. Configure Otter responsive visibility to hide the card on desktop, tablet, and mobile.
3. Publish or update the page and view the frontend at each device size.
4. Observe that the hide classes are present but the card remains visible.

The customer reports three affected cards. The live site was not accessed and the failed attachment was unavailable, so the behavior was not independently reproduced in a browser; the source confirms the conflicting declarations and output path.

Diagnosis

Conclusion

The defect is confirmed from repository inspection. Otter adds responsive hide classes to the Atomic Wind Box root and defines them with display:none!important, while Atomic Wind compiles the coexisting flex utility through Tailwind’s important mode. For late-rendered CSS, Atomic Wind output is also attached after the visibility CSS. This creates a reachable cascade conflict consistent with the reported cards remaining visible.

Where this likely occurs

• inc/plugins/class-block-conditions.php — Block_Conditions::render_blocks() and Block_Conditions::should_add_hide_css_class() lines 45–61 and 285–340: the frontend render path adds o-hide-on-mobile, o-hide-on-tablet, and o-hide-on-desktop to the block’s root element.
• inc/class-registration.php — Registration::load_condition_hide_on_styles() and Registration::condition_hide_on_style() lines 1157–1200: screen-size conditions register footer CSS whose hide declarations use display:none!important.
• src/atomic-wind/blocks/box/save.js — save() lines 3–10: saved Box markup receives block properties, allowing Atomic Wind utility classes and Otter’s render-time visibility classes to coexist on the same root element.
• src/atomic-wind/tailwind/generator.js — createCompiler() and build() lines 340–375: editor generation compiles scanned classes with Tailwind important mode.
• src/atomic-wind/tailwind/generator-frontend.js — createCompiler(), build(), and the DOMContentLoaded handler lines 46–75 and 117–125: frontend fallback generation also uses important mode and emits styles for classes found in the document.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::run() lines 60–83 and Atomic_Wind_Blocks::output_late_css() lines 427–467: late Atomic Wind CSS is attached to wp_footer at priority 19, while visibility CSS uses the default priority 10.
• Git history identifies 75d2c9a2 as the Atomic Wind introduction on 2026-03-19, 477e3141 as the important frontend generator introduction on 2026-04-21, and 6ea09d60 as the late CSS loading path on 2026-07-15. The inspected evidence supports a regression boundary beginning with Atomic Wind’s introduction, with later commits affecting the conflicting output paths.

Engineering notes

The inspected failure path is limited to Atomic Wind blocks carrying a display utility such as flex while Otter screen-size conditions add hide classes to the same root element. The report covers all three configured breakpoints. The cached singular CSS path can emit Atomic Wind CSS in the head, while queried or late-rendered blocks can emit it from the footer; both paths derive CSS from the important Tailwind compiler. Tailwind cascade-layer precedence was not independently runtime-tested in this investigation, but the footer ordering provides an additional directly observed conflict path for late output.

Test coverage status

tests/test-block-conditions.php — test_hide_css_desktop_condition(), test_hide_css_tablet_condition(), test_hide_css_mobile_condition(), test_hide_css_all_condition(), and test_load_condition_hide_on_styles() lines 489–633 verify class insertion and style registration without asserting computed frontend display or Atomic Wind interaction. tests/test-atomic-wind-blocks.php — test_output_late_css_inlines_multiple_rendered_posts() and related late-style tests from lines 1285–1495 exercise synthetic display CSS without important declarations or responsive visibility classes. No relevant end-to-end coverage for an Atomic Wind Box using flex with screen-size conditions was found during inspection.

What to verify or explore next

• Reproduce with an Atomic Wind Box carrying flex and screen-size visibility disabled separately for desktop, tablet, and mobile.
• Compare computed display and winning declarations for cached singular CSS, frontend fallback generation, and late-rendered/query output.
• Run the block-condition PHPUnit suite, Atomic Wind PHPUnit suite, and relevant Playwright frontend checks after establishing a regression test.
• Check the release tags containing commits 75d2c9a2, 477e3141, and 6ea09d60 to narrow the first affected public version.

Unknowns / follow-up

The customer’s exact Otter, Otter Pro, Atomic Wind, WordPress, and PHP versions were not provided. The attachment failed in HelpScout and no ticket image was available. The customer site was not accessed, so computed-style evidence comes from the transcript rather than an independent live reproduction.

Confidence

Confidence: 94/100

Repository inspection confirms that Otter’s responsive visibility classes and Atomic Wind display utilities can compete as important declarations on the same block element. The reported flex path is generated by current frontend code, existing tests do not cover this interaction, and no matching GitHub issue was found.

---

Source: HelpScout #3404675628
Generated by bug-report-triage (ID: bug-report-triage_6a6d2908efacf8.99064621)

[girishpanchal30]

I have fixed it with this PR #3024

[milicavs]

🤖 Automated QA Repro Steps

An Atomic Wind Box that uses the flex utility ignores Otter's responsive visibility setting. With "Hide on" turned on for a device, the box still shows on the frontend at that screen size, so content an editor deliberately removed from mobile, tablet, or desktop stays published there.

Requires: Otter Pro (visibility conditions), with Atomic Wind blocks enabled in Otter's settings.

Reproduce on Otter Blocks 3.2.3:

1. Create a page and insert an Atomic Wind → Box block, with a paragraph inside it.
2. Give the Box the utility classes flex gap-4 p-8.
3. With the Box selected, open its Otter visibility/conditions panel and add a Screen Size condition with Mobile turned off.
4. Publish the page and view it on the frontend.
5. Narrow the browser window to a mobile width (under 768px).

• Bug: the box is still visible at mobile width.
• Fixed: the box is hidden at mobile width.

Edge cases

• The same box at tablet width (769–1024px) and desktop width (1025px and up) — stays visible and still lays its content out in a flex row.
• Repeat with only Tablet hidden, then only Desktop hidden — each hides at its own width and stays visible at the other two.
• A Box using grid or inline-flex instead of flex — hides correctly as well.
• A plain core Group block with the same Hide on Mobile condition — still hides, as before.
• A page with caching or many blocks, viewed after a re-save/cache purge — the hide still wins over the utility.

Fix: #3024 (open)