Deck 13 - HTML/CSS/Responsive/DOM Basics (Reviewer Essentials)

Question 1

Deck 13 - HTML/CSS/Responsive/DOM Basics (Reviewer Essentials) (objective)

Answer 1

Goal: review UI code like a senior: semantic HTML, forms, layout, responsive patterns, DOM/events, and common browser pitfalls.
You learn: what/why (under the hood), common mistakes, and review-grade wording.
Output style: PASS/PARTIAL/FAIL + 2-3 issues + fix approach.

Question 2

Semantics: why choose <button> vs <div onClick>?</button>

Answer 2

button has built-in keyboard support, focus management, and correct ARIA role.
div onClick requires manual keyboard handlers, tabindex, and ARIA; often fails accessibility and behavior parity.

Question 3

Semantics: link vs button rule.

Answer 3

Use <a> for navigation (changes URL / goes to another resource).
Use <button> for actions (mutations, toggles, submitting forms).</button></a>

Question 4

Forms: why button type matters.

Answer 4

Inside a form, <button> defaults to type=’submit’.
Best practice: set type=’button’ for non-submit buttons to avoid accidental submissions.</button>

Question 5

Forms: label association (best practice).

Answer 5

Every input needs an accessible name: <label> or wrapping label, or aria-label/aria-labelledby.
Why: screen readers and click targets; also improves usability.</label>

Question 6

Forms: placeholder is not a label (why).

Answer 6

Placeholder disappears on input and is not a reliable accessible name.
It also has low contrast by default; use a proper label.

Question 7

Forms: controlled vs uncontrolled basics.

Answer 7

Controlled inputs rerender on each change; easier validation.
Uncontrolled use defaultValue/ref and read on submit; can be faster for huge forms.

Question 8

Forms: autocomplete best practice.

Answer 8

Use autocomplete hints like email, name, current-password.
Why: improves UX and reduces errors; helps password managers.

Question 9

HTML: headings hierarchy rule.

Answer 9

Use a logical heading order (h1 then h2, etc.)
Why: screen reader navigation, SEO, and structure.

Question 10

HTML: list semantics rule.

Answer 10

Use <ul>/<ol> for lists; not a series of <div> elements.
Why: semantics, accessibility, and consistent spacing behavior.

Question 11

Images: alt text rule.

Answer 11

Decorative images: alt=’’. Informative images: meaningful alt.
Why: screen readers; missing alt can be noisy or unhelpful.

Question 12

Images: width/height attributes (why).

Answer 12

Providing intrinsic dimensions reduces layout shift.
Why: avoids CLS-like jank as images load.

Question 13

CSS: box model basics (under the hood).

Answer 13

Elements have content + padding + border + margin.
box-sizing: border-box makes width/height include padding/border, reducing layout surprises.

Question 14

CSS: specificity basics.

Answer 14

More specific selectors win; !important overrides most.
Best practice: avoid deep specificity wars; use consistent class-based styling.

Question 15

Layout: flex vs grid rule of thumb.

Answer 15

Flex: 1D layout (row OR column). Grid: 2D layout (rows and columns).
Pick based on whether you need alignment in both axes.

Question 16

Responsive: mobile-first principle.

Answer 16

Start with base styles for small screens, then add min-width breakpoints.
Why: fewer overrides; better defaults for narrow devices.

Question 17

Responsive: common breakpoints (practical).

Answer 17

No single standard, but common: 480, 768, 1024, 1280.
Best practice: use content-based breakpoints rather than device-based.

Question 18

Responsive: avoid fixed widths (rule).

Answer 18

Prefer max-width, flex, grid, and fluid units.
Why: fixed widths break on small screens and cause overflow.

Question 19

Units: rem/em/vw/vh (quick).

Answer 19

rem: root font size; em: relative to parent; vw/vh: viewport.
Best practice: use rem for typography and spacing; use vw/vh carefully (mobile address bar quirks).

Question 20

Overflow: why text truncation needs more than one rule.

Answer 20

Truncation requires overflow hidden + text-overflow ellipsis + white-space nowrap (single line).
For multi-line, use line-clamp patterns with fallbacks.

Question 21

DOM: event bubbling vs capturing (why you care).

Answer 21

Events bubble from target up; capturing goes down.
Why: delegation and unexpected parent handlers firing; stopPropagation is sometimes needed (sparingly).

Question 22

DOM: default actions (example).

Answer 22

Links navigate; forms submit; space/enter activate buttons.
If you preventDefault, ensure you still provide expected behavior.

Question 23

DOM: focus management basics.

Answer 23

Focusable elements (button, input, link) participate in tab order.
Avoid tabindex>0; use tabindex=0 only when you must make custom elements focusable.

Question 24

DOM: why :focus-visible is preferred.

Answer 24

Shows focus ring for keyboard users without always showing it for mouse clicks.
Best practice: do not remove focus outlines; style them intentionally.

Question 25

DOM: scroll locking pitfalls.

Answer 25

Locking body scroll can cause layout shift and iOS issues. Best practice: account for scrollbar width; test mobile Safari.

Question 26

DOM: passive event listeners (why).

Answer 26

Passive listeners cannot call preventDefault; improves scroll performance. Use for touch/wheel when you do not need to cancel scrolling.

Question 27

DOM: resize observers vs window resize.

Answer 27

ResizeObserver tracks element size changes; window resize tracks viewport only. Use ResizeObserver for component layout measurement.

Question 28

DOM: measuring layout causes reflow (why).

Answer 28

Reading layout (getBoundingClientRect) can force layout. Batch reads/writes and avoid in hot paths; use requestAnimationFrame if needed.

Question 29

DOM: innerHTML risk (quick).

Answer 29

Setting innerHTML can introduce XSS if content is untrusted. Prefer textContent or safe rendering methods.

Question 30

DOM: dataset and attributes.

Answer 30

data-* attributes are strings; parse as needed. Avoid relying on DOM attributes for security-critical decisions.

Question 31

Browser: CSS sticky common pitfall.

Answer 31

position: sticky requires a scrolling container and proper top/bottom. Overflow hidden/auto on ancestor can break sticky behavior.

Question 32

Browser: 100vh mobile quirk.

Answer 32

Mobile browser UI changes viewport height; 100vh can be too tall. Use dynamic viewport units (svh/lvh/dvh) or JS workaround if necessary.

Question 33

Browser: image rendering and object-fit.

Answer 33

object-fit: cover preserves aspect while filling box. Why: avoid stretched images; good for avatars/thumbnails.

Question 34

Browser: font loading and FOIT/FOUT (concept).

Answer 34

Fonts can load late causing flash of invisible/un-styled text. Best practice: use font-display: swap and limit font variants.

Question 35

Browser: why heavy box-shadows are expensive.

Answer 35

Shadows can increase paint cost. Best practice: use sparingly and avoid animating expensive paint properties.

Question 36

Performance: which CSS properties are cheap to animate.

Answer 36

Prefer transform and opacity. Avoid animating layout properties (top/left/width) which trigger layout/reflow.

Question 37

Responsive images: srcset/sizes basics.

Answer 37

Let browser choose best image for device size/resolution. Why: faster loads and less bandwidth.

Question 38

Accessibility: reduced motion preference.

Answer 38

Respect prefers-reduced-motion to reduce or disable animations. Why: prevents motion sickness; improves accessibility.

Question 39

Accessibility: color contrast basics.

Answer 39

Low contrast hurts readability. Best practice: ensure sufficient contrast for text and interactive elements.

Question 40

UI state: disabled vs aria-disabled.

Answer 40

disabled attribute prevents focus/click for form controls. aria-disabled is for non-native controls; must still prevent activation in JS.

Question 41

Gotcha: clickable div without keyboard support. ```

Open

```

Answer 41

FAIL - Non-semantic interactive element. Use or add role='button', tabIndex=0, and key handlers (Enter/Space) - but prefer button.

Question 42

Gotcha: button inside form submits unexpectedly. ```

Reset

```

Answer 42

FAIL - button defaults to submit in forms. Add type='button' for non-submit actions.

Question 43

Gotcha: input missing label. ``` ```

Answer 43

FAIL - Placeholder is not a label. Add or aria-label/aria-labelledby.

Question 44

Gotcha: fixed width causes overflow on mobile. ``` .card { width: 900px; } ```

Answer 44

FAIL - Breaks responsiveness. Use max-width: 100%; width: min(900px, 100%); or fluid layout.

Question 45

Gotcha: using px for font sizes everywhere.

Answer 45

PARTIAL - px can be okay, but rem is more scalable for user settings. Prefer rem for typography and spacing.

Question 46

Gotcha: missing box-sizing reset.

Answer 46

PARTIAL - Without border-box, padding/border can create unexpected overflow. Consider a global box-sizing: border-box reset.

Question 47

Gotcha: truncation missing required rules. ``` .name { text-overflow: ellipsis; } ```

Answer 47

FAIL - Needs overflow hidden + white-space nowrap (single line). Add required properties or use line-clamp for multi-line.

Question 48

Gotcha: 100vh on mobile. ``` .hero { height: 100vh; } ```

Answer 48

PARTIAL - Mobile viewport changes can cause jump. Prefer 100dvh/svh or other responsive approach.

Question 49

Gotcha: removing focus outline. ``` button:focus { outline: none; } ```

Answer 49

FAIL - Accessibility regression. Keep focus ring; style with :focus-visible instead.

Question 50

Gotcha: using tabindex=0 everywhere. ```

...

```

Answer 50

PARTIAL - Adds focus stops and can harm keyboard UX. Use native focusable elements when possible.

Question 51

Gotcha: image missing alt. ``` ```

Answer 51

FAIL - Missing alt. Use alt='' if decorative, or meaningful alt if informative.

Question 52

Gotcha: using h1 multiple times for styling.

Answer 52

PARTIAL - One h1 per page is a common convention; use semantic headings for structure and style with CSS instead.

Question 53

Gotcha: list rendered as divs. ``` {items.map(x =>

{x}

)} ```

Answer 53

PARTIAL - Use

• for list semantics unless there is a strong reason not to.

Question 54

Gotcha: link used as button. ``` Delete ```

Answer 54

FAIL - Use for actions. If navigation, use href. Also missing keyboard/role semantics.

Question 55

Gotcha: button used as link. ``` location.href='/settings'}>Settings ```

Answer 55

PARTIAL - Prefer or router Link for navigation to keep semantics and accessibility.

Question 56

Gotcha: nesting interactive elements. ``` Go ```

Answer 56

FAIL - Invalid/buggy interaction. Avoid nested interactive elements; use a single correct element.

Question 57

Gotcha: missing rel on target blank. ``` Open ```

Answer 57

PARTIAL - Add rel='noopener noreferrer' to prevent reverse tabnabbing.

Question 58

Gotcha: excessive specificity. ``` body .app .page .card .title { ... } ```

Answer 58

PARTIAL - Hard to override and maintain. Prefer simple class selectors and a consistent layering strategy.

Question 59

Gotcha: animating layout properties. ``` .box { transition: width 200ms; } ```

Answer 59

PARTIAL - Animating width triggers layout. Prefer transform-based animations when possible.

Question 60

Gotcha: overflow hidden breaks sticky. ``` .container { overflow: hidden; } .header { position: sticky; top: 0; } ```

Answer 60

PARTIAL - Sticky may fail due to overflow on ancestor. Adjust container overflow/structure.

Question 61

Gotcha: using role incorrectly. ```

Open

```

Answer 61

PARTIAL - If you use role=button, you still need tabIndex=0 and keyboard handlers. Prefer .

Question 62

Gotcha: missing aria-live for async errors (when appropriate).

Answer 62

PARTIAL - For dynamic error messages, consider role='alert' or aria-live so screen readers announce changes.

Question 63

Gotcha: using vw for font sizes.

Answer 63

PARTIAL - vw-based fonts can get too small/large. Use clamp() with rem to keep within sensible bounds.

Question 64

Gotcha: no responsive meta tag (site-level).

Answer 64

FAIL - Without mobile scaling is broken. Ensure it exists in HTML template.

Question 65

Gotcha: inconsistent tap targets on mobile.

Answer 65

PARTIAL - Small tap targets reduce usability. Increase padding and hit area for interactive controls.

Question 66

Checklist: HTML/CSS review top 10.

Answer 66

1) Semantics (button/link/heading/list) 2) Labels and accessible names 3) Focus styles (:focus-visible) 4) Form button types 5) Responsive layout (no fixed widths) 6) Text overflow/truncation 7) Images (alt, sizing) 8) Cheap animations (transform/opacity) 9) Mobile viewport quirks (vh) 10) Avoid nested interactive elements

Question 67

Mini-drill: write a verdict. ```

Save

```

Answer 67

FAIL - Non-semantic interactive element. Use for correct keyboard/accessibility behavior.

Question 68

Mini-drill: write a verdict. ```

Cancel

```

Answer 68

FAIL - Defaults to submit. Add type='button' for Cancel, and keep submit explicit.

Question 69

Mini-drill: write a verdict. ``` ```

Answer 69

FAIL - Missing label. Add Email or aria-label.

Question 70

Mini-drill: fix approach for layout overflow.

Answer 70

Replace fixed widths with fluid constraints (max-width:100%, flex/grid). Ensure container allows wrapping and uses gap rather than hard-coded spacing.

Question 71

Mini-drill: explain why focus outline removal is bad.

Answer 71

It removes keyboard navigation feedback and is an accessibility regression. Use :focus-visible to style focus rings rather than removing them.

Question 72

Mini-drill: when to use aria-disabled.

Answer 72

When using a non-native element as a control. But you must still prevent activation in JS and manage focus/keyboard. Prefer native disabled whenever possible.

Question 73

Mini-drill: one-liner on why semantic HTML matters.

Answer 73

Semantics provide built-in accessibility, keyboard behavior, and consistent interaction without custom JS.

Question 74

Mini-drill: verdict on nested interactive elements. ``` Go ```

Answer 74

FAIL - Nested interactive controls are invalid and can break focus/click behavior. Use a single element with correct semantics.

Question 75

Mini-drill: verdict on missing alt. ``` ```

Answer 75

FAIL - Missing alt. Use alt='' if decorative or meaningful alt if it conveys information.

Question 76

Mini-drill: explain truncation recipe.

Answer 76

Single-line: overflow:hidden; text-overflow:ellipsis; white-space:nowrap. Multi-line: -webkit-line-clamp with display:-webkit-box and fallbacks.

Question 77

Mini-drill: explain cheap vs expensive animations.

Answer 77

Transform/opacity are cheap (composite). Layout properties (width/top/left) trigger layout + paint and are more expensive.

Question 78

Mini-drill: mobile vh fix (high level).

Answer 78

Prefer dvh/svh units (100dvh) for full-height sections or compute height with JS if needed. Test iOS Safari.

Question 79

Mini-drill: reviewer wording for responsive bug.

Answer 79

FAIL - Fixed dimensions prevent the layout from adapting on small screens; switch to fluid sizing (max-width, flex/grid) and add breakpoints based on content.

Question 80

Mini-drill: reviewer wording for missing label.

Answer 80

FAIL - Input lacks an accessible name. Add a visible label linked via htmlFor/id (preferred) or aria-label if a visible label is not possible.