Styling resilience and conflict prevention¶

Guide type: Reference
Difficulty: Advanced
Applies to: SmartSize storefront CSS

SmartSize uses multiple defensive strategies to ensure the quiz and size chart popups render correctly regardless of the merchant's theme CSS, browser extensions, or user-agent styles. This reference explains those strategies so developers understand how to safely customize SmartSize without breaking its appearance.

CSS isolation strategies¶

Comprehensive CSS reset¶

SmartSize applies a scoped CSS reset inside the popup that normalizes all HTML elements, form controls, buttons, links, and images. This prevents the merchant theme's global styles from leaking into the popup.

Reset coverage:

• All HTML elements (box-sizing, margin, padding)
• Form elements (appearance, border, font-family)
• Buttons (background, border, cursor)
• Links (color, text-decoration)
• Images (max-width, display)

Explicit font-family declarations¶

Every styled component inside the popup declares its own font-family stack. SmartSize does not rely on inheriting fonts from the parent page.

font-family: Inter, system-ui, Avenir, Helvetica, Arial, sans-serif;

This prevents browser extensions or themes from injecting unexpected fonts into the quiz.

Explicit color declarations¶

All text, borders, and backgrounds use explicit color values. SmartSize does not rely on inherited colors from the theme.

Example: Unicode icons (such as the info icon ℹ) have explicit color: #000000 to prevent user-agent styles from changing their appearance.

Shadow DOM isolation¶

SmartSize renders the widget inside a Shadow DOM host. This provides natural style scoping: merchant theme CSS cannot directly target elements inside the Shadow DOM.

What the Shadow DOM protects against:

• Global CSS resets from the theme
• Theme-specific font overrides
• Color scheme changes (dark mode plugins)
• Layout-altering rules (* { box-sizing: border-box })

Limitations:

• Aggressive global rules using !important can still pierce the Shadow DOM in some browsers
• CSS custom properties (variables) defined on :root are accessible inside the Shadow DOM
• Some browser extensions inject styles at the document level that affect everything

styled-components resilience¶

SmartSize uses styled-components for CSS-in-JS. A specific production-build issue has been addressed to prevent conditional styles from being evaluated incorrectly.

Conditional prop evaluation pattern¶

Problem: Complex conditional logic inside styled-components template literals can fail in production builds when styled-components "speedy mode" is enabled. This causes components to apply wrong styles — for example, a variant="secondary" button might render with primary button styles.

Required pattern: Extract conditional logic into helper functions outside of template literals, and use !important declarations to prevent CSS conflicts.

// ❌ AVOID: Complex conditionals in template literals
const Button = styled.button<{ variant?: 'primary' | 'secondary' }>`
  ${props => props.variant === 'primary' ? `
    background: ${props.accentColor};
    color: white;
  ` : `
    background: transparent;
    color: #666;
  `}
`;

// ✅ REQUIRED: Extract to helper functions
const getButtonStyles = (props: { variant?: 'primary' | 'secondary'; accentColor?: string }) => {
  const isPrimary = props.variant === 'primary';

  if (isPrimary) {
    return `
      background: ${props.accentColor || '#1a1a1a'} !important;
      color: white !important;
    `;
  }

  return `
    background: transparent !important;
    color: #666 !important;
  `;
};

const Button = styled.button<{ variant?: 'primary' | 'secondary' }>`
  ${props => getButtonStyles(props)}
`;

When to apply this pattern:

• Any styled-component with variant-based conditional styling
• Multi-line template literal conditionals with nested prop evaluations
• Components that behave differently in development vs production
• Conditional logic that depends on multiple props simultaneously

Specificity and !important policy¶

SmartSize uses !important declarations strategically to defend against merchant theme overrides. The policy is:

Use !important for:

• Critical layout properties (position: fixed on overlay)
• Styles that must not be overridden by themes (font-family inside popup)
• Conditional styles extracted to helper functions (production safety)

Avoid !important for:

• Decorative styles that developers should be able to override
• Colors and spacing that you want merchants to customize via CSS
• Properties that are already protected by the Shadow DOM

z-index management¶

SmartSize uses a controlled z-index stack to ensure the modal overlay and content appear above the merchant's page:

If your theme uses high z-index values (above 10000), the SmartSize modal may appear underneath. Contact SmartSize support if you encounter this issue.

Testing recommendations¶

To verify the styling resilience works correctly on your store:

1. Test with browser extensions — Install popular extensions that modify page styles (dark mode, ad blockers, font changers).
2. Test with different browsers — Chrome, Firefox, Safari, Edge.
3. Test with aggressive CSS themes — Themes that use * { margin: 0; padding: 0 } or !important heavily.
4. Test with custom user styles — Browser dev tools "Override styles" feature.
5. Test with high-contrast mode — Ensure accessibility is maintained.

Future considerations¶

Impact¶

These strategies ensure that:

• The popup maintains consistent appearance across different environments
• Unicode icons display correctly regardless of user-agent styles
• Font rendering is consistent and predictable
• The app is robust against external style interference
• Accessibility is maintained across different browser configurations

Related articles¶

• CSS customization reference — Complete class list for safe overrides
• SmartSize app embeds for custom themes — Theme integration reference