WEB / WEB-10.02

From HTML to DOM,layout and paint

Follow ordinary source text through DOM,styles,geometry and frame artifacts.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Visible note

Authored source
Ordinary HTML/CSS text is ready; parser output and box measurements are not yet available.
HTML + CSS source
Atlas & Web
DOM + CSSOM
DOM: absent
Layout + draw input
Boxes: absent
Frame presentation
Frame: absent
DOM constructed
The parser converts the character reference to text; the hidden node remains in the Document.
HTML + CSS source
Source retained
DOM + CSSOM
note: Atlas & Web; hidden present
Layout + draw input
Boxes: pending
Frame presentation
Frame: absent
Styles resolved
Selected note style is block; computed color is a separate record from authored source.
HTML + CSS source
Source retained
DOM + CSSOM
DOM + selected CSSOM rules
Layout + draw input
note: block; layout pending
Frame presentation
Frame: absent
Geometry available
The fixed border box is observed as120×24 CSS pixels; this measurement is not a paint capture.
HTML + CSS source
Source retained
DOM + CSSOM
note text unchanged
Layout + draw input
note box:120×24 CSS px
Frame presentation
Frame: absent
Painting dependency
Layout information can feed drawing; display-list bytes are not captured in this model.
HTML + CSS source
Source retained
DOM + CSSOM
DOM unchanged
Layout + draw input
Draw input selected; no capture
Frame presentation
Frame: pending
Frame boundary
Frame presentation is separate work; the model does not claim real pixels or GPU output.
HTML + CSS source
Source retained
DOM + CSSOM
DOM unchanged
Layout + draw input
Geometry retained
Frame presentation
Frame candidate; pixels unmeasured

Hidden vs reserved

Normal source
Hidden and reserved nodes exist in the source; neither represents a server access decision.
HTML + CSS source
hidden + reserved source
DOM + CSSOM
DOM: absent
Layout + draw input
Boxes: absent
Frame presentation
Frame: absent
Both nodes retained
Parsing creates both nodes; a CSS display decision does not delete their DOM identity.
HTML + CSS source
Source retained
DOM + CSSOM
hidden + reserved nodes present
Layout + draw input
Styles pending
Frame presentation
Frame: absent
Different visibility rules
Hidden uses display:none while reserved uses visibility:hidden; the effects differ.
HTML + CSS source
Source retained
DOM + CSSOM
Nodes present; styles resolved
Layout + draw input
hidden:none; reserved:hidden
Frame presentation
Frame: absent
Different box observations
Hidden has a0×0 rectangle while reserved retains80×12; a box does not mean visible text.
HTML + CSS source
Source retained
DOM + CSSOM
Nodes still present
Layout + draw input
hidden:0×0; reserved:80×12
Frame presentation
Visible text from these nodes: none
Boundary retained
Nonvisible data may remain in the Document; client styling does not undo delivered data.
HTML + CSS source
Source retained
DOM + CSSOM
Data present in DOM
Layout + draw input
Reserved space remains
Frame presentation
Pixels not captured

DOM text update

Source retained
Source contains Atlas & Web; ordinary parsing yields text Atlas & Web.
HTML + CSS source
Atlas & Web
DOM + CSSOM
note: Atlas & Web
Layout + draw input
note:120×24
Frame presentation
Frame: not captured
Text API selected
New plain text is selected for a local textContent update without creating a network request.
HTML + CSS source
Source unchanged
DOM + CSSOM
Pending: Atlas — revised
Layout + draw input
Geometry not yet reobserved
Frame presentation
Frame: not captured
Current DOM changed
The note current text becomes revised while the server file and original response remain unchanged.
HTML + CSS source
Source unchanged
DOM + CSSOM
note: Atlas — revised
Layout + draw input
Style dimensions unchanged
Frame presentation
Frame: pending
Geometry reread
The fixed120×24 box can be observed again; text mutation does not measure presentation timing.
HTML + CSS source
Source unchanged
DOM + CSSOM
Current DOM revised
Layout + draw input
note:120×24 CSS px
Frame presentation
Pixels still unmeasured
Separate persistence gate
The client text update is complete; this branch contains no save request or database commit.
HTML + CSS source
Original source retained
DOM + CSSOM
Local update complete
Layout + draw input
Fixed geometry retained
Frame presentation
Server persistence not claimed

ACTORS · STATE · DATA FLOW

HTML bytes are not yet a DOM

Response-body decoding supplies a character stream to the HTML parser. Tokenization produces tags, text and comments, while tree construction builds a Document from those tokens. TCP segments and HTTP DATA frames do not define DOM node boundaries. One p element may span network chunks, while one chunk can contain several elements.

The source fixture <p id="note">Atlas & Web</p> makes this distinction visible: its DOM text is Atlas & Web, rather than the character-reference spelling. Inspecting parser output does not recover the original response bytes unchanged. This lesson separates the data layers of an ordinary selected input without pretending to implement every charset or streaming-parser state.

Tree construction is not a string copy

HTML has defined processing behavior for incomplete and erroneous markup. Implied html/head/body structure may appear, and a tr inside a table can cause a tbody that was absent from the source. View Source and the Elements tree can therefore differ. Follow parent/child relationships rather than visual indentation when selecting an element.

The ordinary <table><tr><td>Atlas</td></tr></table> fixture has no source tbody, yet the parser creates TBODY as table.firstElementChild. This does not make every invalid input safe for an application. Parse-error processing describes structure; input trust, application validation and output context remain separate questions. No parser-difference attack string or exploitation workflow is supplied.

The DOM is a live data model

The DOM exposes Documents and nodes as a tree-based platform model. JavaScript is a language that can use that model; the DOM is not JavaScript syntax itself. Nodes have identity, attributes and current text. Scripts can change current state while response source remains fixed. Holding a node reference does not mean a source file has been rewritten.

The native fixture sets note.textContent to Atlas — revised. That local operation replaces text children without changing the network response or server file. The scene updates its DOM card while retaining its source card. A visible client change also does not prove persistent business data was saved; save requests and server commits belong to other lessons.

CSSOM and computed style record different things

CSS parsing exposes stylesheet rules through platform objects. An authored CSSOM rule and an element’s resolved/computed style are not the same record. Selector matching, cascade, inheritance and layout-related resolved values affect the result. getComputedStyle is not the original CSS source; this fixture reads only selected width, height, color, display and visibility values.

The #note rule supplies width120px and height24px. With border-box and no padding or border, the measured size matches. #hidden uses display:none. #reserved uses visibility:hidden yet retains a box. Being present in the document tree, having a layout box and producing visible painted content are separate properties.

Render tree is a teaching shorthand

Browsers construct layout and painting data structures from document and style state. Render tree is a useful teaching shorthand, not one universally named public tree with a one-to-one DOM mapping. Chromium RenderingNG describes distinct fragment trees, property trees, display lists and compositor frames.

A hidden p in the DOM therefore need not produce a normal layout box. Pseudo-elements, anonymous boxes and text shaping also break a simple DOM=boxes equation. The model retains only selected note, hidden and reserved properties. The accessibility tree is another model; node and box observations here do not certify all accessibility behavior.

Layout, paint and frame presentation

Layout resolves sizes and positions. Paint produces drawing instructions; raster turns them into pixels or tiles; compositing and draw combine and present a frame. Chromium spreads this work across stages and threads and can skip unnecessary stages. Describing every CSS change as a mandatory complete reflow-repaint chain is misleading.

getBoundingClientRect observes border-box geometry rather than capturing paint. Measuring note width120 does not prove how its text appeared in a screenshot. The scene ends with a frame candidate and uncaptured pixels. Its animation explains dependencies rather than measuring the real browser rendering pipeline. With motion disabled, the missing and available artifacts remain readable.

Read every scenario without motion

Hidden data

The hidden node was selected in source and DOM records
The source contains Draft under id hidden, while CSS selects display:none. hiddenNodePresent is true. Not generating a box does not imply that data never reached the client DOM.
Source/DOM record
Draft node present / display:none
Interpretation/visibility
Interpretation pending
Data/presentation boundary
No verdict
Display control did not replace server policy
hiddenWidth and hiddenHeight are 0, describing layout visibility. Client CSS cannot protect private data the server should not deliver. Data delivery belongs to the server; box generation belongs to the client.
Source/DOM record
Draft node present / display:none
Interpretation/visibility
Box0×0 / node still present
Data/presentation boundary
No verdict
Invisibility was not an access denial
Draft is benign example text, not a claimed private disclosure. The mechanism boundary is clear: not visible and not delivered are different. An invisible UI does not establish computed object authorization.
Source/DOM record
Draft node present / display:none
Interpretation/visibility
Box0×0 / node still present
Data/presentation boundary
Visibility hidden / access policy unmeasured
The reserved box used a contrasting CSS condition
reserved has visibility:hidden while retaining width 80 and height 12 CSS px. display:none and visibility:hidden have different geometry. Two invisible elements are not necessarily removed from DOM or layout.
Source/DOM record
Reserved hidden / box80×12
Interpretation/visibility
Box0×0 / node still present
Data/presentation boundary
Visibility hidden / access policy unmeasured
Visibility effects retained their measurement scope
CSS uses fixed dimensions, zero margin/padding/border and border-box. This selected geometry is not a general pixel-perfect guarantee across fonts, viewports or device-pixel ratios. Box presence is not paint capture.
Source/DOM record
Reserved hidden / box80×12
Interpretation/visibility
CSS-pixel geometry only / paint unmeasured
Data/presentation boundary
Visibility hidden / access policy unmeasured
The control target stayed with delivered data
When private data must not be delivered, control belongs to response policy. UI visibility and layout are tested separately. Distinguishing DOM presence, geometry and screenshot evidence prevents the wrong protection assumption.
Source/DOM record
Reserved hidden / box80×12
Interpretation/visibility
CSS-pixel geometry only / paint unmeasured
Data/presentation boundary
Protect delivery server-side / inspect visibility separately

Source/live DOM

Original source retained its character reference
The note source contains Atlas & Web, while parsed DOM text is Atlas & Web. Source bytes and parser-produced text are different representations; current DOM serialization is not reported as the original response body.
Source/DOM record
Source & / parsed text &
Interpretation/visibility
Interpretation pending
Data/presentation boundary
No verdict
A text update was not another network response
Expected revisedNoteText is Atlas — revised. This ordinary local text update changes the current DOM without changing the source snippet or implying another response. textContent processes plain data in a text context.
Source/DOM record
Source & / parsed text &
Interpretation/visibility
Current text Atlas — revised / source retained
Data/presentation boundary
No verdict
Parser success was not a sanitization claim
Parsing ordinary source into a tree establishes neither authorization nor sanitization. Choosing a text API makes this update’s interpretation context explicit without guaranteeing security for every markup feature.
Source/DOM record
Source & / parsed text &
Interpretation/visibility
Current text Atlas — revised / source retained
Data/presentation boundary
Text context explicit / broader markup policy separate
An implied table node explained a source difference
parserFixture contains tr and td within a table, with expected impliedTableChild TBODY. A parser-created node absent from source is ordinary. That tree difference alone is neither application tampering nor new network content.
Source/DOM record
Source table/tr / parsed table/TBODY
Interpretation/visibility
Current text Atlas — revised / source retained
Data/presentation boundary
Text context explicit / broader markup policy separate
State provenance was retained with snapshots
Source, parsed DOM and current DOM after script are compared as separate snapshots. Local DOM stages are not drawn as HTTP packets. Knowing where state changed prevents mixing response evidence with UI evidence.
Source/DOM record
Source table/tr / parsed table/TBODY
Interpretation/visibility
Source→parsed DOM→local update, distinct snapshots
Data/presentation boundary
Text context explicit / broader markup policy separate
Source review was not a pixel or authorization verdict
The example explains text and tree interpretation without measuring paint, GPU or the full accessibility tree. Correct DOM text is neither a server-resource grant nor identical rendered pixels across devices.
Source/DOM record
Source table/tr / parsed table/TBODY
Interpretation/visibility
Source→parsed DOM→local update, distinct snapshots
Data/presentation boundary
Provenance known / pixels-authz unmeasured

ASSUMPTION · BOUNDARY · CONTROL

Keep source and current DOM evidence distinct

For an authorized review, retain source, parsed DOM and post-script DOM as separate snapshots. Source Atlas & Web alongside current Atlas — revised can be an ordinary local update. Reporting a current DOM serialization as the original response body loses provenance. The artifact places source and final text side by side.

Predict which child the parser adds to the table, whether display:none removes a DOM node, and whether visibility:hidden must have zero geometry. These ordinary-input questions teach interpretation. A hidden element is not automatically an access-control decision; data already delivered in a response and client CSS visibility belong to different layers.

Retain the limits of geometric measurements

Width and height can validate a selected browser fixture without proving pixel-perfect output on every device. Font, viewport, zoom and device pixel ratio have different effects. Dimensions here use fixed CSS pixels; no line-break or glyph-metric baseline is invented.

Do not draw network packets for local rendering stages. A DOM text update does not imply another response, and a display-list handoff is not HTTP. Keep present in DOM, measurable box and visible in an image as separate findings. A UI observation then retains the layer to which it belongs.

Read every scenario without motion

Geometry ledger

Parsed text and parser nodes were selected separately
The artifact stores authored HTML/CSS beside expected API results. In a new browser observation, the parser produces DOM text/TBODY, getComputedStyle supplies style values and getBoundingClientRect supplies CSS-pixel geometry. The expected field cannot replace that measurement; geometry cannot supply a screenshot or paint receipt either. Expected parsedNoteText is Atlas & Web and impliedTableChild TBODY. These invariants separately check text decoding and tree construction. Searching only the original source for TBODY misses the node the parser normally adds.
DOM/CSS ledger
Text Atlas & Web / implied TBODY
Invariant comparison
Interpretation pending
Evidence verdict
No verdict
The fixed note box was compared in CSS units
The expected note box is 120 by 24 CSS px with color rgb(15, 118, 110), zero padding and border. CSS px is not renamed as device pixels or screenshot glyph dimensions.
DOM/CSS ledger
Text Atlas & Web / implied TBODY
Invariant comparison
Note120×24 CSS px / color known
Evidence verdict
No verdict
Two hidden conditions entered the comparison table
hidden stays in DOM with a 0×0 box. reserved retains an 80×12 box with visibility hidden. These ordinary negative controls show that absent visible text and layout participation are different measures.
DOM/CSS ledger
Hidden0×0 / reserved80×12 / both nodes retained
Invariant comparison
Note120×24 CSS px / color known
Evidence verdict
No verdict
The local-update invariant was not confused with source
revisedNoteText Atlas — revised is the expected current text after script, not original response-capture bytes. Regression identifies the broken invariant rather than relabeling the whole rendering pipeline as one failure.
DOM/CSS ledger
Hidden0×0 / reserved80×12 / both nodes retained
Invariant comparison
Updated current text / original source distinct
Evidence verdict
No verdict
The geometry verdict did not become paint capture
paintCaptured is false. DOM and geometry observations can measure these invariants; compositor or GPU output needs a separate capture. Supplied expected DOM/box values do not imply that actual measurement was performed in this browser.
DOM/CSS ledger
Hidden0×0 / reserved80×12 / both nodes retained
Invariant comparison
Updated current text / original source distinct
Evidence verdict
DOM/box expectations known / paint unmeasured
Regression retained minimal observable fields
Node presence, parsed text, CSS dimensions and local-update outcomes are checked separately without collecting a full page or private content. Explaining why a state did not change retains measurement scope.
DOM/CSS ledger
Hidden0×0 / reserved80×12 / both nodes retained
Invariant comparison
Updated current text / original source distinct
Evidence verdict
Recheck node/text/box/update separately

Paint gap

Absence of the paint record was selected explicitly
The artifact stores authored HTML/CSS beside expected API results. In a new browser observation, the parser produces DOM text/TBODY, getComputedStyle supplies style values and getBoundingClientRect supplies CSS-pixel geometry. The expected field cannot replace that measurement; geometry cannot supply a screenshot or paint receipt either. The artifact has expected.paintCaptured false. Note dimensions and current text are known, but there is no screenshot or compositor capture. These observations answer only part of the visibility question.
DOM/CSS ledger
DOM/text/box known / paint capture absent
Invariant comparison
Interpretation pending
Evidence verdict
No verdict
Box measurement did not replace actual pixels
Width 120 and height 24 do not prove the exact painted text pixels. Fonts, viewport, zoom and device-pixel ratio have different effects. Geometry and screenshot evidence belong to different observer scopes.
DOM/CSS ledger
DOM/text/box known / paint capture absent
Invariant comparison
CSS geometry ≠ captured pixels
Evidence verdict
No verdict
Benign visibility controls did not fill missing paint
Expected display:none and visibility:hidden behavior explains ordinary CSS mechanisms. Correct source rules do not measure the entire rendered image. A normal-fixture appearance is not copied into a missing capture.
DOM/CSS ledger
Expected CSS effects are not screenshot evidence
Invariant comparison
CSS geometry ≠ captured pixels
Evidence verdict
No verdict
Pipeline stages were separated from data transfer
A DOM update or display-list handoff is not an HTTP exchange. Stage aliases are not a full Chromium-fragment/display-list capture. Local geometry changes do not establish new requests or server delivery.
DOM/CSS ledger
Expected CSS effects are not screenshot evidence
Invariant comparison
Local stages / no HTTP transfer inference
Evidence verdict
No verdict
The paint verdict remained unknown
Exact painted pixels remain UNKNOWN for this evidence. No paint capture does not prove rendering failure, and ordinary geometry is not pixel-perfect proof. The full accessibility tree likewise needs appropriate observation.
DOM/CSS ledger
Expected CSS effects are not screenshot evidence
Invariant comparison
Local stages / no HTTP transfer inference
Evidence verdict
UNKNOWN: exact painted pixels
The new observation boundary was tied to its purpose
Pixel questions need viewport, font/zoom context and an actual capture. DOM questions may need only scoped node/text observations. Different evidence families are not collapsed into one verified label without stating the question answered.
DOM/CSS ledger
Expected CSS effects are not screenshot evidence
Invariant comparison
Local stages / no HTTP transfer inference
Evidence verdict
Choose DOM or pixel evidence for the actual question

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Place data in its intended context

The artifact stores authored HTML/CSS beside expected API results. In a new browser observation, the parser produces DOM text/TBODY, getComputedStyle supplies style values and getBoundingClientRect supplies CSS-pixel geometry. The expected field cannot replace that measurement; geometry cannot supply a screenshot or paint receipt either. Choosing a text-oriented API such as textContent makes plain-text interpretation explicit. If a product requires HTML parsing, accepted markup and trust policy need their own design. A parser producing a tree does not prove authorization or sanitization. This lesson performs an ordinary text update without claiming the guarantees taught in later output-context lessons.

Hiding private data with CSS does not undo its delivery. Server policy decides delivery; the client model decides visibility and layout. Retaining the hidden node in the artifact teaches that distinction. The learner should explain the layer to which data was delivered rather than stopping at looks hidden.

Tie checks to observable invariants

The fixture has small observable invariants: decoded character-reference text, implied TBODY, a retained hidden node, fixed note geometry and current text after mutation. Native browser APIs can observe these. Paint instructions and compositor internals require separate capture and are not evidence supplied by this test.

Prose and scene share an ordinary ledger; manual steps and reduced motion retain the source/DOM/box/frame distinction. When a UI test regresses, name the broken invariant instead of relabeling the entire pipeline. Learner acceptance also needs an explanation of which state remained unchanged and why. Browser output and learning outcome remain separate records.

NOW APPLY IT TO THE CASE

Which separate observations cover source, parsed DOM, local updates and paint?

Source Atlas & Web becomes Atlas & Web in DOM, and a local update changes the text to Atlas — revised. Draft remains in DOM without a display:none box. Reserve retains space under visibility:hidden. Box geometry is not paint capture.

Order response receipt, parsing, callbacks and visible DOM outcome in the case. Try explaining the retained old title through this lesson’s browser-state distinctions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Source / DOM / box / frame ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "htmlFragment": "<main><p id=\"note\">Atlas &amp; Web</p><p id=\"hidden\">Draft</p><p id=\"reserved\">Reserve</p></main>",
  "css": "#note{width:120px;height:24px;margin:0;padding:0;border:0;box-sizing:border-box;color:rgb(15,118,110)}#hidden{display:none}#reserved{visibility:hidden;width:80px;height:12px;margin:0;padding:0;border:0;box-sizing:border-box}",
  "parserFixture": "<table><tr><td>Atlas</td></tr></table>",
  "expected": {
    "parsedNoteText": "Atlas & Web",
    "impliedTableChild": "TBODY",
    "hiddenNodePresent": true,
    "noteWidth": 120,
    "noteHeight": 24,
    "hiddenWidth": 0,
    "hiddenHeight": 0,
    "reservedWidth": 80,
    "reservedHeight": 12,
    "reservedVisibility": "hidden",
    "noteColor": "rgb(15, 118, 110)",
    "revisedNoteText": "Atlas — revised",
    "paintCaptured": false
  },
  "measurementUnits": "CSS px;synthetic fixed style,no padding/border",
  "pipelineStages": "Instructional aliases;not full Chromium fragment/display-list capture"
}

htmlFragment: Ordinary authored source for native parsing,not a network capture.
expected.impliedTableChild: Parser-created table section absent from authored source.
expected.noteWidth: Fixed border-box geometry,not screenshot or paint evidence.
expected.paintCaptured: False: DOM/geometry is not compositor capture.

Selected ordinary HTML/CSS fixture. Source,live DOM and CSS-pixel geometry observations are not paint/GPU capture or full accessibility-tree validation.

Two reality checks

View Source and the current DOM are identical.

The parser can add implied nodes and script can change the current tree; the original response is separate evidence.

Every DOM node has a visible box.

display:none suppresses the normal box while visibility:hidden can retain one;DOM,geometry and visible pixels differ.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

#hidden has display:none. Is the node removed from the DOM?

No; the node exists, but its selected box width/height are 0.
Yes; the parser removes every invisible element.

Read the explained answer

No; the node exists, but its selected box width/height are 0. — hiddenNodePresent=true; display:none produces no layout box in this fixture and does not delete the node.

What do source & , parsed text & and implied TBODY show?

Selected lesson artifact fields; teaching example

htmlFragment: <main><p id="note">Atlas & Web</p><p id="hidden">Draft</p><p id="reserved">Reserve</p></main>
expected.parsedNoteText: Atlas & Web
expected.impliedTableChild: TBODY

The DOM is an unchanged copy of source bytes.
The parser resolves character references and tree-construction rules may insert nodes.

Read the explained answer

The parser resolves character references and tree-construction rules may insert nodes. — ParsedNoteText becomes Atlas & Web; TBODY may appear in the table fixture although absent from source.

What do a visibility:hidden reserved box 80×12 and paintCaptured=false say together?

Read the explained answer

The reserved element may retain layout space while its content is not expected to be visibly painted. An 80×12 CSS-pixel rect is not an actual-pixels capture. This fixed-style example does not validate the full browser-render pipeline or compositor-frame completion.

□ I distinguished reserved space from visible content.

□ I inferred no paint completion from geometry.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

MANUAL LAB

Browser Observation Lab

Predict Document, DOM/CSS, and event-loop results in 18 fields, record native Browser observations, and explain why.

Open the prediction → observation → explanation workbook ↗Source on GitHub ↗

Sources and scope

WHATWG HTML: parsing HTML documents13.2.1 Overview of the parsing model; 13.2.2 Parse errors; 13.2.6 Tree construction; in table and in table body modes
WHATWG DOM: trees and textContentTrees; Nodes; textContent; string replace all
CSS Object Model Level 1CSSStyleSheet; CSSStyleRule; getComputedStyle resolved values
Chromium RenderingNG architectureRendering pipeline structure:Style, Layout, Pre-paint, Paint, Commit, Layerize, Raster, Activate, Aggregate, Draw; Threads
Element getBoundingClientRectReturn value; box sizing; border box; empty border boxes
MDN: Document Object ModelDocument structure; programming interface; DOM and JavaScript
DOMParser parseFromStringDescription:text/html, Document, inert parse; separate document

YOUR NOTES / THIS BROWSER

From HTML to DOM,layout and paint

1. Core · Mechanism

Visible note

Hidden vs reserved

DOM text update

HTML bytes are not yet a DOM

Tree construction is not a string copy

The DOM is a live data model

CSSOM and computed style record different things

Render tree is a teaching shorthand

Layout, paint and frame presentation

2. Red · Trust & Impact

Hidden data

Source/live DOM

Keep source and current DOM evidence distinct

Retain the limits of geometric measurements

3. Blue · Secure development & defense

Geometry ledger

Paint gap

Place data in its intended context

Tie checks to observable invariants

Which separate observations cover source, parsed DOM, local updates and paint?

Two reality checks

#hidden has display:none. Is the node removed from the DOM?

What do source &amp; , parsed text & and implied TBODY show?

What do a visibility:hidden reserved box 80×12 and paintCaptured=false say together?

Browser Observation Lab

Sources and scope

What do source & , parsed text & and implied TBODY show?