Frontend Fundamentals: HTML, CSS, and Responsive Styling Questions

Definition: box-sizing controls how width/height are calculated. content-box (default) measures width/height of content only; padding and border add on. border-box includes padding and border within the specified width/height.
Why prefer border-box in a design system: predictable sizing—elements keep intended layout when padding/border change; easier to compose components and avoid layout shifts across browsers.
Example surprise with content-box:
A card styled as width:200px; padding:20px; border:2px solid. With content-box the rendered total width becomes 200 + 40 + 4 = 244px, which can break grid layouts and cause overflow. Using box-sizing: border-box keeps the visual width exactly 200px regardless of padding/border, simplifying responsive and nested components. Set: * { box-sizing: border-box; } in base styles for consistency.

Definition: Cumulative Layout Shift (CLS) measures unexpected layout shifts during page load or lifecycle that harm visual stability; it’s the sum of layout shift scores for unstable elements.

Three practical guidelines to minimize CLS:

1. Reserve space for media and embeds — Always include width/height attributes or CSS aspect-ratio for images/videos/iframes so the browser can allocate layout space before resources load.

2. Avoid inserting content above existing content — Load late-inserted banners, ads, or dynamic UI below existing flow or reserve space for them; use placeholders or skeletons to prevent sudden pushes.

3. Font & async content strategies — Use font-display: optional or swap to avoid FOIT causing reflow; preload critical fonts to reduce jumps. For late-loading web fonts, provide fallback metrics and avoid layout shifts when font metrics change.

Applying these reduces unexpected movement and improves perceived stability and Core Web Vitals scores.

Situation: Build color, spacing, typography tokens supporting light/dark and high-contrast. Token structure:

• Core primitives (semantic, neutral): color.primary.500, color.background.base, color.text.base, color.border.muted; spacing.0..8 (8px scale); type.family.base, type.scale.100..900, type.lineHeight.
• Mode overrides: themes.light.{color.}, themes.dark.{color.}, themes.highContrast.{color.*}.
  Mapping to CSS/design tools:
• Export as JSON and generate CSS variables: :root { --color-text-base: #111; } .theme-dark { --color-text-base: #eee; }
• In Figma use token plugin mapping same keys to styles.
  Accessibility checks:
• Contrast: automated WCAG AA/AAA checks per token pair (text/background) across theme variants.
• Dynamic checks: test components with tokens for focus/hover states, high-contrast OS modes, and color-blind simulations.
• Runtime asserts: warn when computed contrast falls below threshold, include unit tests in build pipeline. Reasoning: semantic tokens decouple design intent from raw values, themes override safely, and automated checks prevent regressions.

Common differences between iOS Safari and Android Chrome that affect touch/scroll UX:

• Scrolling inertia & bounce: iOS has stronger momentum and native overscroll bounce; Android typically has less bounce. Designers should avoid relying on snap behavior identical across platforms and test on both.

• Overscroll visual effects: iOS shows rubber-band overscroll; Android may show edge glow. Avoid visual elements pinned to viewport that appear to move unexpectedly during overscroll.

• position:fixed behavior: iOS historically treated fixed differently during virtual keyboard and scroll; Android may handle fixed more consistently. Use CSS sticky where appropriate and test keyboard interactions.

• Touch event handling & passive listeners: Chrome favors passive touch listeners preventing preventDefault for scroll unless non-passive. Ensure scroll-lock patterns use proper event options and avoid jank.

Design guidance: provide platform-aware prototypes, favor native scroll where possible, avoid custom scroll unless necessary, implement fallbacks, and test on low-end devices. Document keyboard/virtual-keyboard behavior and ensure controls remain accessible when keyboard opens.

A stacking context is an isolated three-dimensional layer in the rendering order; elements inside it are stacked relative to each other and can’t be layered above elements from other contexts unless that context's z-index is higher. New stacking contexts form from position + z-index, opacity <1, transform, filter, mix-blend-mode, etc. Example bug: a modal backdrop appears, but a child dropdown inside the page renders above the modal because that dropdown belongs to a different stacking context with higher z-index; or the modal has a transform and thus creates a stacking context causing its close button (positioned) to sit beneath other components. Fix by adjusting z-index on the modal’s stacking context or removing unintended transforms.