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
!importantcan still pierce the Shadow DOM in some browsersCSS custom properties (variables) defined on
:rootare accessible inside the Shadow DOMSome 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: fixedon 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:
Element | z-index | Notes |
Modal overlay | 9999 |
|
Modal content | 10000 | Above the overlay |
Close button | 10001 | Above content for accessibility |
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:
Test with browser extensions — Install popular extensions that modify page styles (dark mode, ad blockers, font changers).
Test with different browsers — Chrome, Firefox, Safari, Edge.
Test with aggressive CSS themes — Themes that use
* { margin: 0; padding: 0 }or!importantheavily.Test with custom user styles — Browser dev tools "Override styles" feature.
Test with high-contrast mode — Ensure accessibility is maintained.
Future considerations
Approach | When to consider |
CSS-in-JS isolation | If external interference becomes a major issue |
Shadow DOM enhancements | For maximum style isolation (some trade-offs with event handling) |
CSS custom properties | For better theme management and merchant customization |
Regular audits | Periodically review for new styling vulnerabilities |
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
