Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifying "text node" definition (step 2G) #212

Open
rahimabdi opened this issue Oct 26, 2023 · 6 comments · May be fixed by w3c/aria#2274
Open

Clarifying "text node" definition (step 2G) #212

rahimabdi opened this issue Oct 26, 2023 · 6 comments · May be fixed by w3c/aria#2274
Assignees
Milestone

Comments

@rahimabdi
Copy link

rahimabdi commented Oct 26, 2023

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

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 web-platform-tests/wpt#42407 (comment):

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.

@rahimabdi rahimabdi changed the title Clarifying "text node" definition in AccName (step 2G) Clarifying "text node" definition (step 2G) Oct 26, 2023
@spectranaut spectranaut added this to the 2023H2 milestone Nov 2, 2023
@jnurthen
Copy link
Member

jnurthen commented Nov 2, 2023

Competing text node definitions:

@OrKoN
Copy link

OrKoN commented Jul 1, 2024

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
Copy link
Author

rahimabdi commented Jul 12, 2024

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.

@rahimabdi rahimabdi linked a pull request Jul 12, 2024 that will close this issue
@OrKoN
Copy link

OrKoN commented Jul 12, 2024

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

Screenshot 2024-07-12 at 07 42 15

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

@OrKoN
Copy link

OrKoN commented Jul 12, 2024

Screenshot 2024-07-12 at 07 43 37

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

@rahimabdi
Copy link
Author

rahimabdi commented Jul 14, 2024

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: #95.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants