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 https://github.com/w3c/accname/pull/168#discussion_r1458058588

[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