Browsers have a third rendering mode between standards and quirks — what is almost-standards (limited-quirks) mode, what triggers it, and what does it change?
answer
- three modes, not two
- transitional doctypes, not strict ones
- one rule only, about line boxes
- the pixel gap under an image
- compatMode cannot tell it apart
basics
~20 sAlmost-standards mode, called limited-quirks mode in the HTML standard, is triggered by transitional legacy doctypes such as XHTML 1.0 Transitional. It matches standards mode except for one rule: a line box containing only images is sized to the images, removing the descender gap under an inline image.
solid answer
~50 sThe HTML standard defines three modes, not two: no-quirks, limited-quirks and quirks. Limited-quirks — everyone calls it almost-standards mode — is what you get from certain transitional legacy doctypes, notably `XHTML 1.0 Transitional` and `HTML 4.01 Transitional` when the doctype includes its system identifier URL. It behaves like standards mode in every respect but one: the sizing of line boxes that contain no text. In standards mode a line box always reserves room for the text that could sit next to an inline image, which is where the classic few-pixel gap under an `<img>` comes from; in almost-standards mode a line box holding only images is sized to the tallest of them and the gap disappears. That single carve-out existed because sliced-image table layouts of the era broke without it. `document.compatMode` reports `"CSS1Compat"` for this mode, exactly as it does for standards.
go deeper
Simply knowing a third mode exists, and that it comes from old transitional doctypes rather than from modern markup, is enough here. You will not meet it in new work.
Name the mode, name what triggers it, and describe its single difference — the height of a line box containing only images — plus why that mattered for sliced-image layouts.
Recognise it as a migration hazard: switching an inherited transitional doctype to the modern one introduces descender gaps under images, and no DOM property distinguishes this mode from standards mode, so detection has to go through the doctype string.
Treat it as a case study in shipping a compatibility carve-out: one narrowly scoped exception, permanent, so that a class of existing pages survived a standards transition. Be ready to weigh that pattern against a clean break.
## Three modes, not two Most people describe the doctype switch as binary — standards or quirks. The HTML standard actually defines three document modes: - **no-quirks** — standards mode. - **limited-quirks** — almost-standards mode. - **quirks** — the full legacy rule set. Limited-quirks exists because the transition to standards mode in the early 2000s broke a specific, extremely common layout pattern, and browsers needed a halfway house for pages that declared a *transitional* doctype: authors who were moving toward standards but were not there yet. ## What triggers it The trigger is the doctype's public identifier. The transitional legacy doctypes land here: ```html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ``` The `XHTML 1.0 Frameset` doctype does the same. `HTML 4.01 Transitional` and `HTML 4.01 Frameset` are conditional: with the system identifier (the trailing DTD URL) present they give limited-quirks; with the URL omitted they drop all the way to quirks mode. That subtlety is why two doctypes that look almost identical can render a page differently — a genuinely nasty bug on legacy sites. The strict doctypes (`HTML 4.01 Strict`, `XHTML 1.0 Strict`) and, of course, `<!DOCTYPE html>` all give plain standards mode. ## The one behavioural difference Almost-standards mode differs from standards mode in exactly one thing: how tall a line box is when it contains no text. An `<img>` is inline-level, so it sits on the text baseline. In standards mode the line box also accounts for the *strut* — the invisible box representing the line's font metrics — which reserves descender space below the baseline. An image dropped into a container therefore leaves a few pixels of space beneath it: ```html <div style="border: 1px solid; display: inline-block"> <img src="tile.png" alt="" width="80" height="40"> </div> <!-- standards mode: visible gap between image bottom and the border --> ``` In almost-standards mode, a line box with no text in it is sized to its tallest inline-level box, so the strut contributes nothing and the gap vanishes. That is the whole difference. ## Why it mattered The web of that era built layouts by slicing a design into images and reassembling them in table cells. Every stray pixel of descender space under an image pushed the slices apart and showed a hairline seam through the artwork. Switching such a page to full standards mode visibly shattered it. Limited-quirks gave those pages modern CSS behaviour — the correct box model, correct percentage resolution — while keeping the one rule their layouts depended on. ## How to detect it This is where the mode is awkward: `document.compatMode` has only two values, `"BackCompat"` and `"CSS1Compat"`, and limited-quirks reports `"CSS1Compat"` just like standards mode. There is no standard DOM API that distinguishes almost-standards from standards, so the practical test is to read the doctype string (`document.doctype.publicId` gives you the public identifier) and recognise a transitional one — or simply to observe whether the image gap is present. ## What you should do about it today Nothing, in new work: write `<!DOCTYPE html>` and you never see this mode. It matters for two situations. First, inherited codebases — a page carrying an XHTML 1.0 Transitional doctype is in almost-standards mode right now, and modernising the doctype will introduce descender gaps under images that were previously flush. Second, interviews, where it functions as a depth probe: knowing there are three modes, and that the third one exists for one narrow reason, signals you have read the actual specification rather than a blog summary. If you do modernise such a page and gaps appear, the fix belongs in CSS — change how the images participate in line layout — not in reverting the doctype.
- How can you tell almost-standards mode from standards mode at runtime?Not from `document.compatMode` — it returns `"CSS1Compat"` for both, distinguishing only quirks mode from everything else. The practical route is to inspect the doctype itself: `document.doctype.publicId` gives the public identifier, and a transitional XHTML 1.0 or HTML 4.01 one means limited-quirks. Otherwise you detect it behaviourally, by whether an image alone in a container leaves descender space beneath it.
- Why does the HTML 4.01 Transitional doctype sometimes give almost-standards mode and sometimes quirks mode?Because the switch also inspects the system identifier — the DTD URL after the public identifier. HTML 4.01 Transitional and Frameset doctypes give limited-quirks when that URL is present and drop to full quirks mode when it is omitted. It was a rough proxy for author intent: someone who copied the complete doctype was assumed to be more standards-aware than someone who typed half of it.
- A legacy page moves from an XHTML 1.0 Transitional doctype to <!DOCTYPE html> and thin gaps appear under its images. Why?The page left almost-standards mode for standards mode, so line boxes now reserve descender space below the baseline even when they contain only an image. The gap is correct inline-layout behaviour, not a regression in the markup. Fix it in CSS by changing how the image participates in line layout rather than by restoring the old doctype.
saying these in an interview costs you the question
- Says there are only two rendering modes
- Claims document.compatMode reports three distinct values
- Thinks almost-standards mode has its own box model
- Believes any legacy doctype means quirks mode