默认只显示问题 —— 先自己在心里答一遍，再展开对答案。答不上来就标「不会」，下次抽认卡会先抽它。Only the question shows by default. Answer it in your head first, then open the answer. Mark the ones you miss; the flashcard round puts those first.
正在读这台浏览器里的标记…Reading your marks from this browser…
标记不是打分，是给下一轮排队Marks are a queue, not a score
标「不会」的题会排到抽认卡最前面，标「会」的进低频池排最后。所以别客气 —— 觉得答得磕磕巴巴就标「模糊」。准备好了就去抽认卡。“No idea” jumps to the front of the next round; “got it” drops to the back. So be honest — if it came out shaky, mark it shaky. Then go run a flashcard round.
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.
JavaScript三个阶段的完整顺序The full order of the three phases示意Illustrative
面试里画得出这个顺序，基本就过了。注意：现在的浏览器在目标元素上也是先执行捕获监听器、再执行非捕获监听器（旧规范才是按注册顺序），同一组内按注册顺序。If you can draw this order in an interview, that question is handled. One detail: modern browsers also run capture listeners first on the target itself, then the non-capture ones (registration order applied only under the old spec); within each group, registration order holds.
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.
Text实际会写的那几行The lines you would actually write示意Illustrative
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 real benefits:
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.
Machines can tell where the main content is. Search engines, reader mode and a screen reader’s skip-to-main all rely on tags such as main and article (do not claim that main ranks higher).
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.
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 for (htmlFor in JSX); 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.
99 道来自面试题库 #269–#387；TypeScript 深度那 6 道是 DrillLab 自出的（senior 补强，卡片上有标注）。答案都是 DrillLab 写的，所以讲解里的代码块一律标「示意」。每道题都能点回它出处的那一节课。99 questions come from the interview bank (#269–#387); the 6 TypeScript deep-dive ones are DrillLab-made (marked on the card). All answers are written by DrillLab, so every code block here is labelled “demo”. Each card links back to the lesson it came from.