Homepage typography shrinks shortly after initial render

Summary

On an affected homepage, configured font sizes initially render correctly and then become much smaller shortly afterward. Typography is expected to remain consistent after the first paint. The visible transition makes the published design unstable and can leave text at unintended sizes.

Customer context

Product / area: Otter Blocks frontend styling; likely Atomic Wind fallback path
Version: 3.2.3
Environment: Homepage using Gutenberg blocks; theme and browser not provided
Integration / third party: Unknown from available evidence
Reported error / symptom: Configured font sizes appear initially, then become much smaller after roughly half a second
Impact: Published typography changes visibly after page load.

Reproduction notes

Reported workflow: open the homepage on Otter Blocks 3.2.3, observe the configured font size initially, then observe it shrink after about half a second. Repository-derived conditional setup: Atomic Wind is enabled and frontend generation is reached because cached CSS is unavailable or late-rendered content requires generation. Runtime reproduction and exact markup are not available.

Diagnosis

Conclusion

Otter Blocks v3.2.3 contains a reachable frontend path that compiles CSS after DOMContentLoaded, scans class names across the whole document, and appends the resulting stylesheet only after compilation. The generated utilities use the Tailwind important mode. This directly establishes a delayed, globally applicable CSS transition capable of overriding an existing recognized typography utility class. The submission does not expose its markup, so the exact colliding class remains an inference rather than a verified customer-page value.

Where this likely occurs

• Frontend homepage rendering when an Atomic Wind post lacks cached _atomic_wind_css, or when late-rendered Atomic Wind content triggers the fallback generator.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::output_singular_css() lines 315–339 routes missing cached CSS to the frontend generator.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::output_late_css() lines 427–467 also routes missing or excess late-rendered block CSS to that generator.
• src/atomic-wind/tailwind/generator-frontend.js — createCompiler() lines 46–52 enables Tailwind important mode; build() lines 54–75 scans every document element carrying a class; the DOMContentLoaded callback lines 117–125 compiles and appends #atomic-wind-tailwind after initial document parsing.
• Commit 477e3141 introduced the current frontend generator in the v3.1.9 ancestry with the message fix: atomic-wind tailwind overriding core-specific styles; git blame shows the relevant compiler and delayed append lines unchanged through v3.2.3 (0c6ff15e).

Engineering notes

The confirmed defect surface is conditional on the Atomic Wind generator fallback being loaded. Cached singular CSS is inlined earlier through Atomic_Wind_Blocks::output_singular_css(), so that path does not have the same insertion timing. The generator collects class names from the complete page rather than only Atomic Wind block descendants. A class recognized as a Tailwind typography utility can therefore receive a late important declaration outside the originating Atomic Wind block. The specific homepage classes and computed-style winner were unavailable, so the exact selector collision is not established.

Test coverage status

tests/test-atomic-wind-blocks.php — test_output_singular_css_enqueues_generator_without_cache() lines 1449–1458 verifies that missing cached CSS enqueues the generator. The surrounding Atomic Wind PHP suite covers cached and late CSS routing, but not browser paint timing or computed typography. No relevant browser coverage was found during inspection for computed font sizes before and after #atomic-wind-tailwind is appended.

What to verify or explore next

• A browser reproduction on v3.2.3 with Atomic Wind enabled, an uncached Atomic Wind block, and a theme or Gutenberg element carrying a Tailwind-recognized typography class.
• Computed-style and stylesheet snapshots before and after the atomic-wind:css-ready event.
• The affected selector and winning declaration from #atomic-wind-tailwind on the reported page shape.
• Cached versus uncached singular requests and content rendered through footer or query callbacks.

Unknowns / follow-up

The report does not identify whether Atomic Wind blocks were present, whether _atomic_wind_css existed, which class collided, or which theme and browser were used.

Confidence

Confidence: 86/100

Repository inspection confirms a delayed, document-wide Atomic Wind stylesheet path in v3.2.3 that can override existing utility-class typography and spacing after initial paint. The other three submissions lack enough feature, environment, or reproduction detail to confirm a product defect.

---

Source: automated uninstall feedback — otter-blocks, 2026-08-23
Generated by bug-report-triage (ID: bug-report-triage_6a8bd0087959e6.44978995)

Start with src/atomic-wind/tailwind/generator-frontend.js and the fallback paths in inc/plugins/class-atomic-wind-blocks.php. Reproduce an uncached Atomic Wind homepage and compare computed typography before and after #atomic-wind-tailwind is appended; inspect the atomic-wind:css-ready event. The existing test is tests/test-atomic-wind-blocks.php, but browser coverage for the before-and-after styling behavior is still missing.