Frontend Fundamentals: HTML, CSS, and Responsive Styling Questions

Block elements (e.g., <div>, <p>) occupy full available width, start on a new line, and accept width/height. Inline elements (e.g., <span>, <a>) flow within a line, size to content, and ignore width/height. Inline-block blends both: sits inline but accepts width/height. Example 1: Navigation links — using inline makes items wrap awkwardly; inline-block lets you set equal width/height for hit areas without forcing line breaks. Example 2: Card grid — using block for cards stacks them vertically; inline-block or flex/grid enables horizontal rows. For product designers this matters because it affects alignment, spacing, accessibility of touch targets, and predictable responsive behavior.

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.

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.

Rendering strategies for thousands of rows:

1. Virtualization (client-side windowing): render only visible rows + buffer. Pros: smooth scrolling, low DOM size. Cons: complex keyboard/accessibility, measuring variable row heights, heavier client CPU for large data.

2. Pagination (client-side paging): show N rows per page with controls. Pros: simple, accessible, predictable performance. Cons: breaks continuous scrolling discoverability and may increase server requests.

3. Server-side paging & sorting: return pages sorted server-side. Pros: low client memory/CPU, consistent latency. Cons: more network round trips and UX complexity for multi-row selection across pages (requires selection state management).

UX trade-offs: virtualization gives best perceived performance but needs careful focus management, ARIA updates, and preservation of selection when rows unmount. Use virtualization for immersive browsing; provide keyboard support and announce visible range. For workflows requiring exact row counts and bulk selection across the dataset, prefer server paging with stable identifiers and a selection model that persists across pages (e.g., store selected IDs server-side or in app state). Hybrid approach: server-side paging with optional client-side caching and virtualized rendering of cached pages offers balance.

Framework: design for latency with optimistic updates, progressive save, and resilient error recovery.
Optimistic UI:

• Apply immediate local state changes and show in-progress indicator ("Saving...").
• Assign client-generated temporary IDs for new items; reconcile with server response.
• Rollback strategy: preserve previous state snapshot to revert if server fails.
  Progressive saving:
• Autosave on field blur or after debounce; chunk large payloads (save section-by-section).
• Use local persistence (IndexedDB) to queue changes when offline and sync when online.
  Error recovery & UX:
• Surface contextual errors inline with actions (field-level) and provide a summary at top for submission errors.
• Retry strategies: exponential backoff for transient failures; allow manual retry with clear CTA.
• Communicate confidently: toasts for success/failure, non-blocking warnings for degraded autosave, and clear guidance when rollback occurs.
  Design rationale: keeps user flow smooth, minimizes data loss, and makes failure transparent and recoverable.