Automatic.css - WordPress Plugin

A Practical Guide to Setting Up and Using Automatic.css in WordPress

Automatic.css is not just a bundle of prebuilt styles you switch on and forget about. In a real project, it works more like a managed design system for WordPress: it defines colors, typography, spacing, site width, button behavior, grids, forms, and accessibility states, then exposes those decisions through variables, classes, recipes, and settings in the admin panel.

In this guide, we will take a practical approach to the plugin: what to check before installation, which settings to open first, how to avoid breaking an existing site, how to apply colors, spacing, typography, and grids in a real block, how to test the result across screen sizes, and what to do when the styles do not behave as expected.

This guide is written for site owners, front-end implementers, designers, and agencies already working with WordPress who want to build pages faster without turning a project into a chaotic pile of random classes. We will not repeat the product's marketing copy. The goal here is to give you a clear working map so you can test Automatic.css safely and decide whether it fits your workflow.

How Automatic.css Changes the Way You Build a Site

The core idea behind Automatic.css is that design decisions are defined once at the system level and then reused throughout the site through clear tokens. Instead of choosing a new spacing value every time, manually tweaking a button color, or fighting a one-off style inside the builder, you set the base rules in the ACSS panel and apply them through classes, variables, and recipes.

In practice, this changes how you think. You stop working with one isolated button, card, or section and start working with a repeatable system: primary color, neutral palette, base site width, heading scale, block spacing, focus behavior, button styles, grids, and forms. This approach becomes especially valuable when the site grows: new pages, landing sections, blog posts, service cards, templates, and additional forms all need to stay consistent.

A System Instead of Manual Tweaks

The official documentation describes Automatic.css as a CSS framework for WordPress and page builders. One important detail is that it is more than a set of utility classes. In newer versions, the product clearly leans more toward variables, recipes, and custom classes. That makes the most sensible workflow look like this: define the foundation in the panel, create meaningful custom classes for your components, and let ACSS provide the stable base through variables, mixins, and recipes.

The most common mistake people make at first is treating the plugin like a catalog of random classes. That approach can produce quick results, but it does not scale well. It is better to decide up front what the system is responsible for: colors, sizing, layout, spacing, accessibility, and base elements. On top of that, you build project-specific classes such as a service card, a benefits block, a pricing card, a testimonial section, or a catalog filter.

When the Impact Is Most Noticeable

Automatic.css is especially useful on projects with repeatable patterns: agency sites, landing pages with multiple sections, service websites, company pages, catalogs without complex business logic, blogs with a unified typographic system, and pages built in Bricks, Gutenberg, or a compatible visual builder. The real benefit is not one button. It is the full chain: configure the system once, build new blocks faster, and spend less time going back to manually fix responsive behavior.

Even a small two-page site can benefit, but the payoff does not always justify the learning curve. If you need the simplest possible site and the theme already controls all styling, Automatic.css may add an unnecessary layer. But if the project needs a cohesive look, room to grow, and the ability to survive brand changes, the system starts saving time almost immediately.

Who This Plugin Is For and When Another Approach Makes More Sense

Before installing it, take an honest look not only at the feature set but also at your team's workflow. Automatic.css works best for people willing to think in systems. It does not replace a working understanding of CSS, it does not automatically fix bad structure, and it does not remove the need to test the final result on real pages. Its strength lies elsewhere: it reduces the number of manual decisions and gives your design process a shared language.

Good-Fit Scenarios

• Agency WordPress development. If your team regularly builds sites through a similar process, ACSS helps standardize colors, spacing, typography, buttons, and grids.
• Projects built with Bricks or Gutenberg. The documentation includes dedicated guidance for these editors, including Bricks configuration and Gutenberg settings.
• Sites likely to be redesigned later. When colors, core spacing, and sizing all live inside one system, rebranding or refining the visual rhythm becomes much safer.
• Teams that want fewer inline styles. Variables, recipes, and custom classes make it easier to avoid keeping every design decision trapped inside individual builder elements.
• Projects where accessibility matters. ACSS includes dedicated options for focus styling, clickable parent, forms, and color relationship logic, but those features need to be tested deliberately.

When Automatic.css May Not Be the Right Fit

If a site already depends on a large body of hand-written styles, adding ACSS on top of the existing system can create mismatched expectations and conflicting behavior. You should not enable the plugin on a live production site without a backup or a staging environment. It can also be excessive if the entire front end is built in a fully custom theme without a visual builder and the team already has its own CSS framework, build process, variables, and component rules.

It is also worth addressing users who expect "magic" automatic beauty. ACSS helps you maintain scale, rhythm, and consistency, but it does not design the page structure for you. If your blocks have no hierarchy, weak images, and random copy, the framework will not fix the underlying content. What it does provide is a strong foundation for someone who understands what they are building.

A practical check before adoption: if you cannot clearly name your primary color, content width, heading scale, default section spacing, and button rules, start by writing a short style guide. Automatic.css will make far more sense after that.

What to Check Before Installation

Installing the plugin is technically simple: upload the ZIP through the WordPress admin, activate it, and open the Automatic.css area in the left-hand menu. But preparation matters more than the click itself. Because the plugin affects site styling, you need to understand where your global design decisions already live before you enable it for the first time: in the theme, the builder, a child theme, global CSS, template kits, or another framework.

Environment Check

Start with a site copy or a test install. On a brand-new project, it makes sense to add ACSS at the very beginning, before the site accumulates hundreds of manual edits. On an existing site, create a backup, open staging, and test pages with different content types: the homepage, a blog post, a service page, a form, card layouts, an archive template, pages with buttons, and any complex content blocks.

Next, document which editor the site uses. The official documentation covers Etch, Bricks, and Gutenberg separately. For Bricks, there is both an automatic setup route and a manual one, where global styles, HTML font size, container width, and disabling conflicting defaults are especially important. For Gutenberg, there is an Options > Gutenberg panel where you manage the palette, color replacement, and a class-first workflow.

What Not to Do at the Start

• Do not enable every module and option "just in case." The more you activate, the harder it becomes to understand where a specific style is coming from.
• Do not follow old video tutorials without checking the current documentation first. The 4.x branch changed several core approaches, especially around utility modules, recipes, and adaptation points.
• Do not change the theme, the builder, global styles, and ACSS all at the same time. If something breaks, you will have a hard time finding the cause.
• Do not apply the plugin to a client's live site without a clear page test list and a rollback plan.

A Minimal Pre-Launch Map

It helps to write down four decisions in advance: site width, base palette, typography, and spacing. This is not design bureaucracy. It is protection against chaos. Automatic.css builds many of its relationships around those values. If the site width in ACSS does not match the builder container, responsive typography, spacing, and auto grids will behave less predictably. If colors are enabled without defined roles, you may end up with a pretty palette but no clear sense of which color is meant for actions, backgrounds, text, or neutral borders.

Installation and the First Check in WordPress

The standard Automatic.css installation follows the normal WordPress flow: Plugins, Add New, upload the file, select the ZIP, and activate it. Once activated, an Automatic.css area appears in the left sidebar of the admin panel. The documentation emphasizes an important point: the plugin includes many settings, but the system can work with very little initial complexity. That does not mean the settings do not matter. It means your first priority should be checking the foundation rather than trying to work through every tab immediately.

The First Safe Launch

1. Open a test copy of the site or a new WordPress project.
2. Install and activate the plugin using the standard ZIP upload flow.
3. Open the Automatic.css section in the left admin menu.
4. Confirm that the panel loads without errors and that the main settings groups are available.
5. Do not start by mass-enabling or disabling modules. Configure width, palette, typography, and spacing first.
6. Create a test page with headings, body text, a button, a card, a grid, and a form if the project uses forms.

If the panel does not open or your changes do not appear at this stage, do not rush to rewrite styles. Check the cache, user permissions, conflicts with admin-side JavaScript optimization, the current editor version, and whether aggressive minification is active in the test environment. The ACSS changelog has included fixes related to the dashboard, the Gutenberg palette, the Bricks UI, and variable handling, so the change log is worth checking when symptoms are unclear.

Initial Result Check

Once ACSS is enabled, do not start with a design review. Start with a technical one. Open a public page in a normal browser window, then view it while logged out. Check whether the styles are loading, whether heading sizes shift unexpectedly, whether extra spacing appears, and whether buttons or forms break. Then open the same page in the editor your team will actually use. It is important to confirm that classes, palette options, and variables are available where the team is building pages, not just on the front end.

If the site already uses another CSS framework or a large set of global classes, do not mix approaches without a plan. Start by choosing one test block, rebuild it using ACSS logic, and only then decide whether the rest of the site should migrate.

Core Settings: Width, Breakpoints, Colors, and Typography

This section is the heart of working with Automatic.css. It is also where mistakes happen most easily, because the settings can look like unrelated fields. In reality, they are connected. Site width affects responsive calculations. Breakpoints need to align with the builder. The palette needs meaningful roles. Typography needs to stay readable both inside the editor and on the front end. Spacing should create rhythm, not random empty gaps.

Site Width and Builder Alignment

In the ACSS documentation, the width setting lives under the Viewport tab. The Website Width value should match the actual site width or the container width defined in your page builder. This matters more than it may seem. If the builder assumes one container width while ACSS assumes the site is wider or narrower, fluid typography, responsive spacing, and auto grids will all be calculated against the wrong base.

For Bricks, the documentation also recommends matching breakpoints between ACSS and Bricks. On a new project, that is worth doing before you start actively building pages. On an existing project, document the current breakpoints first, then compare them carefully with the ACSS settings. If you change them too abruptly, some existing blocks may start behaving differently.

How to Check Width Without Guessing

Create a test section with a container, a heading, body text, and a three-card grid. Open the page on a wide screen, at tablet width, and at mobile width. Do not only judge whether it "looks good." Check concrete signals: the container matches the intended width, text does not stretch too far, the grid reflows at a logical point, and the buttons do not introduce horizontal scrolling.

Palette: Think in Roles, Not Hex Codes

In ACSS, your main colors are organized into slots such as Primary, Secondary, Tertiary, Accent, Base, and Neutral. The documentation recommends enabling only the colors you actually need. That is a good rule. You do not need all six roles if the project only calls for Primary, Base, and Neutral. The fewer active roles you use, the easier it is for the team to stay aligned on which color is used for actions, which for backgrounds, and which for structure.

Primary usually carries the main action color: buttons, important links, and accents. Base is often tied to backgrounds and text. Neutral works well for borders, dividers, disabled states, and quiet surfaces. Secondary and Accent should only be introduced when they truly carry meaning. If Accent appears in every other block, it stops functioning as an accent.

Typography: Readability Matters More Than Flashiness

In the Typography panel, you can define the root font size, base heading or text size, scale, font family, line height, weight, letter spacing, max width, and text wrap behavior. The documentation also covers Smart Line Height and text-wrap settings separately. For most sites, it is best to start conservatively: a clear base line height, a moderate heading scale, and a sensible maximum line width wherever that does not conflict with the builder.

Your typography review should include a long heading, a short heading, a normal paragraph, a list, a caption, a button, and a card. If you see a lonely orphan line on mobile, an overly dense list, or an oversized H2, the issue is not the individual block. You most likely need to go back to your base min/max values and overall scale.

Spacing: One Rhythm Across the Entire Site

Standard Spacing in ACSS is built around a base spacing value and a base scale. The base value controls the size of a medium gap, while the scale generates values above and below it. That is useful when you do not want to debate whether a gap should be 24, 28, or 32 pixels every time. But do not make the scale too aggressive. On mobile, excessive differences between spacing steps quickly turn into empty voids or, at the other extreme, a cramped interface.

Working with Bricks, Gutenberg, and the Page Editor

Automatic.css is often chosen for its integration with visual editors. This is where you need to distinguish between "the plugin is installed" and "the editor is configured correctly." If ACSS works on the front end but classes are awkward to apply in the editor, the palette does not match, or the builder's global styles fight the system, the team will quickly fall back to manual tweaking.

Bricks: Automatic Setup vs. Manual Setup

For Bricks, the documentation offers two paths. The first is importing prepared settings files into a new project. That is a quick way to bring defaults into a known-good state, but it is risky on an existing site because it can overwrite current settings. The second path is manual configuration of Bricks Settings and Global Theme Styles. In the manual route, container width, HTML font size via var(--root-font-size), container behavior, heading/text defaults, and careful handling of other global Bricks styles all matter.

For a new project, the automatic setup can save time. For an existing project, a manual audit is safer: capture the current settings first, then change one area at a time and test the result. If all headings suddenly look different in Bricks after enabling ACSS, do not rush to edit every heading by hand. Check the global theme styles and typography rules first.

Gutenberg: Palette and a Class-First Workflow

For Gutenberg, the documentation points to the Options > Gutenberg panel. There you can generate the ACSS palette inside the editor, replace existing colors, and enable a class-first workflow that moves the class field higher in the block settings panel. This is convenient for authors who actively use classes, but it requires discipline: do not expose editors to dozens of utility classes without context.

If the site includes a blog, pay attention to the blog post styling settings: post types, editor background, and text color. These options help make the authoring experience closer to the real front-end appearance. But they do not replace a final check on the live-facing page. The editor may provide a useful approximation while the theme, post template, or cache still influences the final result.

Recipes, Variables, and Custom Classes

Newer ACSS workflows make variables and recipes especially important. A recipe is an expandable CSS block that you can insert where a utility class would be awkward or unnecessary as a permanent pattern. For example, for targeted techniques such as clickable parent, it is better to use a documented recipe or mixin than to invent a complicated workaround of your own.

A practical rule is this: if a solution will be reused often and should live as part of a component, create a meaningful custom class. If you need to apply a ready-made pattern quickly inside a CSS field, use a recipe. If you need a precise global value, use a variable. That keeps the project from turning into a confusing mixture of vague utility classes and hand-entered inline values.

Practical Example: Building a Services Section with Cards and a Responsive Grid

Now let us apply Automatic.css in a real-world scenario. Imagine an agency page that needs a services section: a heading, introductory text, three cards, a button in each card, and clean behavior on mobile screens. The goal is not to produce the prettiest block possible. The goal is to complete the full cycle: prepare the system, build the block, test responsiveness, verify accessibility, and see where ACSS actually saves time.

Goal and Preparation

The goal is to create a section that inherits global colors, uses system spacing, works inside a grid, keeps button styling consistent, and does not break when the palette changes. Before you begin, site width, the base palette, typography, standard spacing, and button styles should already be configured. ACSS classes, or at least a convenient way to add them, should be available in the editor.

For this example, assume Primary already handles the main action, Base controls the core text and backgrounds, and Neutral covers lines and quiet surfaces. In the section, we will use system variables and classes, while creating a custom class for the unique card logic so the styling does not get scattered across individual elements.

Steps in the Editor

1. Create a new section and apply system padding using an ACSS section padding class or the project-approved variable.
2. Add a container inside it that matches the site width from your ACSS settings.
3. Add a heading and a short paragraph. Confirm they inherit the global typography rather than old manual sizes from a legacy template.
4. Create a wrapper for the cards and apply appropriate grid logic. For a simple row of three cards, you can use ACSS grid classes; for a more complex layout, use a custom class with ACSS variables.
5. Inside each card, add a short heading, body text, and a link or button. Style the button through a system button class, such as a class from the .btn-- family, if that is enabled and matches your project version.
6. Do not wrap the entire card content in a link. If you need the whole card to feel clickable, use the documented clickable parent approach: keep the real link in the heading and expand the click area through a recipe or mixin.

Small Snippet for a Local Button Override

The ACSS documentation shows that button-local CSS variables can be overridden on a specific selector or within a page scope. That is safer than rewriting the global button style just to adjust one section. The example below works well when you want one group of primary buttons to be denser and darker only inside a services block.

.services-section .btn--primary {
  /* Local adjustment inside the section without changing global buttons */
  --btn-padding-block: 0.85em;
  --btn-padding-inline: 1.35em;
  --btn-font-weight: 700;
  --btn-background: var(--primary-dark);
  --btn-background-hover: var(--primary-ultra-dark);
}

Add code like this in a safe place for project-specific custom CSS: a child theme, the builder's CSS panel, or another source you control and can roll back if needed. Do not edit plugin files. After adding it, open the page and check the hover state, focus state, mobile width, and whether any horizontal scrolling appears.

Checking the Result

Your review should follow a clear sequence: desktop, tablet, mobile, keyboard navigation, then a system-level change. First, make sure the grid reflows at the expected point. Then use the Tab key to move through the cards and confirm the focus state is visible. After that, change the Primary color or base spacing in the test copy and see whether the section reacts like a single system-based component. If one change to base spacing causes the block to fall apart, it relies on too many random manual values.

Key Features Worth Learning After the Basic Setup

Once your first block works, there is no need to study every documentation page at once. It is more productive to focus on the features most likely to pay back the time you invest: color relationships, buttons, forms, focus styling, clickable parent, auto grids, recipes, and WP-CLI commands for diagnostics. These areas matter because they directly affect real-world site maintenance.

Buttons and Local Exceptions

Buttons appear on almost every page, so they should not be left to chance. In ACSS, you can configure shared button styling: padding, minimum width, line height, weight, font family, border, radius, and transition. You also get button groups for active colors and solid/outline/light/dark variations if those options are enabled. One important note from the documentation: an excessively large minimum button width can cause overflow on mobile devices.

If ACSS affects buttons from a third-party plugin, do not "fix" it by globally disabling button styling everywhere. The changelog has mentioned exclusion mechanisms for button selectors. In practice, the right workflow is to identify exactly which class or element is being affected, then exclude or locally override only that area. This preserves the value of the system across the rest of the site.

Forms and WS Form

The ACSS documentation specifically calls out styling support for WS Form. For those styles to work, you need to enable Load Forms in the Forms screen, and Styler must be enabled in WS Form because ACSS depends on the CSS variables it provides. If a form looks wrong, do not start by changing colors. Start by checking that dependency: is Styler enabled, were the WS Form settings saved, and were the system files regenerated?

The .form--light and .form--dark classes are useful when automatic color-scheme detection is not enough. But on most standard pages, there is no reason to create forced variants everywhere. First check how the form adapts through the shared color scheme, and only then add an explicit light or dark treatment if necessary.

Focus Styling and Accessible Cards

Focus styling is one of those areas people often ignore until the first complaint arrives. In ACSS, you can choose between an outline or a box shadow and configure the color, thickness, and offset. Outline is helpful because it can sit away from the element; box-shadow tends to follow rounded corners more naturally. If the focus state disappears inside a dark section, the documentation suggests setting a local --focus-color variable on the relevant container.

.dark-section {
  /* White focus inside a dark block if the main color blends into the background */
  --focus-color: var(--white);
}

The test is simple: open the page, press Tab, and watch where focus goes. If the user cannot see which link or button is active, a polished design does not help. For cards, use clickable parent carefully: the parent should be position: relative, and the recipe or mixin should be applied to the real link or button, not to an arbitrary wrapper.

WP-CLI and Developer Diagnostics

The documentation includes a WP-CLI commands section covering settings, css, status, logs, doctor, and flags. This is not essential for a site owner, but it is useful for a developer or administrator maintaining multiple projects. These commands make it easier to inspect the system and troubleshoot problems without digging through the panel by hand. We are not listing commands to run here because environments differ, but the important point remains: ACSS includes a documented CLI layer for maintenance and support.

Post-Setup Validation: How to Tell Whether the System Is Working Properly

A successful installation is not the same thing as a successful setup. Automatic.css should produce predictable results both inside the editor and on the public-facing site. For testing, do not rely on a single homepage. Use a controlled set of elements instead. That will show you where the system is working and where it is being overridden by the theme, the builder, the cache, or hand-written CSS.

A Control Page

Create a draft page with these blocks: headings at every level, regular body text, a list, a quote, two button types, a card, a grid, a form, a link inside a dark section, an image with a caption, and a test block with extra-wide content. This page does not need to be published for users, but it makes it much easier to see what changes after adjusting the palette, spacing, typography, and button defaults.

After every major change, open the control page in three contexts: inside the editor, on the front end while logged in as an administrator, and on the front end as a guest. If the difference only appears for guests, check caching and optimization. If it only appears in the editor, check integration settings. If it appears everywhere, inspect the ACSS setting itself or a conflict with the theme's global styles.

Responsive Testing

For responsive behavior, do not look only at browser width. Watch for meaningful transitions. The grid should not become too narrow before it reflows. A heading should not break into one character per line. Buttons should not create horizontal scroll. If the issue only appears at one width, check whether the website width and breakpoints match between ACSS and the builder. If it appears everywhere, the most likely cause is a poor choice of base spacing, type scale, or a manual element style.

Brand Change Testing

One of the strongest tests is to temporarily change the Primary color or base spacing in staging. If the site is truly built as a system, key buttons, links, accents, cards, and spacing should all update in a coordinated way. If some blocks stay stuck in the old styling, those areas still contain hard-coded values. That is not always wrong, but it should be documented because those sections will be more expensive to maintain.

How to Use Training and Video Content Without Following Outdated Steps

Automatic.css has an official YouTube channel and a free ACSS 101 course referenced in the documentation. Videos are useful because they show a real workflow, not just a list of settings. But when using video training, remember that the interface and recommended approaches evolve. It is best to use videos to understand the underlying principles, then verify exact setting names and current exceptions against the documentation.

For a first look, the official ACSS 101.01 video is a good starting point. The documentation ties it directly to installation and first-time orientation. It answers the core beginner question, "How do I start using Automatic.css?" by showing that the system can work out of the box, while still requiring a solid understanding of its foundational settings.

After watching, do not repeat every step blindly. Build your own implementation map instead: which builder are you using, where is width defined, what palette do you need, which buttons and forms exist on the site, and what older styles are already loaded. That turns training into part of adoption rather than a disconnected checklist of clicks.

When Automatic.css Is the Right Choice

Automatic.css is a strong choice if you want to build WordPress sites as a system rather than as a collection of isolated visual decisions. Its strengths show up most clearly when you have repeatable components, a page builder, a need for a shared palette, fluid typography, spacing, grids, buttons, accessibility, and a maintainable CSS structure. It is especially well suited to new projects where the foundation can be set before active page building begins.

If you already have a complex site, do not start with a full migration. Start with a test copy and a single block. Check how ACSS integrates with your builder, whether widths align, whether classes are available, whether forms and buttons remain intact, and whether you can change color or spacing without manually repairing every element. Only after that should you decide whether to expand the system across the rest of the site.

For a safe start, prepare a backup, a control page, and a short list of critical templates. After validating the settings, workflow, and troubleshooting path, you can download the WordPress version and test the plugin in your own working environment. The best sign of success is not that the first page looks prettier. It is that the next pages are faster to build, easier to revise, and able to keep a consistent rhythm without constant manual tweaking.