105 道问答题，一道一卡105 questions, one card each

In one line: a block element takes the whole line and you can set its width and height; an inline element flows with the text and is sized by its content.

There are exactly three differences worth remembering:

• Line breaks — block elements break before and after (div, p, h1, ul); inline ones do not (span, a, strong, img).
• Width and height — settable on block elements, ignored on inline ones.
• Margin and padding — all four sides work on block elements; on inline elements vertical margin does nothing, and vertical padding overflows visually without pushing the line apart.

Follow-up: “What about inline-block?” — it is the compromise: no line break (like inline) but width, height and vertical margin all work (like block). Nav buttons use it constantly.

Also asked: “img is inline, so why can you set its size?” — because it is a replaced element: its content comes from an external resource, so the browser makes an exception. Same for input and video. Getting this one right scores points.

In one line: a click travels the DOM in three phases — down from window to the target (capture), fires on the target, then back up to window (bubble). Capture goes outside-in, bubbling goes inside-out.

The third argument to addEventListener picks the phase you listen in: false (the default) is bubbling, true (or { capture: true }) is capture.

Why is bubbling the default? Because what you almost always want to know is “what did the user click”, and inside-out is the natural direction for that — it is also what makes event delegation possible (see #289).

Follow-up: “How do you stop it?”

• e.stopPropagation() — stop travelling further up (or down).
• e.stopImmediatePropagation() — also skip other listeners on the same element.
• e.preventDefault() — cancels the default behaviour (link navigation, form submit) and has nothing to do with propagation. These two get mixed up most often; do not confuse them.

Also asked: “Which events do not bubble?” —focus, blur, load, mouseenter, mouseleave. When you need to delegate, use their bubbling counterparts: focusin / focusout / mouseover / mouseout.

In one line: meta carries information about the page — browsers, search engines and social platforms read it; users never see it.

Only four of them actually matter day to day:

• <meta charset="UTF-8"> — must be first in the head. Without it non-ASCII text turns to mojibake, because the browser has to know the encoding before it can parse the bytes that follow.
• viewport — the precondition for mobile. Without this line a phone browser pretends it is 980px wide and scales the whole page down, which throws away every responsive rule you wrote (see #274).
• description — the snippet in search results. It does not affect ranking, but it affects click-through.
• Open Graph (og:title, og:image) — the card shown when the link is shared into Slack, Twitter or a chat app.

Follow-up: “Does keywords still do anything?” — no. Google stopped reading it long ago because it was abused into keyword stuffing. Knowing this shows you are not reciting an old tutorial.

In one line: the tag name itself states the role of the content — header / nav / main /article / section / aside /footer — whereas div and span say nothing at all.

Do not answer “the code looks nicer”. Semantics buys you two things you can actually measure:

• Screen readers can navigate. A blind user can jump to the main content or list every heading — and those features depend on tag semantics. On a page of nothing but divs, a screen reader can only read from the top.
• Search engines know which part is the article. Content in main weighs more than content in aside.

Follow-up: “So how do you choose between section and div?” — the test is “does this block have its own heading?” If it does (you could give it an h2), use section. If it is a wrapper you added purely for layout, use div. A container that exists for styling should be a div — forcing it to be a section just pollutes the document outline.

The distinction in one line each:

• Accessibility (a11y) — can people with disabilities use it: vision, hearing, motor, cognitive.
• Usability — how smoothly can people who can use it, use it: can they find things, understand them, avoid mis-taps.
• Inclusion — how wide is the net: older users, slow connections, small screens, non-native speakers, someone operating one-handed while holding a child.

The three nest: accessibility is part of inclusion, and anything with poor usability is worse for everyone.

One example each — examples are what the interviewer wants:

• a11y: write alt on images; tie a label to its input with htmlFor; make sure Tab reaches every interactive element and do not delete the focus ring with outline: none.
• usability: label the button “Save draft” rather than “Submit”; put the validation error on the field that failed, not a generic banner at the top of the page.
• inclusion: at least 4.5:1 contrast for body text; never use colour as the only carrier of meaning (someone with red-green colour blindness cannot see that “red means wrong”, so add an icon or a word); make the first screen usable on 3G.

Follow-up: “How do you test it?” — walk the main flow with the keyboard only; run Lighthouse’s a11y audit in Chrome DevTools; scan with the axe extension. Naming the tools is more convincing than naming the concepts.