Designing your site to reflect your brand and vision is important. That's why Stacks includes a robust and flexible Style Editor, which gives you the tools to tailor your site's look and feel - with no code required. For those who want to go even further, CSS overrides provide you with an extra layer of control.
CSS overrides let you fine-tune your site's design, beyond what's possible with the Style Editor settings. While that flexibility is powerful, it also comes with important considerations; in this article, we'll explore these questions:
- What are CSS overrides?
- What are some common mistakes to avoid?
- What are best practices for writing stable, maintainable overrides?
What are CSS overrides?
CSS (Cascading Style Sheets) is the language used to define the colors, borders, fonts, spacing, and other styles used across your site. Most of this styling happens behind the scenes and is fully managed by Stacks, although many styles can be safely modified using the Stacks Style Editor.
The Style Editor is designed to handle the most common and important design needs. However, CSS overrides let you go the extra mile, especially when you need highly specific or unique styles. Basically, CSS overrides can empower you to make your Stacks site your own!
Toward the bottom of the Style Editor is the CSS override section, where you can add custom styles using standard CSS.
CSS example:
.custom-banner h2 {
font-size: 2rem;
text-transform: uppercase;
}
Common mistakes with CSS overrides
CSS overrides give you significant control of your site design, which means they should be added with care. Here are some of the most common mistakes we see.
1. Overuse of !important
It's tempting to add the !important declaration to force you styles to apply. Overuse of this makes your CSS overrides harder to debug, harder to update, and more likely to conflict with other styling rules.
In nearly all cases, you can avoid using !important by increasing the specificity of your selector. If you find yourself relying on !important to make your styles work, you may need to improve your familiarity with CSS before adding overrides.
2. Poor scoping or broad selectors
Writing broad rules could make changes to more content than expected. For example, the code snippet below would change the color of every h2 to red across your entire site.
h2 {color: red;}
This phenomenon is also common when elements share the same class name. To prevent your styles from leaking inadvertently, scope you CSS whenever possible with unique class names or content-specific containers, such as:
.custom-banner h2
3. Overly complex or deep selectors
While we just discussed that it's important to avoid broad selectors, which can cause styles to leak, on the flip side, selectors can also become overly deep or complex.
For instance, targeting highly specific DOM structures, like the snippet below, can make your CSS fragile.
.main .section > div > ul li span
If Stacks updates the underlying code structure, or if you rearrange block on the landing page, your styles may silently stop applying.
4. Adding code that hurts performance
CSS overrides are generally quick to render and are unlikely to cause a noticeable impact on your site's performance. However, there are some specific areas where performance may suffer due to overrides:
- Importing several custom fonts from third-party services
- Loading multiple conflicting style libraries
- Embedding very large animations or transitions on many elements
If you have added CSS overrides and your website seems unusually slow, it's worthwhile to review your overrides.
Best practices for CSS overrides
Here's how to get the most out of your custom CSS, without creating future headaches.
1. Use the Style Editor first
Before reaching for custom CSS, explore what's possible with the built-in Style Editor. It's designed to be update-safe and easy to use, and it helps keep your site maintainable.
If you have ideas on how to enhance the native capabilities of the Style Editor rather than adding CSS overrides, consider submitting your idea to the Stacks product team via our Feature Request Portal.
2. Keep overrides minimal
Avoid using CSS overrides whenever possible. Remember that your team is responsible for maintaining and debugging any CSS overrides that you add to your site. These customizations are not tested by the Stacks development team before releasing updates.
3. Scope you CSS carefully
Remember to 'scope' your CSS carefully, ensuring that styles only apply to the intended content, and that your selectors won't easily break if the underlying code structure behind Stacks changes over time.
That Stacks team makes efforts to avoid adding or removing existing classes and IDs, which can break CSS selectors. However, some changes are unavoidable, especially as we make accessibility updates to align with evolving laws and best practices.
Whenever possible, use the custom naming conventions to safely narrow your styling to specific components or sections. This prevents your styles from unintentionally leaking to other components of your site.
If you're editing content inside a WYSIWYG editor, like a custom block or description field, you can manually add a class by clicking the more items icon in the toolbar, then clicking Source Code. This lets you wrap content in your own HTML tags and CSS classes or IDs for more precise targeting.
4. Test on all screen sizes
Your CSS overrides should work across all screen sizes, not just on desktop. Stacks may apply different layouts depending on the screen size:
- Desktop: wider than 64em
- Tablet: between 40em and 64em
- Mobile: less than 40em
Use your browser's responsive design mode (or resize the browser window manually) to test how your overrides behave across breakpoints. If needed, apply media queries to fine-tune style for specific device sizes.
5. Test after updates
After each product update, review your site to ensure your custom styles still work as intended. If we've made changes to the underlying code structure, you may need to adjust your selectors accordingly.
Visit the Stacks 4.0 Status page to find information about planned maintainence.
6. Store a backup offline
We recommend you keep a backup of your CSS overrides outside of Stacks. This is helpful in case someone accidentally overwrites or removes your code, or if you want to revert to a previous version.
Final Thoughts
We're committed to giving you the flexibility to make your site your own through the Stacks Style Editor. By following best practices and using CSS overrides thoughtfully, you can enjoy the benefits of custominzing your design while minimizing the risks of unexpected issues.