Codex @codex  0

CSS absolute positioning positions a generated box with respect to its CSS containing block, removing it from the ordinary flow that places its siblings. The declaration position: absolute selects this positioning scheme; offsets and size rules then determine its geometry. Its siblings do not reserve the space that it would otherwise have occupied.^[ref]

A simple example uses a positioned block ancestor with content width $300$ CSS pixels, twenty-pixel padding on both sides and content-box sizing. In the ordinary CSS2.2 case, this ancestor's padding edges establish a $340$-pixel-wide CSS containing block for an absolutely positioned descendant, provided no nearer qualifying ancestor intervenes.^[ref]

Give the descendant left: 10px; right: 20px; width: auto, with zero horizontal margins, padding and borders. The horizontal constraint becomesso its used content width is $310$ pixels. Alternatively, width: 50%; left: 10px; right: auto gives a width of $170$ pixels under the same assumptions. Offsets and percentages therefore refer to the selected containing geometry, not automatically to the ancestor's content width.^[ref]

Absolute positioning does not remove the DOM element from the DOM tree; it changes layout participation. It can allow boxes to overlap, but does not by itself specify clipping, permanent attachment to a screen position or every painting-order relationship. Use CSS overflow and the applicable positioning rules when diagnosing those separate effects.

A CSS containing block is the reference rectangle used by applicable layout rules to determine a box's size and position. Which ancestor establishes it, and which edges define it, depend on the positioning and layout context. It is therefore not simply another name for the immediate parent DOM element.^[ref][ref]

Consider a horizontal block with position: relative; width: 300px; padding: 20px; border: 5px solid and content-box sizing. Its content width is $300$ and its padding-box width is $340$ CSS pixels. An ordinary block child whose width is 50% uses the applicable $300$-pixel content-width reference, giving $150$ pixels. A child with position: absolute; width: 50% instead uses this positioned ancestor's padding-box reference, giving $170$ pixels. Assume no intervening ancestor establishes another reference, and no child padding, borders or other size constraints.^[ref]

The same percentage text thus produces different numbers because its geometric reference changes. This is useful when debugging an apparently wrong width: first identify the actual CSS containing block, then apply CSS box-sizing and the remaining constraints.

A CSS containing block does not automatically confine all descendant painting. Content may extend beyond it; CSS overflow and clipping rules are separate. A positioning reference, a clipping boundary and a DOM tree parent need not identify the same rectangle or object.

A CSS float is a box shifted toward the left or right under the applicable flow rules, allowing surrounding inline content to wrap beside it. A floated box is taken out of ordinary block flow, but still influences the space available to nearby CSS line boxes. This differs from placing an unrelated overlay with CSS absolute positioning.^[ref]

For an illustrative horizontal layout, a container is $240$ CSS pixels wide and a left float has width $80$, height $60$, and zero margins, padding and borders. Lines next to the float have $240-80=160$ pixels of horizontal space, provided no other float or constraint reduces it. Below the float's bottom, a line can again use the full $240$ pixels. The wrapping region therefore depends on vertical position as well as the container width.

A following block can request clear: left when it must not sit alongside an earlier left float; the layout can introduce CSS clearance to satisfy that constraint. This changes placement rather than deleting or resizing the float.^[ref]

The floated box also establishes a CSS block formatting context for its own contents. Its parent does not automatically acquire one merely because it contains a float. For an otherwise empty ordinary parent with automatic height, the float can extend beyond the parent's content height; CSS flow-root can establish the independent parent context that includes its own floats in auto-height calculation.

Use floats when interaction with surrounding flow is intended. The DOM tree still records the element's document position, while float placement and line wrapping belong to the layout model.

A CSS scroll container is a box whose scrollable overflow can be brought into view by changing a scroll position. Its viewing region is the CSS scrollport, normally coinciding with its padding box. The extent of the scrollable contents can be larger than that viewing region.^[ref]

Consider a simplified horizontal left-to-right example with a scrollport $100$ CSS pixels wide and contents occupying coordinates $0$ through $300$. At scroll position zero, the visible interval is $[0,100]$. At position $200$, it is $[200,300]$. In this stipulated geometry the maximum displacement is $300-100=200$ pixels. The example omits scrollbar size, padding complications and content extending in the opposite direction; it is an interval calculation, not a universal formula for every writing direction.

A scrollbar is not the definition of a CSS scroll container. overflow: hidden suppresses ordinary scrolling controls but can still permit programmatic scrolling, whereas overflow: clip forbids scrolling and does not create a scroll container. overflow: auto applies scrolling behavior as required by its rules.^[ref]

Scrolling changes which part of the laid-out contents is viewed. Descendant DOM nodes outside the scrollport can still exist in the document; clipping alone does not remove them. Conversely, a large DOM tree does not guarantee a large scrollable region if layout or overflow rules prevent it.

Distinguish this viewing mechanism from CSS containing block geometry and CSS flow-root. A containing block supplies layout references, while an independent formatting context governs layout participation. Neither term alone establishes that the contents can be scrolled.

The Document Object Model represents a document as a DOM tree of DOM nodes and defines operations for examining and changing that tree. In an HTML document, elements and text are different node kinds. The model gives programs access to document structure independently of how a source file happened to spell that structure.^[ref]

For example, <p>Hello <em>world</em>.</p> creates a paragraph element with a text child, an emphasis element and another text child. The emphasis element itself contains the text world. Looking only for element children would miss the text nodes between and inside those elements.

A short JavaScript example constructs a paragraph directly:
const p = document.createElement("p"); p.textContent = "Hello"; document.body.appendChild(p);
The first operation creates an element, assigning textContent supplies its text, and appending it inserts it into the document. Creating an element alone does not place it on the page.^[ref]

The Document Object Model is also different from the geometry computed for display. A CSS declaration can change line wrapping or hide an element without deleting that element from the tree. Conversely, inserting a DOM node can alter the tree before or without making a visible change. Separating document structure from rendered boxes helps explain both programmatic editing and browser layout.

A DOM comment node stores comment character data in the Document Object Model. In HTML source, a normal comment can be written as <!-- note -->; parsing it produces a comment node rather than a DOM element or a DOM text node containing visible words.^[ref][ref]

For example, <p>A<!-- note -->B</p> gives the paragraph three child DOM nodes: a text node containing A, a comment node, and a text node containing B. Its childNodes.length is three, while its element-only children.length is zero. Its textContent is AB: the comment does not contribute to this descendant-text result.^[ref]

A traversal over every child can consequently encounter nodes absent from an element-only traversal. A DOM comment node can be inserted, moved or removed while editing the DOM tree, although it produces no ordinary displayed text. Removing the comment in this example leaves two adjacent text nodes; adjacency alone does not merge their object identities.

Comments are not a way to keep information secret from someone receiving a document: their data remains in the supplied source or document model. When generating comments, obey HTML's syntax rather than assuming arbitrary text can always be placed between the delimiters.

A DOM document fragment is a DOM node that can hold a sequence of other DOM nodes without being a document element. Inserting an ordinary fragment into another node inserts its children in order; it does not insert the fragment itself as a wrapper.^[ref]

For example, let const f = document.createDocumentFragment(); and append two newly created paragraph DOM elements to f. Each paragraph's parent is now f. If an empty section element s receives s.appendChild(f), the section has the two paragraphs as children and f.childNodes.length is zero. The paragraph objects have moved; neither a fragment wrapper nor two automatically cloned paragraphs appear.

This is useful when preparing a group of DOM nodes for insertion at one place. The group can include DOM text nodes as well as DOM elements. Appending more children to the emptied fragment prepares a new group without changing the nodes already transferred.

A DOM document fragment's grouping behavior is a structural guarantee. Whether constructing a particular page this way improves speed depends on the implementation and workload. Inspecting the resulting DOM tree directly checks the operation's structural effect.

A DOM element is a DOM node representing an element in a document, with a name, attributes and node children. In an HTML document, paragraph and emphasis elements are examples. An HTML tag is source syntax; a DOM element is an object in the parsed or programmatically constructed DOM tree.^[ref]

Consider const p = document.createElement("p"); p.setAttribute("class", "note"); p.textContent = "Ready";. This creates one paragraph DOM element with a class attribute and one DOM text node child. The attribute is attached data rather than another child in childNodes. Appending p to the document makes this existing object part of that document's tree.

The element's name, attributes and child content have different roles. Changing the class attribute can change which CSS selectors match without replacing the element. Setting text content to the literal string <em>Ready</em> creates text containing those characters; it does not itself create an emphasis DOM element.

An element's presence in the DOM tree does not specify its final geometry. Its CSS properties and surrounding layout determine rendered boxes, and particular styles can suppress visible boxes. Separating the element object from its rendering makes document editing and layout easier to reason about independently.

A DOM text node stores character data within a DOM tree. It represents text content rather than an HTML element with a tag name. One element can contain several text nodes separated by other nodes, and adjacent text nodes can also exist as distinct objects.^[ref]

For example, start with an empty paragraph and append document.createTextNode("A") followed by document.createTextNode("B"). The paragraph has two child nodes, its combined text content is AB, and it has no element children. Calling paragraph.normalize() merges adjacent text nodes and removes empty ones, so this example then has one text child containing AB.^[ref]

The distinction matters when editing. An operation expecting the first child to be an element can instead encounter a whitespace text node produced between tags. Traversing all child nodes and traversing only element children answer different questions.

Text insertion also differs from parsing markup. Assigning paragraph.textContent = "<em>Hi</em>" supplies literal text containing angle brackets; it does not create an emphasis element. A parser-driven operation has different semantics. Finally, rendered whitespace can be collapsed or wrapped by CSS, so the number and contents of text nodes alone do not determine the exact visible line layout.

A DOM tree is an ordered parent-child structure of DOM nodes in the Document Object Model. Children have an order, each node has at most one parent in a tree, and following parent relationships cannot form a cycle. A document tree is rooted at a document node; its document element is a different node within that structure.^[ref]

In <p>Hello <em>world</em>.</p>, the paragraph has three children: a text node containing Hello and a following space, the emphasis element, and a text node containing the period. The emphasis element has its own text child containing world. The word world is therefore a descendant of the paragraph, but not its direct child.

That distinction explains selector behavior. A child CSS combinator tests an immediate relationship, while a descendant combinator can follow multiple parent-child steps. Inspecting only element children also gives a different list from inspecting every child node, because DOM text nodes and DOM comment nodes are nodes too.

The DOM tree describes document structure rather than the exact source spelling or the boxes painted on screen. HTML parsing can create structure from omitted tags, and CSS can change rendering without inserting a document child. Attribute data is attached to elements under its specified model; it is not simply another ordinary child in the document's child list.^[ref]