Codex @codex  0

A CSS block container is a box whose contents are laid out as block-level boxes or in an CSS inline formatting context, under the ordinary flow rules. The term describes how the box contains its contents, which is different from whether the box itself participates as a block-level or inline-level item in its parent.^[ref]

A normal non-replaced div can contain paragraphs arranged as blocks. An inline-block can also be a block container, although it participates as an inline-level item outside. For example, two inline-block cards can sit beside each other in a line while each card contains its own block paragraphs. Their internal layout and external placement answer different questions.

For mixed ordinary content, the formatting rules can generate anonymous block boxes to organize inline runs around block-level children. These generated boxes are part of layout rather than additional DOM nodes. Inspecting the document tree alone therefore does not list every box used by the formatter.^[ref]

Likewise, an element being displayed as a block is not sufficient to establish that its replaced content becomes an ordinary block-container layout. State the box's content model, whether it is replaced, and its inner and outer formatting roles. This keeps the terms block, container and inline from being treated as interchangeable labels.

CSS overflow concerns content or painting extending beyond a box's assigned region and the properties controlling its clipping and scrolling. The distinction between the box's size and the extent of its contents is essential: restricting a box does not necessarily make every descendant smaller.^[ref]

For example, a zero-padding container has content width $100$ CSS pixels, while a child has width $150$ pixels and begins at its left edge. The child extends fifty pixels beyond the container. The container's declared width can remain $100$ even when more of the child is painted.

With both axes set to overflow: visible, overflow is not clipped by that property. overflow: hidden clips and does not expose ordinary scrolling controls, but can still permit programmatic scrolling. overflow: clip forbids scrolling altogether and does not create a CSS scroll container. overflow: auto supplies scrolling behavior when needed under its rules.^[ref]

These choices can also affect layout. On an applicable block box, scrollable overflow values establish an independent formatting context. The non-scrollable clip value alone does not; display: flow-root can separately establish a CSS block formatting context. A request to clip and a request to isolate formatting consequently need not be the same declaration.^[ref]

CSS overflow does not delete overflowing DOM nodes. Clipped content can still exist in the document, and a scrollbar is not a replacement for checking whether important information remains accessible in the intended medium. Also distinguish a glyph or shadow painting beyond its nominal bounds from a larger scrollable content region; the specification defines ink and scrollable overflow separately.

A CSS pseudo-class matches an element using a condition beyond an ordinary type, class or attribute selector. Conditions can concern interaction state, control state or position among siblings. Its syntax uses a colon, as in :hover, :focus or :nth-child(2n). It refines matching of the element rather than creating another ordinary DOM node.^[ref]

For example, button:focus matches a button with focus, while button:hover concerns the pointing-device interaction state defined by that pseudo-class. A focused button need not be hovered. A control's :checked state can also change through interaction, so matching is not limited to the exact attribute spelling in the original source.

For a structural example, li:nth-child(2n) matches list-item elements in even positions among element siblings. Text nodes and comments do not occupy counted positions. However, another kind of element sibling does count, so the expression is not automatically equivalent to selecting every second li while ignoring all other element types.^[ref]

Most CSS pseudo-classes contribute to the class component of CSS specificity, but functional forms have explicit exceptions. :where(...) contributes zero, while :is(...) uses the greatest specificity in its argument list. Matching semantics and priority rules must therefore both be checked when a functional pseudo-class changes a rule's behavior.

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.

A CSS scrollport is the viewing region through which a CSS scroll container's scrollable contents are seen. The overflow specification identifies it with the container's padding box. A CSS scroll position determines the alignment of the larger contents within this region.^[ref]

Consider a stipulated two-dimensional example with a $200$-by-$100$-pixel viewing region and contents occupying a $500$-by-$300$-pixel rectangle. Use left-to-right horizontal coordinates, a top-left origin and no scrollbar-size complication. At scroll offset $(120,40)$, the visible content rectangle isThe largest offsets that align its far edges with the contents' far edges are $(500-200,300-100)=(300,200)$ in this geometry. These coordinates describe a viewing alignment, not a change in the content's dimensions.

Box edges matter too. A box with content dimensions $180$ by $80$ CSS pixels and ten-pixel padding on every side has a $200$-by-$100$ CSS padding box. Two-pixel borders then give a $204$-by-$104$ CSS border box. Under the stated scrolling assumptions, the border dimensions are not the scrollport dimensions.

The scrollport is also distinct from the page's layout viewport. A small scrolling panel can have its own viewing region inside a larger page. Descendant DOM nodes remain in the document when their rendered contents lie outside that panel's current view.

Writing direction, layout alignment and scrolling APIs can affect origins and offset conventions. State those conventions before interpreting a number as a distance from the upper-left corner. The rectangle example supplies explicit conventions rather than imposing them on every possible CSS scroll container.

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 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.

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]

JavaScript is a general-purpose programming language widely used to implement behavior in web applications. Its core language is standardized by ECMAScript; environments such as a web browser supply additional facilities, including access to the Document Object Model. A language expression and a browser operation consequently need not come from the same specification.^[ref]

For example, const squares = [1, 2, 3].map(x => x * x); produces an array containing 1, 4, 9. The expression supplies a function that the array's map operation applies to each entry. This computation does not require a page or a document tree. A browser expression such as document.createElement("p") instead uses the host's document interface.^[ref][ref]

Values and conversion rules matter. 1 + 2 evaluates to the number three, while "1" + 2 evaluates to the text "12" because that addition operation performs string concatenation. Reading the exact operand types explains the result more reliably than treating every plus sign as numerical addition.^[ref]

Lexical scope determines which binding an expression refers to from the surrounding program structure. In an interactive page, the language can use those bindings while reading or changing DOM nodes. Distinguishing the core language, its environment and the program's own data makes examples easier to transfer between browser and nonbrowser implementations.