Preparing for ACSS 4.0

We’re nearing the final stages of work on ACSS 4.0. Here’s what you need to know to prepare along with some important information on how we’re approaching third party integrations in Era 4.

Written by

Published on

July 2, 2025
BlogCSS Frameworks

After 3+ years of active development and holding the #1 spot in CSS frameworks for WordPress (5xing the closest competitor in number of active projects), it’s time for Automatic.css to prepare for a new era of web design.

First, a little recap:

ACSS 1.x was the first CSS framework to introduce the concept of a visual UI for customizing values. The first dashboard was written purely in PHP and proved that a visual UI was a massive benefit and time saver for users of a framework.

ACSS 2.x took what we learned from v1 and refined it with an updated dashboard UI while focusing mostly on framework feature expansion.

ACSS 3.x was the biggest shift of all, introducing the first-ever Svelte-powered “real-time dashboard” that modernized the framework experience, eliminated the magic area of the back-end, and brought in another critical component of framework management – live preview.

Unlike the last 3 major version milestones, though, this next iteration doesn’t require a massive dashboard overhaul, a major UI update, or any big changes to the way you use Automatic.css.

Instead, this update focuses on two things: Modernizing and Streamlining.

Here are the three big things that make this update necessary:

  1. The rapid iteration of CSS – major aspects of the code base can be re-written with more modern CSS techniques that make the code more agile and efficient, and we can use these refactoring opportunities to re-align with third party tools who have also undergone recent refactorings. In addition, we can better position ACSS to take advantage of innovative new CSS features that are right around the corner.
  2. Tighter integration with modern Era 4 development tools like Etch – We want to ensure that integrations are faster and easier to build, proper API routing is in place, and that we’re continuing to find ways to make modern development quicker, more efficient, and more maintainable. We’re also streamlining our approach by focusing on tools that follow modern standards and moving away from supporting overrides for Era 2 and Era 3 tools that aren’t aligned with best practices. Additionally, we’re shifting our strategy regarding Gutenberg and builders that attempt to leverage Gutenberg as a page builder (see below).
  3. The removal of baggage to keep ACSS nimble – We’ve learned a ton from hundreds of releases and thousands of code commits. ACSS 4.0 is an opportunity to strip out all the accumulated complexity, bloat, and deprecation artifacts that come with three full years of active development, including an outdated and cumbersome licensing system.

You can consider ACSS 4.0 a maturation. It’s not a brand new experience that users have to learn or figure out – we just took the #1 CSS framework for WordPress and made it faster, more agile, more intelligent, more efficient, and more visually aligned with our flagship development environment, Etch.

These improvements drive three fundamental changes that will shape how you use ACSS going forward. Let me walk you through each one, starting with what’s probably your biggest question:

ACSS 4.0 is not designed to be backward compatible.

ACSS 4.0 is a framework built for Era 4.

It represents a fresh start for a new era of web development.

For those wondering about backward compatibility: ACSS 4.0 represents a clean foundation for the future. Rather than forcing a risky in-place upgrade due to large amounts of refactoring in combination with things out of our control (rendering differences between HSL and OKLCH, for example), we’re offering a parallel track — keeping ACSS 3.x stable and maintained for existing projects, while giving new projects the benefits of the new track.

What this means is that you don’t “upgrade” to ACSS 4.0 in the traditional sense. Instead, you’ll use ACSS 4.0 on new projects and continue using ACSS 3.x on existing projects.

This approach completely eliminates the typical frustrations involved in major version upgrades — no months of testing and reporting inconsistencies, no extended “beta” periods, and no unexpected breakages on complex websites.

After all, why complicate a website that’s already complete and functioning well, especially when it won’t fully benefit from what 4.0 has to offer?

Every major version update in ACSS up to this point has maintained backward compatibility with previous versions. But there comes a time in software development when looking toward the future means leaving behind the accumulated complexity of the past.

For ACSS, that time is now.

For users, this actually means a much cleaner and more predictable experience!

All your existing sites will continue running on ACSS 3.x, which will receive critical bug fixes and security updates for the next 5 years. While no new features or enhancements will be added, this ensures your current projects remain stable as-is while you explore ACSS 4.0 for new builds.

No compatibility issues, no unexpected breakages, no extensive testing required, and no upgrade anxiety!

ACSS 4.0 is raising our 3rd party integration standards.

As part of our modernization effort, we’re also being more selective about which third-party tools we support. This change is driven by our commitment to promoting tools that follow web development best practices and our need to focus our development resources more effectively.

Tools We’re No Longer Supporting

We’ve made the difficult decision not to carry forward support for several integrations:

  • Cwicly – Removed due to being EOL / discontinued.
  • Oxygen 3.x and 5.x – Removed due to development concerns and workflow misalignment.
  • Breakdance – Removed due to workflow misalignment.
  • GeneratePress & GenerateBlocks – Removed due to workflow misalignment.

Tools We’re Continuing to Support

  • Bricks
  • Core Gutenberg (for rendering and blog post needs)

Our Reasoning

Here are some additional insights on each specific area:

Discontinued Tools Cwicly is no longer being developed, has no future roadmap, and is not a safe choice for developers to rely on. This decision should be fairly straightforward.

Tools With Architectural Misalignment Some tools have taken approaches that diverge significantly from modern web development standards or have unclear development trajectories:

  • Oxygen 3.x is essentially in maintenance mode with no meaningful active development.
  • Oxygen 5.x attempts to recreate a Webflow-like experience on top of Breakdance’s framework but retains many legacy patterns and workflows. We’ve decided to focus our support on tools that are evolving in alignment with modern development standards and practices.
  • Breakdance, while modern and clean, encourages unscalable and unmaintainable development practices and makes it difficult for users to use a framework like ACSS.
  • GeneratePress operates as a classic theme which comes with inherent limitations. And GenerateBlocks, while well-built, relies on Gutenberg as a page building interface, which we no longer support the concept of. Gutenberg is a capable content editor and that’s all it should be used for.

Our New Integration Philosophy

Moving forward, our primary consideration for integrations is: “Does the tool follow fundamental best practices of web development and share our commitment to a scalable, maintainable, accessible workflow?”

The reality is that supporting tools with fundamentally different approaches makes it difficult to deliver the features and improvements our users deserve. Every time we release a new feature that follows standard web development principles, we need to figure out how to make it work with tools that have different approaches, then maintain that compatibility as these tools continue to “do their own thing.”

This creates significant technical debt that ultimately slows down our ability to innovate for the tools that do follow best practices.

We believe our efforts are better spent focusing on tools that share our commitment to web standards, rather than trying to bridge increasingly divergent approaches.

ACSS 4.0 is refocusing our development efforts on framework innovation.

The third major change involves how we approach builder-specific workflow features.

Part of Automatic.css has involved innovating workflow efficiency features for visual builders – things like right click context menus with live preview and token insertion, Auto-BEM, variable and calc expansion, automatic rem computation, bulk class renaming, in-builder color scheme switcher, and CSS authoring improvements.

While these features are highly valuable, they require deep, ongoing collaboration with builders to implement and maintain well and not every builder has the proper API routes to support these features.

Going forward, we’re focusing our builder and workflow enhancement efforts on Etch, where we can fully control and support these features while avoiding breakages caused by random updates with no communication from builder dev teams.

Moving forward, if you want innovative workflow features in your visual builder, the best approach is to choose a builder that prioritizes workflow innovations natively.

One exception: For Bricks users we will continue to include right click context menus in the workflow.

What This Means for You

Here’s the practical summary:

For your existing projects: Keep using ACSS 3.x. It will be maintained with critical bug fixes and security updates for the next 5 years. No upgrade pressure, no compatibility concerns.

For new projects: Start with ACSS 4.0 and enjoy the improved performance, cleaner codebase, and streamlined experience from day one.

For your tool choices: If you’re currently using one of the tools we’re no longer supporting, you can continue using it with ACSS 3.x on existing projects. For new projects, consider tools that align with modern web development practices or switch to a more capable and future-proof tool.

For workflow features: If builder-specific enhancements are important to your workflow, consider builders that are developed by forward-thinking dev teams who include these features natively.

More to come…

We’re excited to share more details about ACSS 4.0 over the coming weeks. We’ll be publishing a series of blog posts and videos that dive deep into specific improvements, new features, and migration strategies.

Make sure you’re subscribed to the YouTube channel and follow Automatic.css on X to stay up to date. You should also subscribe to the Etch channel and Etch on X for information and updates on how we’re establishing a new standard for professional development and data liberation in WordPress.