WordPress 7.1 Mary Lou: Which Custom CSS Snippets You Can Finally Delete

WordPress 7.1 "Mary Lou" landed on 19 August 2026, timed to the last day of WordCamp US in Phoenix. The official release post is a design-tools release: responsive styles in Global Styles and block settings, interactive pseudo-states, a persistent admin bar in the editors, a real media-editor modal, richer Notes, and two new blocks (Tabs, Playlist).

The snippet-library headline is narrower. A large class of custom CSS now has a core control. If you have been maintaining mobile font sizes, button hover colors, and "hide this block on tablet" as snippets, 7.1 is a deletion event — if you verify, not if you assume.

This is two days after release. APIs will settle. Do not mass-delete on Monday morning without a staging pass.

What 7.1 actually added for CSS people

Responsive styles. You can change how a block looks at different screen sizes from Global Styles or the block sidebar, with viewport previews while you edit. This sits on top of the show/hide-per-breakpoint options that already existed. The promise in the release post is explicit: *without custom CSS*.

Hover, focus, and active. Button (and other supported) styles can set :hover, :focus, and :active from the UI. Block-level support still varies. Preview the blocks you actually use; "supported in Global Styles" is not "every third-party block."

What did not ship. Collaborative editing that was pulled from 7.0 is still not the story. A Table of Contents block was punted toward 7.2. Native multilingual is not here. And the editor iframe is now the enforced path — Block API v3 for custom blocks — which will break old blocks harder than it will break a CSS snippet.

If you register PHP-only blocks from 7.0's autoRegister path, test them in 7.1's iframed editor before you call the upgrade done.

CSS snippets that are candidates for deletion

Open the CSS half of your library and look for:

• Media queries that only change font size, padding, or gap on core blocks
• .wp-block-button hover/focus color overrides that match something you can now set in Styles
• "Hide on mobile" rules that duplicate the built-in visibility controls
• Admin-bar offset hacks if you added them because the bar vanished in the site editor — 7.1 keeps the admin bar visible across editors. Re-test before you delete; themes still fight the bar.

For each candidate: recreate the look on staging with 7.1 controls, then disable the snippet (do not delete yet), then click through the templates that used it. Keep a Git tag. GitHub sync makes this a revert, not an archaeological dig.

CSS snippets you should not touch

Core did not replace the ugly half of the job:

• WooCommerce / Easy Digital Downloads layout patches
• Plugin CSS you override because the vendor will not
• Third-party embeds, chat widgets, cookie banners
• Print styles, email (where relevant), and PDF generators
• Anything that targets a classic theme the site has not left
• JS-driven CSS (classes added by your own scripts)
• Critical checkout CSS that is a business rule, not a design token

Those stay in a CSS snippet with conditional loading. 7.1 is not a reason to move them into Additional CSS.

JavaScript snippets: smaller delta, still check

7.1's client-side media processing (HEIC, AVIF, WebP, UltraHDR) and the new crop modal may collide with snippets that hook wp_handle_upload or replace the media modal. After 7.0.4's upload RCE, you should already have an upload-snippet list. Re-open it.

Notes now support inline ranges, rich text, and @ mentions. Snippets that customized the 6.9 block-Notes UI may no-op or clash. Disable and see.

The persistent admin bar will break snippets that assumed "no bar in the site editor" and injected their own jump links. Rare, but it shows up in agency kits.

Abilities API and agents

7.1 continues the Abilities work that started in 6.9 and widened in 7.0. If you register abilities from snippets, regression-test them the same week you test CSS. An agent that calls a renamed ability is a support ticket, not a design issue.

The Snippet Engineer is not a core Ability. It still needs the same human deploy gate after a major. Do not autopilot a "clean up old CSS" prompt against production the night of a release.

A sane 7.1 week for snippet libraries

• Update staging to 7.1, not production first
• Screenshot the five templates you actually sell
• Disable candidate CSS snippets one at a time
• Fix third-party blocks that fail the iframe (that is a plugin update, not a snippet)
• Re-run conditional loading checks — responsive core styles do not mean your JS pixel should go global
• Pull the surviving set through remote sites only after staging is boring

Why this is an SEO page and a maintenance page

Search is about to fill with "WordPress 7.1 custom CSS" and "responsive styles without CSS." Most of those posts will be feature recaps. The useful work is library hygiene: every CSS snippet you delete is one less file that can fight Global Styles, one less cache bust, one less thing a future 7.2 control will duplicate.

Treat 7.1 as a chance to make the snippet list smaller. The plugin's job is to run the CSS that core still cannot express — not to hoard the CSS core just grew.