Frontend Fundamentals: HTML, CSS, and Responsive Styling Questions

Trade-offs:

• Performance: webfonts add bytes and can cause FOIT/ FOUT; slow networks amplify delay.
• UX: invisible or sudden font swaps harm readability and layout.
• Licensing: fonts may have restrictive EULAs, require proper hosting or subsetting.
  Mitigations:
• Subset fonts to needed glyphs and weights; deliver WOFF2 and use variable fonts where appropriate.
• Loading strategy: preload critical fonts, use font-display: swap or optional depending on importance; consider FOIT for hero text only.
• Metric matching: choose system fallback with similar metrics and use CSS adjustments (font-size-adjust, letter-spacing) to reduce layout shift.
• Caching & CDN: host fonts on CDN with long TTL and proper CORS headers.
• Accessibility: test reading flow; support prefers-reduced-motion and system fonts when necessary.
  Trade-off rationale: balance brand fidelity with performance by prioritizing only critical brand glyphs/weights and graceful fallbacks.

Checklist for interactive components (buttons, inputs, dialogs):

1. Keyboard focus order & visible focus styles — Ensure logical tab order and clear focus indicator (not removed). Important so keyboard-only users can navigate and know current focus.

2. ARIA roles & attributes — Use role="button"/role="dialog", aria-expanded, aria-controls, aria-labelledby. Provides semantic meaning to assistive tech.

3. Contrast & hit target size — Text/icon contrast >=4.5:1, interactive targets >=44x44px. Improves readability and tap accuracy for low vision and motor-impaired users.

4. Labeling & instructions — Provide visible labels and aria-label/aria-describedby for extra context (errors, helper text). Prevents ambiguity for screen reader users.

5. Announcements for dynamic changes — Use aria-live or role=alert for status updates and opened/closed dialogs. Ensures assistive tech users receive state changes.

6. Focus management for dialogs & menus — Trap focus when open, return focus to triggering control on close. Prevents focus loss and disorientation.

7. Avoid relying on color/hover — Don’t use color alone to convey state; provide text or icon indicators and ensure hover-only interactions have keyboard alternatives.

8. Motion preferences — Respect prefers-reduced-motion: reduce/disable non-essential animations to avoid vestibular issues.

Each item maps directly to common accessibility failures and should be included in the design spec with examples and acceptance criteria.

Key artifacts to include:

• Responsive spec doc: breakpoints, behavior rules, and visual examples per breakpoint (small/medium/large).
• Token mapping: spacing, type, and color tokens used by component.
• Detailed anatomy: labeled parts (image, title, body, actions) with min/max dimensions, aspect-ratio rules, and cropping strategy.
• Interaction states: hover, focus, disabled, loading with CSS class names and visual examples.
• Accessibility notes: role, aria attributes, focus order, keyboard behavior.
• Edge cases: missing image, long title, no actions, RTL, very narrow/very wide containers with screenshots and expected fallback.
• Implementation snippets: HTML structure and sample CSS variables usage, and integration notes for image srcset and lazy-loading.
• Tests & acceptance: visual regression screenshots, pixel tolerances, performance budget.
  Rationale: these artifacts give developers concrete, testable rules and reduce ambiguity during handoff.

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.

FLIP = First, Last, Invert, Play. It avoids layout thrashing by animating only transforms.

How to apply to reorder list items:

1. First: record each element's current bounding rect (getBoundingClientRect) before DOM change.
2. Last: apply the DOM reorder (e.g., move nodes) and record new bounding rects.
3. Invert: compute delta for each item: dx = first.left - last.left; dy = first.top - last.top; apply transform: translate(dx,dy) to visually place item back where it started.
4. Play: remove transform over a transition to translate(0,0) so the browser animates the item to its new position using transform (GPU-composite only).

Why it improves performance: transforms are composited and avoid layout/paint of other elements; the browser can run them on the compositor thread at 60 FPS. FLIP minimizes reflow and expensive paints, resulting in smooth reordering animations even with many elements. Use requestAnimationFrame to batch reads/writes and cancel layout thrashing.