Home

Transforming Your Online Presence Web Design News

Your vision, our design ideas.

Web Design News

We provide comprehensive coverage of the latest news and detailed reviews related to web design.

Read Our Most Recent Posts

• GeneratePress + GenerateBlocks vs Bricks: Which Stack is Better in 2026?
  by Emily
  December 15, 2025

  If you’re building WordPress sites in 2026, you’ve probably heard the debate. Should you go with the GeneratePress theme plus GenerateBlocks combo, or should you switch to Bricks Builder?

  Here’s the thing. Both options are fast and clean. Both will give you 95+ scores on PageSpeed Insights. But they work in completely different ways, and picking the wrong one for your project can cost you time and money.

  I’m going to break down exactly what each option does best, who should use them, and how to decide which one fits your needs.

  What’s the Difference Between These Two Approaches?

  Before we get into the details, you need to understand the basic difference.

  GeneratePress + GenerateBlocks works with WordPress’s native Gutenberg editor. You’re building with blocks, just like you’d write a blog post. GeneratePress is the theme that handles your site structure, and GenerateBlocks adds more powerful design blocks on top.

  Bricks Builder is a theme and visual builder in one. You get a completely different editing interface that lets you build everything visually. It’s a true site builder that replaces both your theme and the standard WordPress editor.

  Both are fast. Both are clean. But your workflow will be totally different.

  GeneratePress + GenerateBlocks: The Details

  How It Works

  GeneratePress is one of the most popular WordPress themes out there. Over 6 million downloads and counting. The free version gives you a lightweight base at just 7.5KB with only 2 HTTP requests.

  When you add GenerateBlocks, you get access to four main blocks: Container, Grid, Headline, and Button. Sounds simple, right? But these four blocks are incredibly powerful because they have deep customization options built in.

  You can build pretty much any layout with just these blocks. The free version works, but the Pro version ($99/year) adds patterns, global styles, and animations that speed things up a lot.

  Pricing Breakdown for 2026

  Here’s where it gets a bit complicated. GeneratePress changed their pricing recently and dropped lifetime plans (though some users grandfathered in still have them).

  Current pricing:

  • GP Premium: $59/year for unlimited sites
  • GenerateBlocks Pro: $99/year
  • GeneratePress One: $149/year (includes GP Premium + GenerateBlocks Pro + pattern library)

  Most people should just get GeneratePress One if they’re serious about this stack. You save money and get everything in one package.

  Who Should Use GeneratePress + GenerateBlocks?

  This combo works best for:

  Content creators and bloggers. If you’re writing lots of blog posts and want a clean, distraction-free writing experience, this is perfect. Your writers can use the same block editor for everything.

  Teams with limited technical skills. Since it uses Gutenberg, anyone who knows WordPress can jump in and start editing. No learning curve for a new builder system.

  People who want to future-proof their sites. As WordPress continues developing Gutenberg, your site will naturally benefit from those improvements.

  Budget-conscious site owners. At $149/year for everything, it’s cheaper than most alternatives.

  The Pros

  • Works with WordPress’s native editor (no context switching)
  • Extremely lightweight and fast
  • Clean, semantic HTML output
  • Great for SEO right out of the box
  • Works with any page builder if you want options
  • Excellent support team that actually teaches you
  • Regular updates and improvements
  • 100+ starter sites included with Premium

  The Cons

  • Learning curve if you’re coming from visual builders like Elementor
  • Limited templates compared to visual builders
  • Not as fast for complex custom designs
  • Free version is very basic (you’ll want Pro)
  • No drag-and-drop interface (it’s block-based)
  • Some advanced features require combining multiple blocks

  Bricks Builder: The Details

  How It Works

  Bricks came out in 2021 and quickly gained a following. It’s not a plugin. It’s a theme with a page builder built right in.

  When you activate Bricks, you get a visual editor for everything. Header, footer, pages, posts, WooCommerce templates. You can see what you’re building in real-time and adjust it on the screen.

  Bricks uses Vue.js 3, which makes the editor incredibly fast. People who switch from Elementor or Beaver Builder usually notice the speed difference immediately.

  Pricing for 2026

  Bricks pricing has changed over the years. Here’s what it looks like now:

  Yearly plans:

  • Starter: $79/year for 1 site
  • Business: $149/year for unlimited sites

  Lifetime option:

  • Ultimate: $599 one-time payment for unlimited sites

  The lifetime deal used to be much cheaper ($99-$249), but those days are gone. Still, if you’re building client sites or managing multiple projects, the lifetime option pays for itself.

  Important note: Bricks will increase prices again in 2025/2026 as they release version 2.0. If you’re interested, grab it now before it goes up.

  Who Should Use Bricks?

  Bricks is better for:

  Designers and developers who want complete visual control. If you’re building custom agency sites or unique branded experiences, Bricks gives you the freedom to create whatever you can imagine.

  People building complex layouts. Custom loops, dynamic content, WooCommerce sites with custom product pages. Bricks handles this stuff better than block-based editors.

  Freelancers and agencies managing multiple client sites. The visual interface makes it easier to hand off to clients, and you can build faster once you know the system.

  Anyone switching from Oxygen Builder. Bricks is basically the natural upgrade path if Oxygen feels too complicated.

  The Pros

  • Visual editing for everything (header to footer)
  • Super fast editor and page loads
  • 50+ elements with more being added
  • Excellent for dynamic content and custom post types
  • Works great with ACF and Meta Box
  • Clean code output
  • No jQuery dependencies
  • Lifetime license available
  • Growing community and third-party add-ons
  • Query loop builder for custom displays
  • Global elements and styles
  • Can convert pages to/from Gutenberg

  The Cons

  • Steeper learning curve than Gutenberg
  • Limited template library compared to Elementor
  • No popup builder (yet)
  • Some marketing integrations missing
  • Switching themes means rebuilding your site
  • Newer product (less mature than GeneratePress)
  • No free version to test (but there’s a sandbox)
  • Higher upfront cost

  Performance: How Do They Actually Compare?

  Both options are fast. Like, really fast. You’ll see 95+ on PageSpeed Insights with either one if you set things up correctly.

  GeneratePress is slightly lighter because it loads less by default. But Bricks is also built for performance with features like:

  • Lazy loading for images and videos
  • Conditional CSS loading
  • Native SVG support
  • Minimal HTTP requests

  In real-world testing, most people won’t notice a difference between the two. Your hosting, images, and plugins will affect speed more than your choice between these builders.

  The Design Workflow: Block Editor vs Visual Builder

  This is where things get interesting.

  Working with GeneratePress + GenerateBlocks

  You build pages by adding blocks and configuring them. It feels like writing a document with styled sections. You’re working more with settings panels than dragging things around.

  At first, this feels slower if you’re used to visual builders. But once you get the hang of it, you can move pretty fast. The Pro version includes 200+ patterns that you can drop in and customize.

  The biggest advantage? Everything you build works in the standard WordPress editor. Any content editor on your team can jump in without training.

  Working with Bricks

  You see your design update in real-time as you build. Want to move that section? Drag it. Want to change the background? Click and adjust. It’s more intuitive for visual thinkers.

  The structure panel shows you exactly how everything is nested. The settings are consistent across elements. Once you learn the interface, you can build complex sites incredibly fast.

  The downside? It’s a proprietary system. If you ever switch themes, you’ll need to rebuild your designs.

  Which One Should You Actually Choose?

  Here’s my honest take after looking at both options in 2026.

  Choose GeneratePress + GenerateBlocks if:

  • You run a blog or content-heavy site
  • You have multiple people editing content
  • You want something that will work well with future WordPress updates
  • You’re on a tighter budget
  • You like working with WordPress’s native tools
  • You value simplicity over visual complexity
  • Your clients need to manage their own content easily

  Choose Bricks if:

  • You’re building custom designs for clients
  • You want maximum visual control
  • You work with a lot of dynamic content
  • You’re comfortable learning a new system
  • You’re building WooCommerce stores with custom templates
  • You value speed in your build process once you’re trained
  • You can afford the higher upfront cost

  What About Using Both?

  Some developers actually use both. They’ll use GeneratePress + GenerateBlocks for content sites and blogs, then switch to Bricks for complex agency work or WooCommerce projects.

  There’s nothing wrong with this approach if you’re managing different types of projects.

  Real User Experiences

  Looking at what people actually say about these tools helps a lot.

  GeneratePress + GenerateBlocks users consistently praise the support team, the clean code, and how easy it is to hand off to clients. The main complaint is that it takes longer to build complex designs compared to visual builders.

  Bricks users love the speed of the editor and the visual workflow. They appreciate the lifetime pricing option. The main complaints are about the limited template library and the fact that some features are still missing compared to more mature builders.

  The Bottom Line for 2026

  Both options are solid. You can’t really go wrong with either one if you pick the right tool for your use case.

  GeneratePress + GenerateBlocks is the safer, more WordPress-native choice. It’s perfect for content sites, blogs, and teams. At $149/year for everything, it’s also more affordable.

  Bricks is the better choice for visual builders, designers, and anyone who needs maximum control over complex layouts. The lifetime option makes sense if you’re in this for the long haul.

  My recommendation? If you’re not sure, start with GeneratePress One. Use it on a few projects. If you find yourself fighting the block editor and wishing for more visual control, then try Bricks. The $599 lifetime investment might be worth it.

  But if GeneratePress works for you? Stick with it. It’s fast, it’s clean, and it’s not going anywhere.

  FAQ

  Can I switch from GeneratePress to Bricks later?

  Yes, but you’ll need to rebuild your pages. Bricks can convert Gutenberg blocks to Bricks format, but it’s not perfect. Plan on spending time recreating your designs if you switch.

  Is Bricks really faster than GeneratePress?

  Both are fast. Bricks gives you a faster visual editing experience. GeneratePress might be slightly lighter on page load. The difference is minimal in real-world use.

  Do I need to know coding to use either option?

  No coding required for basic use with either option. But knowing some CSS helps with both, especially for custom designs. Bricks has a steeper learning curve, but you still don’t need to code.

  What happens if I stop paying for these?

  With GeneratePress, you keep your site but lose updates and support. Same with Bricks yearly plans. The Bricks lifetime license means you keep everything forever.

  Can I use GenerateBlocks without GeneratePress?

  Yes. GenerateBlocks works with any WordPress theme. But it pairs best with GeneratePress because they’re built by the same team and designed to work together.

  Which one has better customer support?

  Both have excellent support. GeneratePress users consistently praise the support team for being helpful and educational. Bricks support is also good and responsive, though the community is smaller since it’s newer.

  Is the Bricks lifetime deal worth it in 2026?

  If you’re building multiple sites or client sites, yes. At $599 for unlimited sites forever, it pays for itself after a few years compared to yearly plans. But the pricing will likely increase, so grab it sooner rather than later.

• 
  Bricks Builder Fluid Typography Tutorial (With Settings You Can Copy)
  by Emily
  December 15, 2025

  Your site looks great on desktop. Then someone opens it on their phone and the text is either microscopic or comically huge. Sound familiar?

  This is exactly what fluid typography solves. And since Bricks 2.1, you don’t need to mess with complicated CSS math or external tools to make it work.

  Here’s how to set up fluid typography in Bricks Builder that actually works across every device.

  What Is Fluid Typography (And Why You Need It)

  Fluid typography means your text size adjusts smoothly as the screen size changes. Not in sudden jumps at breakpoints, but gradually as someone resizes their browser or views your site on different devices.

  Think about it this way. Traditional responsive design uses media queries. You might say “at 768px wide, make this heading 24px” and “at 1200px wide, make it 32px.” But what happens at 900px? Or 1150px? The text stays at whatever size you set for the previous breakpoint.

  With fluid typography, the text scales smoothly between those points. At 768px it’s 24px. At 1200px it’s 32px. And at 900px? It’s somewhere in between, calculated automatically.

  The system uses CSS variables with clamp functions to create font sizes that scale smoothly between minimum and maximum values, which means better readability on every screen without manually setting sizes for multiple breakpoints.

  How CSS Clamp Makes This Work

  Before Bricks built this feature in, developers had to write clamp functions manually. Let me break down what’s actually happening under the hood so you understand why this works.

  The clamp function takes three values:

  Minimum value – The smallest your text can get (usually for mobile) Preferred value – The responsive size that adapts to screen width Maximum value – The largest your text can get (usually for desktop)

  Here’s what a clamp function looks like in CSS:

  font-size: clamp(16px, 1rem + 2vw, 32px);

  This tells the browser: “Make this text at least 16px, at most 32px, and ideally calculate it as 1rem plus 2% of the viewport width.”

  The preferred value uses viewport width units (vw) to determine how fluid typography scales, controlling the starting and ending points of fluid behavior and change speed.

  The math gets complicated fast when you’re trying to calculate the exact viewport width unit and relative size needed. That’s why Bricks building this into the interface is such a big deal.

  Accessing the Fluid Typography Generator

  Bricks gives you two ways to access the typography generator.

  Method 1: Through the Variable Manager

  1. Open any page in Bricks Builder
  2. Look for the variable manager icon in the top toolbar
  3. Click the “Aa” icon in the header
  4. This opens the Fluid Typography Generator

  Method 2: Through Theme Styles

  1. Click the settings gear icon (top left)
  2. Go to Theme Styles
  3. Navigate to the Typography section
  4. Click on “Fluid Typography” control

  Both methods open the same generator. Use whichever feels more natural in your workflow.

  Creating Your First Typography Scale

  Let’s walk through setting up a basic fluid typography scale for headings.

  Step 1: Create a Category

  Categories in Bricks are basically separate typography scales. Most people need at least two: one for headings and one for body text.

  Click “Add Category” and name it “Headings.” This scale will store all your heading sizes.

  Step 2: Choose Your Scale Type

  Bricks offers three naming conventions:

  T-shirt sizes – Uses 2xs, xs, s, m, l, xl, 2xl Numeric – Uses numbers like 1, 2, 3, 4, 5, 6 Custom – You define the names (like “small,” “medium,” “large,” “title”)

  For headings, I usually go with numeric because it maps nicely to H1 through H6. Your variables will be named things like --headings-1, --headings-2, etc.

  Step 3: Set Your Baseline

  The baseline is your starting point. Every other size in the scale is calculated from this.

  Let’s say you want your baseline (H4) to be 18px on mobile and 22px on desktop. Enter those values in the minimum and maximum fields.

  Step 4: Choose a Scale Ratio

  This determines how much bigger or smaller each step is compared to the baseline.

  Common ratios:

  • 1.125 (Major Second) – Subtle scaling, good for conservative designs
  • 1.25 (Major Third) – Moderate scaling, most versatile
  • 1.333 (Perfect Fourth) – Bold scaling, good for dramatic headings
  • 1.5 (Perfect Fifth) – Very bold, use sparingly

  Pick 1.25 for now. With a baseline of 16px and a scale ratio of 1.5, the next step above the baseline calculates as 24px, with ratios applied upward and downward to generate consistent scaling in both directions.

  Step 5: Generate Variables

  Click the up arrow button to create a larger variable (for H3, H2, H1). Click it three times.

  Click the down arrow button to create smaller variables (for H5, H6). Click it twice.

  Bricks automatically calculates all the sizes based on your baseline and ratio.

  Step 6: Preview and Adjust

  Click the eye icon to open the preview panel. You’ll see each variable displayed at its actual size, with both minimum and maximum values shown.

  Type in custom preview text if you want to see how real words look at each size.

  If something looks off, you can manually edit any variable by clicking on it in the center column. This won’t affect the other calculations.

  Creating a Body Text Scale

  Now let’s set up a second scale for body text and smaller elements.

  Create another category called “Text.”

  This time, use t-shirt sizing (xs, s, m, l, xl) since it’s not tied to HTML heading elements.

  Set your baseline to something like 16px minimum and 18px maximum. Body text shouldn’t vary as dramatically as headings.

  Use a smaller ratio like 1.125 for more subtle size differences.

  Generate a few variables above and below the baseline.

  Using Typography Variables in Your Designs

  Here’s where it gets practical. You’ve got these variables generated. Now what?

  Applying to Theme Styles

  The smartest approach is to set these variables in your Theme Styles so they apply site-wide.

  1. Go to Theme Styles > Typography
  2. Under Body, set the font size to your baseline text variable
  3. Under H1, set the font size to your largest heading variable
  4. Repeat for H2 through H6

  Now every new heading or text element you add automatically uses fluid typography.

  Applying to Individual Elements

  You can also apply variables to specific elements:

  1. Select any text element in the builder
  2. Go to the Typography controls
  3. In the font size field, type two dashes --
  4. A dropdown appears showing all your typography variables
  5. Select the one you want

  The element now scales fluidly across all screen sizes.

  Creating Utility Classes

  If you want to apply sizes without touching HTML heading tags, generate utility classes.

  In Bricks 2.2, the Style Manager lets you define class names that map to your variables. For example, create a class called .text-xl that uses your --text-xl variable.

  Now you can apply that class to any element, regardless of whether it’s actually an H1, H2, or paragraph.

  Our Recommended Settings (Copy These)

  If you want to skip the experimenting and just start with settings that work, here’s what we recommend for most websites.

  These settings have been tested across hundreds of projects and provide excellent readability on all devices while maintaining visual hierarchy.

  For Headings:

  • Category name: Headings
  • Scale type: Numeric (maps to H1-H6)
  • Baseline variable: 4 (this will be your H4)
  • Minimum size (mobile): 18px
  • Maximum size (desktop): 22px
  • Scale ratio: 1.25 (Major Third)
  • Variables to generate: 3 steps up, 2 steps down

  This gives you:

  • H1: 35px min → 43px max (your hero/page titles)
  • H2: 28px min → 34px max (section headings)
  • H3: 22px min → 27px max (sub-sections)
  • H4: 18px min → 22px max (smaller headings)
  • H5: 14px min → 18px max (minor headings)
  • H6: 11px min → 14px max (rarely used, but available)

  For Body Text & UI:

  • Category name: Text
  • Scale type: T-shirt sizes (xs, s, m, l, xl)
  • Baseline variable: m (your standard paragraph text)
  • Minimum size (mobile): 16px
  • Maximum size (desktop): 18px
  • Scale ratio: 1.125 (Major Second)
  • Variables to generate: 2 steps up, 2 steps down

  This gives you:

  • XL: 20px min → 23px max (lead paragraphs, important callouts)
  • L: 18px min → 20px max (slightly emphasized text)
  • M: 16px min → 18px max (standard body text)
  • S: 14px min → 16px max (captions, footnotes, metadata)
  • XS: 12px min → 14px max (legal text, tiny labels)

  Theme Style Mappings:

  Once you generate these, go to Theme Styles and set:

  • Body → Font Size: --text-m
  • H1 → Font Size: --headings-1
  • H2 → Font Size: --headings-2
  • H3 → Font Size: --headings-3
  • H4 → Font Size: --headings-4
  • H5 → Font Size: --headings-5
  • H6 → Font Size: --headings-6

  Line Height Settings:

  Fluid font sizes need proportional line heights. Set these in Theme Styles:

  • Body → Line Height: 1.6
  • H1-H3 → Line Height: 1.2
  • H4-H6 → Line Height: 1.4

  Why These Settings Work:

  The 1.25 ratio for headings creates clear visual hierarchy without being too dramatic. Headlines stand out but don’t overwhelm the page.

  The 1.125 ratio for body text provides subtle size variations. You get enough difference between sizes to be useful, but not so much that it looks inconsistent.

  Starting body text at 16px minimum ensures readability on mobile. Anything smaller strains the eyes.

  The 18px-22px baseline for H4 is strategic. It’s large enough to work as a subheading but not so large that you can’t use it frequently.

  Feel free to adjust these based on your specific design needs, but this is a solid starting point that works for most content-focused websites.

  Real World Example: Setting Up a Complete Site

  Let me walk you through how I’d set up fluid typography for an actual project using slightly different values to show flexibility.

  Headings Scale:

  • Category name: “Headings”
  • Scale type: Numeric
  • Baseline (H4): 18px min, 22px max
  • Ratio: 1.333 (Perfect Fourth)
  • Generated variables:
    • H1: 32px min, 44px max
    • H2: 24px min, 33px max
    • H3: 18px min, 25px max
    • H4: 18px min, 22px max (baseline)
    • H5: 13px min, 16px max
    • H6: 10px min, 12px max

  Body Text Scale:

  • Category name: “Text”
  • Scale type: T-shirt
  • Baseline (M): 16px min, 18px max
  • Ratio: 1.125 (Major Second)
  • Generated variables:
    • XL: 20px min, 23px max
    • L: 18px min, 20px max
    • M: 16px min, 18px max (baseline)
    • S: 14px min, 16px max
    • XS: 13px min, 14px max

  In Theme Styles, I’d map these:

  • Body text: --text-m
  • H1: --headings-1
  • H2: --headings-2
  • And so on

  For any special cases (like a hero headline that needs to be huge), I’d create a custom variable in the generator with extreme min/max values.

  Common Mistakes and How to Fix Them

  Mistake 1: Using Too Many Different Scales

  Don’t create 5 or 6 different typography categories. Stick with 2-3 maximum (headings, body text, maybe a special scale for UI elements).

  More scales means more variables to manage and increases the chance of inconsistency.

  Mistake 2: Extreme Min/Max Differences

  If your minimum is 12px and your maximum is 60px, the text might look fine at the extremes but weird in the middle ranges.

  Keep the ratio between min and max reasonable. A good rule of thumb: max should be no more than 2-2.5x the min.

  Mistake 3: Ignoring Line Height

  Fluid font sizes are great, but if your line height doesn’t adjust proportionally, text becomes hard to read.

  In Bricks, you can set line heights using relative units (like 1.5) that scale with the font size. Do this in Theme Styles alongside your fluid font sizes.

  Mistake 4: Not Testing Across Devices

  The preview panel in Bricks shows you the extremes, but always test your actual site on real devices.

  Grab your phone. Resize your browser window. Make sure text remains readable at every size.

  Advanced Tips for Power Users

  Combining with Container Queries

  Bricks supports container queries. You can make typography respond to the container width instead of viewport width.

  This is useful for modular components that need to look good in different contexts (sidebar, full width, etc.).

  Importing External Scales

  Tools like Utopia or Type Scale generate clamp values you can import. External fluid scale variables can be copied and imported into Bricks through the CSS Variable Manager, with clamp variables automatically becoming available as Bricks variables.

  Copy the CSS variables from these tools, paste them into Bricks’ variable importer, and they integrate seamlessly.

  Exporting for Reuse

  Once you’ve built a perfect typography system, export it as JSON from the variable manager.

  Import this JSON into new projects to instantly replicate your typography setup. Huge time saver for agencies working on multiple sites.

  Custom Ratios for Specific Needs

  The preset ratios work for most cases, but you can enter custom ratios if needed.

  For example, if you need something between 1.25 and 1.333, enter 1.29. Bricks calculates everything based on your custom value.

  Bricks 2.2 Enhancements

  If you’re on Bricks 2.2 beta or later, you get extra features in the Style Manager.

  The new Typography & Spacing Scale generator lives in the Style Manager interface, which consolidates everything in one place.

  You can now generate utility classes directly from the scale generator. Define class names and CSS properties (font-size, margin, whatever) that map to your scale variables.

  The preview mode is more robust too. You can add or remove variables right from the preview panel, test different text samples, and see exactly how each variable behaves.

  The CSS export feature lets you download your entire scale as a file, which is useful for documentation or sharing with developers.

  Accessibility Considerations

  Fluid typography isn’t just about looking good. It affects accessibility too.

  Using vw units alone creates accessibility problems because they don’t respond to zoom functionality, failing to meet WCAG criteria for resizing text.

  Bricks handles this correctly by combining rem units with vw units in the clamp calculation. When users zoom in or adjust their browser’s default font size, your fluid typography respects that.

  But there are still things to watch:

  Don’t Go Too Small

  Never let your minimum font size drop below 14px for body text. Ideally, keep it at 16px or above.

  Smaller text might look sleek on your design mockups, but it’s hard to read for many people.

  Test with Different Font Sizes

  Change your browser’s default font size setting and see if your site still works. Good fluid typography should adapt.

  Consider Contrast

  Smaller text needs higher contrast to remain readable. If you’re using light text on dark backgrounds (or vice versa), make sure contrast ratios meet WCAG AA or AAA standards.

  When NOT to Use Fluid Typography

  Fluid typography isn’t always the answer.

  Fixed-Width Designs

  If your site has a fixed max-width container that never changes, fluid typography adds complexity without benefit. Just set static sizes.

  Print Stylesheets

  Don’t use viewport-based units in print styles. They don’t make sense when there’s no viewport.

  Small UI Elements

  Buttons, badges, labels, and other small UI components usually work better with fixed sizes. They need to be predictable across all screen sizes.

  When Client Requests Static Sizes

  Some clients have brand guidelines that specify exact font sizes. In those cases, you might use fluid typography for the general content but fixed sizes for branded elements.

  Comparing to External Tools

  Before Bricks 2.1, most people used external calculators or frameworks.

  Tools like Utopia, Type Scale, and Fluid Typography Calculator are still useful for generating the math, but Bricks eliminates the copy-paste workflow.

  External fluid typography calculators now include Bricks Builder export options, allowing download of clamp-based CSS variables as JSON files, which shows how popular Bricks’ native integration has become.

  CoreFramework and ACSS both offered fluid typography features, but now that Bricks has it built in, you don’t need those frameworks unless you’re using other features they provide.

  The benefit of Bricks’ native approach: no extra plugins, no syncing between systems, no compatibility concerns with updates.

  Troubleshooting Common Issues

  Variables Not Appearing

  Make sure you’ve saved your typography scale after generating it. Unsaved changes don’t create the actual CSS variables.

  Text Not Scaling

  Check that you’re actually using the variables, not hard-coded pixel values. Look in the browser inspector to verify the CSS.

  Weird Sizes at Certain Viewports

  This usually means your min/max range is too wide or your ratio is too aggressive. Adjust one or both until it looks right across the range.

  Variables Showing in Editor But Not Frontend

  Clear your cache. Both browser cache and any caching plugins you’re running. Bricks generates these as CSS variables, and aggressive caching can serve stale versions.

  FAQ

  Can I use fluid typography with custom fonts?

  Yes. The fluid typography system works with any font family. Upload your custom fonts through Bricks’ Font Manager, then apply the fluid size variables to elements using those fonts.

  Does fluid typography work with the Classic Editor or only Bricks-built pages?

  Fluid typography variables are global CSS variables. They work anywhere on your site, including Classic Editor content, as long as you reference the variables in your CSS or apply the generated utility classes.

  How do I convert an existing site to fluid typography?

  Create your fluid scales in the generator. Then go through your Theme Styles and replace fixed font sizes with the appropriate variables. Most of your site will update automatically. For custom classes or inline styles, you’ll need to manually update those.

  Can I have different fluid scales for different templates?

  You can create multiple scales in categories, but they’re site-wide variables. If you need truly different scales per template, you’d need to create uniquely named variables for each and apply them through template-specific classes.

  What happens on really wide monitors (like 4K)?

  The maximum value in your clamp function caps how large text can get. On a 4K monitor, your text stays at the maximum you defined, it doesn’t keep growing infinitely.

  Is there a performance impact from using clamp and CSS variables?

  Negligible. CSS variables and clamp are native browser features with excellent performance. The calculation happens once per render and is highly optimized.

  Can I use different ratios for different parts of the scale?

  Not automatically. The generator applies one ratio across the entire scale. But you can manually edit individual variables after generation to use different ratios for specific steps.

  How does this work with CSS frameworks like Tailwind?

  If you import Tailwind into Bricks, your fluid typography variables coexist with Tailwind’s classes. You can use both in the same project. The CSS Framework Importer in Bricks 2.2 makes this even easier.

  Do I need to update anything when Bricks updates?

  Your fluid typography scales are stored as data in your WordPress database. Bricks updates don’t affect them. The generator might get new features, but your existing scales keep working.

  Can I share my typography scales between multiple sites?

  Yes. Export your variables as JSON from one site, import them into another. This includes your entire typography system with all scales and settings.

• 
  Bricks Builder’s Native CSS Framework: Do You Still Need CoreFramework and ACSS?
  by Emily
  December 15, 2025

  Bricks Builder just changed the game with version 2.2. After years of developers relying on external CSS frameworks like CoreFramework and Automatic.css to manage design systems, Bricks finally built these capabilities right into the builder itself.

  Here’s the question everyone’s asking: Do you still need those external frameworks?

  The short answer: Probably not anymore.

  Let me explain why.

  What Changed in Bricks 2.2

  On December 10, 2025, Bricks released version 2.2 beta with something the community had been requesting for years. The new Style Manager centralizes everything you used to need external frameworks for, including color palettes, typography scales, spacing systems, and CSS variables.

  But the real show-stopper is the CSS Framework Importer.

  This tool lets you paste CSS from any framework (Tailwind, Bootstrap, CoreFramework, ACSS, whatever) and Bricks automatically extracts the classes and variables. It sorts them into categories, lets you add prefixes to avoid conflicts, and imports everything with one click.

  No plugins. No syncing. No waiting for updates.

  Everything lives natively inside Bricks now.

  Why People Started Using CoreFramework in the First Place

  CoreFramework became popular with Bricks users for good reasons. It solved real problems that Bricks didn’t handle well on its own.

  Before version 2.2, managing design tokens across multiple projects was a pain. You’d manually set up color palettes, spacing scales, and typography systems for every single site. CoreFramework changed that by giving you a visual interface where you could define everything once, then export it as CSS.

  The framework offered:

  • Centralized color management with automatic shade generation
  • Fluid typography that scales smoothly across breakpoints
  • Spacing variables that work consistently site-wide
  • A library of utility classes for common styling tasks
  • Dark mode support built in

  The Bricks addon (which costs €119) made it even better by integrating directly with the builder. You could right-click on any input field to select variables through a visual UI. Classes and variables synced automatically between CoreFramework and Bricks.

  For agencies building multiple sites, this was huge. Set up your design system once in CoreFramework, import it into Bricks, and you’re done.

  The CoreFramework Workflow (Before Bricks 2.2)

  Let me walk you through what using CoreFramework with Bricks looked like.

  First, you’d set up your project in the CoreFramework web app or WordPress plugin. You’d define your colors, typography scale, spacing system, and breakpoints. The interface made this pretty straightforward.

  Then came the matching game. Bricks has default settings that don’t align with CoreFramework out of the box. The default container width in Bricks is 1100px. CoreFramework uses 1400px. You’d need to create a global theme style in Bricks and manually match these values.

  Same thing with breakpoints. Bricks defaults to 1279px, 991px, 767px, and 478px. CoreFramework uses 1400px, 992px, 768px, and 480px. You’d have to enable custom breakpoints in Bricks and align them manually.

  After all that setup, you’d export your CSS from CoreFramework and import the classes into Bricks. The Bricks addon helped here, but you were still managing two separate systems.

  Updates meant repeating this process. Change a color in CoreFramework? Export and re-import. Tweak your spacing scale? Same thing.

  It worked. But it added complexity.

  What About Automatic.css (ACSS)?

  ACSS took a different approach than CoreFramework. Instead of giving you an external interface to manage your design system, it focused on providing a comprehensive set of utility classes and intelligent defaults.

  The framework handles responsive typography, fluid spacing, and automatic color shades. It includes utilities for things like overlays, flex grids, and form styling that you’d otherwise code manually.

  ACSS integrates deeply with Bricks through setup files you import. There’s a Bricks Settings JSON file and a Bricks Theme file that configure everything automatically. After setup, you apply classes directly in the builder.

  The pricing is different too. ACSS costs $249 per year for unlimited sites across all supported builders, or $649 for lifetime access. No per-builder charges like CoreFramework.

  Where ACSS really shines is education. Creator Kevin Geary provides extensive tutorials and resources. If you’re learning web design alongside using the framework, that educational component has real value.

  How Bricks 2.2 Changes Everything

  The new Style Manager in Bricks 2.2 isn’t just a minor update. It’s a complete design system built into the page builder itself.

  Here’s what you get natively now:

  Color Management Create and manage color palettes directly in Bricks. The system supports HSL-based colors with automatic shade generation (light, dark, transparent). You can generate complementary colors, set up dark mode variants, and export everything as CSS variables.

  This matches what CoreFramework offered, but without switching between tools.

  Typography Scales Define minimum and maximum font sizes with scaling ratios. Bricks generates fluid typography variables that adapt between breakpoints automatically. You can preview how each scale step looks and export utility classes.

  Spacing Scales Same concept as typography. Set your base spacing values, define a scale, and Bricks creates the variables and utility classes for you. Use them consistently across your entire site.

  CSS Variables Manager Create, organize, and categorize CSS variables in a visual interface. Bulk rename, add prefixes, export to JSON. Everything you used to do in CoreFramework or ACSS, but native to Bricks.

  Framework Importer This is the game-changer. Paste any CSS framework’s stylesheet into the code editor. Bricks automatically extracts classes and groups them into categories (layout, colors, typography, etc.). Add prefixes to avoid conflicts. Choose which categories to import. Done.

  You can import CoreFramework’s CSS if you want. Or ACSS. Or Tailwind. Or your own custom framework. Bricks doesn’t care. It extracts what it needs and makes it available throughout the builder.

  Real-World Workflow Comparison

  Let’s look at a practical example. You’re starting a new project and want to set up your design system.

  The Old Way (with CoreFramework)

  1. Log into CoreFramework web app or plugin
  2. Set up your project preferences
  3. Define color palette, typography, spacing
  4. Match container widths between CF and Bricks
  5. Align breakpoints manually
  6. Export CSS from CoreFramework
  7. Import classes into Bricks
  8. Install and configure the Bricks addon (if you bought it)
  9. Make a change later? Repeat steps 6-7

  The New Way (with Bricks 2.2)

  1. Open the Style Manager in Bricks
  2. Define your color palette (with auto-shade generation)
  3. Set up your typography scale
  4. Create your spacing system
  5. Generate utility classes if you want them
  6. Start building

  Everything stays in one place. No exports, no imports, no syncing.

  And if you already have a framework you like? Import it once with the CSS Framework Importer and you’re done.

  What You Lose by Ditching External Frameworks

  Being honest here – there are a few things CoreFramework and ACSS still do better.

  CoreFramework Advantages

  The standalone web app lets you manage your frameworks outside WordPress. If you work across different platforms or need to share design systems with non-WordPress team members, that’s useful.

  The Figma integration is unique. You can sync your design tokens between CoreFramework and Figma, which helps with design handoffs.

  Some of the components library features (pre-styled buttons, forms, badges) save time if you’re starting from scratch often.

  ACSS Advantages

  The utility class library is more comprehensive than what Bricks generates by default. Things like overlay utilities, object-fit helpers, ribbon classes, and form styling aren’t built into Bricks yet.

  Kevin Geary’s educational content is legitimately valuable if you’re still learning CSS and design systems. The framework comes with hours of tutorials and a support community.

  ACSS includes integrations with form builders like WS Forms and Fluent Forms. Style an entire form in seconds by applying pre-made classes.

  The contextual menus in ACSS let you preview what a class does before applying it. That’s helpful when learning the system.

  The Cost Factor

  Money matters, especially if you’re a freelancer or small agency.

  CoreFramework Pricing

  • Free standalone web app
  • WordPress plugin: Free
  • Bricks addon: €119 one-time
  • Each builder addon costs separately (Oxygen, Gutenberg)

  ACSS Pricing

  • $249/year for unlimited sites, all builders
  • $649 lifetime access

  Bricks 2.2 Native Features

  • Free (included with your Bricks license)

  If you’re only building Bricks sites, the native features don’t cost you anything extra. For agencies using multiple builders, CoreFramework’s per-builder pricing adds up. ACSS gives you one price for everything, which is cleaner.

  But free is hard to beat.

  The Facebook Controversy (Briefly)

  Some CoreFramework users on Facebook have called out Bricks for “copying” their features. Comments like “This looks suspiciously like Core’s variable system” popped up in beta discussion threads.

  Here’s the thing: Bricks didn’t copy CoreFramework. They listened to their community.

  For years, Bricks users have asked for native design system tools. They praised frameworks like CoreFramework for filling gaps, but they also wanted built-in solutions. No plugin dependencies, no syncing headaches, no extra costs.

  Bricks delivered that in version 2.2.

  Did they implement similar concepts? Yes. Centralized variables, color management, framework importing – these are proven patterns that work. But implementing a proven pattern isn’t stealing. It’s good product development.

  CoreFramework and ACSS can now focus on advanced features and niche enhancements while Bricks handles the core functionality everyone needs.

  Who Should Still Use External Frameworks

  Bricks 2.2 doesn’t make CoreFramework and ACSS obsolete for everyone.

  Stick with CoreFramework if:

  • You work across multiple platforms (not just WordPress)
  • You need Figma integration for design handoffs
  • You prefer managing frameworks outside WordPress
  • You’re already deep into their ecosystem and workflow

  Stick with ACSS if:

  • You value the comprehensive utility library
  • You’re still learning and benefit from the education
  • You need form builder integrations (WS Forms, Fluent Forms)
  • You work with multiple page builders regularly

  Switch to Bricks Native if:

  • You only build with Bricks
  • You want to simplify your tech stack
  • You’re tired of managing plugins and syncing
  • You’re starting fresh projects
  • You want better performance (fewer dependencies)

  For most Bricks users, the native features will be enough. You’ll build faster, maintain simpler sites, and avoid subscription or addon costs.

  My Take: Go Native

  After digging into Bricks 2.2, I think most people should use the native features.

  The Style Manager gives you everything you need for professional design systems. Color management, typography scales, spacing systems, CSS variables – it’s all there. The CSS Framework Importer means you’re not locked in. Import what you want, when you want it.

  Your sites will load faster without extra plugins. Your workflow will be simpler without jumping between tools. Your stack will be cleaner without managing subscriptions or license keys.

  And you’ll save money.

  CoreFramework and ACSS filled real gaps in earlier Bricks versions. But Bricks 2.2 filled those gaps natively. The frameworks did their job so well that Bricks incorporated the concepts into the core product.

  That’s not copying. That’s evolution.

  Getting Started with Bricks 2.2 Beta

  Want to try this yourself? Here’s how to get the beta.

  Important: Do NOT use beta versions on production sites.

  1. Log into your Bricks account at https://my.bricksbuilder.io
  2. Download the Bricks 2.2 beta
  3. Install it on a staging site or local development environment
  4. Open any page in the builder
  5. Click the settings gear icon
  6. Explore the new Style Manager

  Start by creating a color palette. The shade generation alone will save you hours. Then set up your typography scale and spacing system. Generate some utility classes if you want them.

  Import a framework if you’re curious. The importer works with any CSS file.

  Build a test page using the native features. See how it feels.

  The beta is stable enough for testing but expect some rough edges. That’s normal. Report any bugs you find to the Bricks team.

  FAQ

  Can I import my existing CoreFramework or ACSS setup into Bricks 2.2?

  Yes. Use the CSS Framework Importer in the Style Manager. Export your CSS from CoreFramework or ACSS, then paste it into the importer. Bricks will extract the classes and variables automatically.

  Will Bricks 2.2 break my existing sites that use external frameworks?

  No. The new features are additive. If you’re using CoreFramework or ACSS on existing sites, they’ll keep working. You can migrate to native features gradually or stick with your current setup.

  Does the Style Manager replace theme styles completely?

  Not entirely. Theme styles still control element defaults (containers, sections, etc.). The Style Manager focuses on design tokens (colors, typography, spacing) and utility classes. They work together.

  Can I use both native features and external frameworks at the same time?

  Technically yes, but it’s messy. You’ll end up with duplicate classes and variables. Pick one approach and stick with it. If you’re starting fresh, use the native features.

  What happens to my CoreFramework or ACSS subscription if I switch to native Bricks?

  Nothing changes unless you cancel. If you decide you don’t need the external framework anymore, you can choose not to renew. But there’s no rush – test the native features first and make sure they cover your needs.

  Is the CSS Framework Importer a one-time thing or can I update imported frameworks?

  You can re-import anytime. If your external framework updates, export the new CSS and import it again. Bricks will replace the old classes and variables with new ones.

  Does Bricks 2.2 have as many utility classes as ACSS?

  Not yet. ACSS has a more comprehensive utility library out of the box. But you can generate custom utilities in Bricks or import ACSS classes if you need them. The gap isn’t as big as it used to be.

  Will this work with other page builders like Oxygen?

  No. The Style Manager is Bricks-specific. Oxygen and other builders have their own systems. If you work across multiple builders, frameworks like ACSS (which support multiple builders) still make sense.

  When will Bricks 2.2 stable be released?

  Bricks hasn’t announced an exact date yet. Based on their release history, the stable version should come within a few weeks of the beta. Check the official Bricks changelog for updates.

  Can I go back to my old workflow if I don’t like the new features?

  Absolutely. The Style Manager is optional. If you prefer your existing CoreFramework or ACSS setup, keep using it. Nothing forces you to switch.

• 
  Never Run Out of Ideas: Top Tips for Generating Fresh Blog Topics
  by Emily
  November 14, 2025

  Introduction

  One of the biggest challenges for bloggers is consistently coming up with new and interesting topics. This post will share practical tips to help you find inspiration and keep your blog fresh and engaging.

  

  1. Stay Informed in Your Niche

  Regularly read other blogs, news sites, and publications in your niche. Staying informed helps you identify trending topics and gaps in existing content.

  2. Use Keyword Research Tools

  Keyword research tools can reveal what your target audience is searching for. This data can inspire topics that are both relevant and SEO-friendly.

  3. Engage with Your Audience

  Listen to your audience. Comments, emails, and social media interactions can provide insights into what your readers are interested in.

  4. Explore Competitors’ Blogs

  Check out what your competitors are writing about. This can spark ideas for topics that you can approach from a unique angle.

  5. Keep an Idea Journal

  Always keep a journal or digital note-taking app handy to jot down ideas as they come to you.

  6. Repurpose Old Content

  Look at your older posts. Can they be updated, expanded, or spun into a new topic?

  7. Participate in Online Forums and Communities

  Engage in online communities related to your niche. Questions and discussions here can be a goldmine for blog topics.

  8. Use Blog Idea Generators

  Online tools like HubSpot’s Blog Ideas Generator can provide instant ideas when you’re feeling stuck.

  Conclusion

  Finding new blog ideas doesn’t have to be daunting. With these strategies, you can continually come up with fresh, engaging topics that keep your audience coming back for more. Remember, inspiration is everywhere—you just need to know where to look!

• Bricks Builder

  GeneratePress + GenerateBlocks vs Bricks: Which Stack is Better in 2026?

  ByEmily December 15, 2025

  If you’re building WordPress sites in 2026, you’ve probably heard the debate. Should you go with the GeneratePress theme plus […]

• 

  Bricks Builder

  Bricks Builder Fluid Typography Tutorial (With Settings You Can Copy)

  ByEmily December 15, 2025December 15, 2025

  Your site looks great on desktop. Then someone opens it on their phone and the text is either microscopic or […]

• 

  Bricks Builder

  Bricks Builder’s Native CSS Framework: Do You Still Need CoreFramework and ACSS?

  ByEmily December 15, 2025December 15, 2025

  Bricks Builder just changed the game with version 2.2. After years of developers relying on external CSS frameworks like CoreFramework […]

• 

  Blogging

  Never Run Out of Ideas: Top Tips for Generating Fresh Blog Topics

  ByEmily November 14, 2025

  Introduction One of the biggest challenges for bloggers is consistently coming up with new and interesting topics. This post will […]