Clarifying "text node" definition (step 2G)

[rahimabdi]

In "4.3.2 Computation steps", Step 2G of the name computation algorithm states:

G. Text Node: Otherwise, if the current node is a Text Node, return its textual contents.

Although a "Node" definition is provided, it's not made explicit what a "text node" is. I would propose adding more documentation, e.g.,:

• The DOM spec "Text" interface definition: https://dom.spec.whatwg.org/#interface-text
• Also the "Node" interface, rather than linking to the Node tree definition: https://dom.spec.whatwg.org/#interface-node

Other sections that would need updating with linked "node" references:

• 4 Name and Description
• 4.3 Text Equivalent Computation

Further clarification from @cookiecrook and additional context for why this is being recommended in https://github.com/web-platform-tests/wpt/pull/42407#discussion_r1372401204:

These are inherited from XML/DOM terms: most commonly text node versus element node versus comment node. Element nodes can be empty or contain other element, comment, and text nodes, but IIRC text nodes and comment nodes are always leaf nodes.

[jnurthen]

Competing text node definitions:

• https://dom.spec.whatwg.org/#dom-node-text_node {{Node/TEXT_NODE}}
• https://drafts.csswg.org/css-display-4/#text-nodes [=CSS/text node=]

[OrKoN]

I think the spec should also define what the node's textual content is (found this issue by trying to answer the question about how whitespaces should be handled when computing the name).

[rahimabdi]

I would propose using the DOM text interface definition: https://dom.spec.whatwg.org/#interface-text.

@OrKoN from my investigation, the "textual contents" of text nodes (Text interface) is its data; text nodes implement the CharacterData interface which has a data instance property:

Each node inheriting from the CharacterData interface has an associated mutable string called data.

In terms of DOM spec, for text nodes (and also comment nodes), they also inherit from the generic Node interface which has a nodeValue property; it's my understanding that data is the same thing as nodeValue for text nodes.

Depending on the definition's granularity, the textual contents could be the data of the text node although that is less readable than the node's "string value" or simply "text contents" IMO.

---

July 14 update: Specifically, it looks like the exclusive text node definition should be referenced from the Text interface. An "exclusive text node" is effectively the text contents that is referenced in accname per nodeType.

DOM spec states the definition of "exclusive text node" as:

An exclusive Text node is a Text node that is not a CDATASection node.

[OrKoN]

I think using text node data would not match the current behavior when dealing with whitespaces:

Source: data:text/html,<h2> foo</h2>

[OrKoN]

(nodeValue does appear to be the same in this accessible)

[rahimabdi]

I think using text node data would not match the current behavior when dealing with whitespaces:

I believe trimming whitespace generally from accName/accDescription ((e.g., trailing/leading whitespace) is being tracked here: https://github.com/w3c/accname/issues/95.