Consider allowing CSS inline display to modify the whitespace character joins in accessible name computation

[cookiecrook]

From another PR that I'm mostly gutting due to merge conflicts and an inability to land on consensus in time for the looming AccName CR.

On the [18 Jan 2024] call, @accdc said [the references to spacing should be dependent on] whether or not the element had an inline or similar value, versus a block or similar display value. I assume the "block-like" values include inline-block, cell, and the like. I'm not sure if display:contents or other newer layout tooling values are considered "block-like" or not.

Presumably the interior contents would be promoted for "adjacency" consideration?

If the above is correct, I also presume that would mean if either of the adjacent elements (or their pseudo when joining pseudos) had a "block-like" display then use a space joiner...

Unknown at the moment whether that is implementable, and also unknown is how far the render tree should consider "adjacent" render objects... For example, if the adjacent DOM element is display:none (or display:contents), is the expectation that the renderer check the next adjacent element or pseudo that is not display:none? What about a display:inline element with visibility:hidden?

Originally posted by @cookiecrook in #168 (comment)

[cookiecrook]

I think Bryan's summary was that inlines would concat without space.

<span>foo</span><span>bar</span> = "foobar"
<span>foo</span> <span>bar</span> = "foo bar" (interior space between inline elements meaningful)

and "block-like" values (pretty much every display value besides inline) would be joined with a space, even if only one of the adjacent ~nodes was non-inline.

<div>foo</div><span>bar</span> = "foo bar"

Bryan's thought was this also applies to pseudo elements, but the interior extra concatenated space is only used if both the pseudo and its element are display:inline or equivalent.

Again, I'm not yet sure if this is implementable, and there are a number of other open questions...

[cookiecrook]

If the solution gets complicated enough, such as a table listing all the CSS display values (or other properties for that matter) and how they affect Accessibility API related mappings, then there might be a need to revisit the idea of a CSS-AAM spec.

[fantasai]

CSS's most current definition of how to most correctly convert to plaintext is here btw: https://www.w3.org/TR/css-text-4/#plaintext
Note that if you're not in an inline formatting context, collapsible whitespace sequences get collapsed away.
(I would add an expectation that generated content via ::before/::after/::marker would be included in the conversion.)

[cookiecrook]

Thanks @fantasai... that and the cross-referenced section, CSS Text: 4.3.1. Phase I: Collapsing and Transformation, seem like the most promising path forward.

[spectranaut]

Discussed in today's meeting: https://www.w3.org/2024/02/01-aria-minutes.html#t05

[dd8]

I think there might be a simpler approach for figuring out additional whitespace if you have have access to layout when calculating the name (this came up in discussions for an ACT Rule for label in name).

Just check whether there's a gap between the right and left sides of the content boxes for two sibling elements:

<!-- visual label: "Once upon a time" (no gap between sides of span content boxes - no space added) -->
<p><span style="font-weight:bold">O</span><span>nce upon a time</span>

<!-- visual label: "4 Services delayed" (4px gap between sides of span content boxes, space added) -->
<p><span style="font-weight:bold; padding-right:4px;">4</span><span>Services delayed</span>

This approach is independent of how the CSS layout and white-space processing actually works - it just uses the position of elements as laid out by the browser to determine whether to add a space. That means it should also work for more complex layouts like floated elements or grids - don't add a space if the content boxes for floating/grid elements don't have a gap between them.