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 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 node is an object participating in the node model of the Document Object Model. Documents, DOM elements, DOM text nodes, DOM comment nodes and DOM document fragments are different node kinds. They share operations and relationships defined by the Node interface, while particular kinds expose additional data and constraints.^[ref]

For example, a paragraph element can contain a text node. The paragraph has a tag name and attributes; its text child stores character data. Both are DOM nodes, but an element-specific operation such as setting an attribute is not thereby available on the text node.

Insertion also concerns object identity. Suppose an existing paragraph is a child of element A. Executing B.appendChild(paragraph) moves that same node under B, removing it from A's child list. It does not automatically make a second paragraph. Cloning is a separate operation, with its own treatment of descendants.^[ref]

A newly created node can exist without being connected to a displayed document. Conversely, a connected node need not produce a visible box: a CSS declaration can suppress its display. A reference to a node therefore identifies a document-model object, not a promise about visibility or a fixed screen position. Reading the node kind and its current tree relationships is the appropriate starting point for manipulation.

ECMAScript is the standardized core language underlying JavaScript. It specifies grammar, values, built-in objects and evaluation rules; a JavaScript engine implements those rules within a host environment. A web browser's Document Object Model facilities come from additional platform specifications rather than from the core language alone.^[ref]

For example, the language-level computation const a = {count: 1}; const b = a; b.count += 1; a.count gives 2: the two bindings refer to the same object. Copying the binding into b did not make a separate copy of the object's contents. This computation needs no DOM elements.

Contrast document.createElement("p"). The property access and function-call syntax belong to ECMAScript, but the supplied document object and its element-creation behavior come from the host's Document Object Model. A language expression can be syntactically valid even when an environment has not provided a referenced platform object.^[ref]

ECMAScript also defines observable choices such as string concatenation versus numerical addition and the rules for lexical scope. These rules do not require every JavaScript engine to use the same internal representation or execution strategy. Reading a program requires distinguishing specified language behavior from the additional facilities supplied by its host.

An HTML void element is an HTML element whose HTML syntax permits no contents and no end tag. Examples include br, img and input. An ordinary element that happens to contain no text does not thereby become void.^[ref]

For example, <p>A<br>B</p> contains a paragraph with text A, a line-break element and text B. The br start tag has no matching </br> end tag. An image's source and alternative text likewise use attributes such as src and alt, rather than child text between an image start/end pair.

The optional slash in <br /> does not create the void behavior; br is void because of its element category. The same slash does not make <div /> into a generally self-closing ordinary HTML element. Reading such source requires the HTML parser's rules.^[ref]

Source conformance and general Document Object Model operations must also be distinguished. A program can construct a node tree that violates an element's HTML content restrictions. Such an object does not make nonconforming source or a void element's hypothetical children a valid way to serialize HTML. The DOM element model and the allowed source syntax answer different questions.