Working with Global Styles in GeneratePress: My ideas on process and structure in the generative AI world

As developers, we’re constantly looking for ways to streamline our workflow and create maintainable code. When working with GeneratePress and GenerateBlocks (Premium and Pro), the temptation is often to create a utility-first system similar to Tailwind CSS. However, after years of working with clients and teams, I’ve discovered that this approach can actually create more problems than it solves.

Why the Utility Approach Falls Short

The idea of creating multiple utility classes that you can mix and match sounds appealing in theory. You might think about creating classes like .mb-2, .text-center, .bg-blue, and applying multiple classes to achieve your desired styling. But here’s why this doesn’t work well in the GeneratePress ecosystem:

• Slow Creation Process: There’s no easy interface to bulk upload or add global styles. Unless you’re comfortable editing the database directly, creating numerous utility classes becomes a tedious, one-by-one process.
• Complex Application: The process of applying and changing multiple utility classes on blocks creates friction in your workflow.
• Client Confusion: This is the biggest issue. When working with clients or team members who aren’t familiar with your utility system, they’ll inevitably edit or change classes without understanding the broader implications. This breaks your carefully constructed system and creates maintenance headaches.

The Template-First Strategy

Instead of fighting against the platform, I recommend embracing a template-first approach that works with GeneratePress’s block-based philosophy.

Think in Templates, Not Components

Structure your naming convention around specific templates. Your homepage is unique—the hero section there is different from heroes on other pages. Start your class names with the template identifier:

• home-hero-container
• home-featured-services
• about-team-grid
• service-pricing-table

The One-Item Rule

When you have repeating content (cards in a grid, testimonials, product listings), perfect one item first. Design it exactly as intended, ensure it works flawlessly on both desktop and mobile, and only then duplicate and add the rest of your content.

This prevents the messy situation where you’re juggling local styles and global styles, or having to retrospectively add classes to fix inconsistencies.

The One-Class-Per-Element Philosophy

A key principle of this approach is using one class per element. Instead of complex methodologies like BEM or multiple utility classes, assign a single, descriptive class to each element. If you need unique variations, use local overrides sparingly rather than creating additional classes.

This simplification offers several advantages:

• AI Clarity: When instructing AI tools, you can reference exactly one class per element without ambiguity
• Client Safety: Non-technical users can’t accidentally break styling by removing one class while leaving others
• Future Maintenance: Anyone working on the code knows exactly which class controls each element’s styling

Embrace Purposeful Duplication

Here’s a controversial take: some duplication is actually beneficial. If you have a card grid on your homepage and a similar one on a service page, create separate classes for each template:

• home-service-card
• service-page-card

Yes, the styles might be nearly identical, but this approach provides crucial benefits:

• Isolation: Changes to service page cards won’t unexpectedly affect the homepage
• Clarity: Anyone working on the site knows exactly what they’re modifying
• Flexibility: When the client inevitably wants the service page cards “a bit wider” or with “a different border color,” you can make changes confidently

GeneratePress makes this easy—you can copy styles from existing classes when creating new ones, so the duplication overhead is minimal.

Future-Proofing with Semantic Naming

In our AI-driven development landscape, semantic class names aren’t just nice-to-have—they’re essential. As GitHub Copilot and other AI coding assistants become standard tools, clear naming becomes crucial for effective collaboration between humans and AI. Consider this naming structure for a service card:

service-card-wrapper
service-card-top-container
service-card-main-title
service-card-eyebrow
service-card-paragraph
service-card-pricing
service-card-delivery-date
service-card-featured-image

This might seem verbose, but it provides enormous benefits:

Human Readability

Team members and clients can understand the purpose of each element without deep codebase knowledge.

AI Compatibility

When working with AI tools, you can give precise instructions: “modify the service card pricing section” rather than “change the element with class mb-4 text-lg font-bold.” This aligns with best practices for AI-assisted development and makes your codebase more maintainable.

Future-Proof Specificity

As development becomes more AI-assisted, clear, descriptive names will be invaluable. You want to create a “dummy-proof” system that any AI can understand without extensive context.

The Paradigm Shift

This approach represents a shift away from the cryptic, abbreviated naming conventions that many developers have embraced (think mb-0, flex-col, justify-center). While these shortcuts can speed up manual coding, they become liabilities in an AI-assisted workflow. This concept aligns with the semantic web principles that emphasize meaning and context over brevity.

As our tools become more powerful, arguing over a few extra bytes in class names becomes irrelevant. What matters is creating systems that are:

• Immediately understandable to humans and AI
• Specific enough to avoid confusion
• Maintainable by teams with varying skill levels
• Scalable without creating technical debt

Practical Implementation

When starting a new GeneratePress project:

1. Map your templates before writing any global styles
2. Design one element completely before duplicating
3. Use descriptive, template-specific naming with one class per element for maximum clarity
4. Embrace helpful duplication over complex inheritance
5. Think about future maintainers (including AI tools)

This strategy might feel slower initially, especially if you’re used to utility-first frameworks. But the long-term benefits—reduced client confusion, easier maintenance, better team collaboration, and AI compatibility—far outweigh the initial time investment.

The goal isn’t to write the most efficient code for today’s workflow, but to create sustainable systems that will serve your projects (and your sanity) for years to come.