Common framework conflicts

CSS frameworks ship rules that apply to your elements whether you asked for them or not. When your custom styles don’t appear as expected, it’s often because a framework rule is winning the cascade. Here’s how to identify and resolve these conflicts.

Understanding the specificity chain

Styles are applied in this order, from lowest to highest priority:

1. Browser default styles (user-agent stylesheet)
2. Framework base styles (e.g., Foundation’s normalize.css)
3. Framework component styles (e.g., .button { … })
4. Your custom class styles
5. Element-level overrides in the Style pane (higher specificity class chains)
6. Inline styles (highest — avoid these)

When a framework rule and your rule target the same property on the same element, the one with higher specificity wins. If specificity is equal, the rule that appears later in the stylesheet wins.

Identifying a conflict with the CSS pane

Site Designer’s CSS pane is your primary debugging tool for specificity conflicts. When you select an element:

• Properties shown with a strikethrough are being overridden by a higher-specificity rule.
• Hover over a struck-through property to see which rule is overriding it.
• The winning rule shows the selector that’s winning (e.g., .button.success from Foundation).

If you see your custom property struck through, you need to either increase your rule’s specificity or remove the conflicting framework rule from the element.

Foundation conflict example: button override

Scenario: You created a .cta class for your call-to-action button, but Foundation’s .button styles are overriding your custom background color.

What’s happening: Foundation’s .button selector has the same specificity as your .cta class. Since Foundation’s stylesheet loads before your custom CSS, you’d expect your rule to win. But Site Designer may be writing your rule with lower specificity, or Foundation’s rule has a longer selector chain.

Fix: Chain your class with the element selector to increase specificity:

/* Before — same specificity as Foundation's .button */
.cta { background-color: #e65c00; }

/* After — higher specificity because of the chained element selector */
a.cta { background-color: #e65c00; }

Or, even more reliably, chain two classes (which you control in Site Designer’s Style pane):

.btn.cta { background-color: #e65c00; }

Bootstrap conflict example: margin reset

Scenario: Bootstrap’s CSS normalize/reset is zeroing out margins on your <h2> elements and your custom margin-bottom isn’t applying.

What’s happening: Bootstrap’s base styles include * { box-sizing: border-box; } and a normalize layer that resets heading margins. Your custom margin rule has the same specificity but loads earlier.

Fix: Add your margin rule via a class with a more specific selector:

.content-section h2 { margin-bottom: 2rem; }

By scoping the rule to .content-section h2 instead of just h2, you beat Bootstrap’s element-level reset.

Using !important as a last resort

!important overrides all specificity calculations and makes the rule win unconditionally. It solves the immediate problem but creates a future maintenance problem: every subsequent override also needs !important, leading to an escalating arms race.

Use it only when:

• You are overriding a third-party framework you cannot modify.
• The override is narrow and well-documented with a comment.
• There is truly no specificity-based fix available.

/* Needed because Foundation's .button specificity beats our .cta */
.cta { background-color: #e65c00 !important; }

Preventing conflicts from the start

• Apply framework classes first and custom classes second in the Content pane’s class list. Later classes are more likely to override earlier ones when specificity is equal.
• Use custom class names that are clearly distinct from framework class names (avoid naming your class .button when Bootstrap or Foundation already use that name).
• Scope your custom styles inside a wrapper class (e.g., .site-header .nav-link { … }) to automatically beat generic framework selectors.