Add API investigation details to tooltip spec

[m-akinc]

Pull Request

🤨 Rationale

There are some open design decisions that need to be addressed before the tooltip is ready for general use. This spec update attempts to resolve those issues.

👩‍💻 Implementation

See spec.

🧪 Testing

N/A

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[rajsite]

Spec does not have any discussion of alternatives. May want to have a meeting to brainstorm api options if have not had previous discussions.

[mollykreis]

Prior art seems like the wrong section title here. Maybe something like Existing APIs or Example APIs or even very explicitly APIs from other design systems.

[mollykreis]

The other con we were going to list here was that there we didn't get any accessibility benefits for free with this approach (i.e. we shouldn't automatically make the tooltip describe the anchor element).

[mollykreis]

It might be worth noting here that it isn't just "rich tooltip content" that isn't supported -- we also lose support for tooltip icons & severity. Or, to keep support, you'd have to have a tooltip attribute plus additional attributes for configuration of the tooltip (e.g. tooltip-severity and tooltip-icon-visible).

[rajsite]

As we discussed we have added slots to elements without forking templates, for examples the text field:

nimble/packages/nimble-components/src/text-field/index.ts

Lines 59 to 68 in b39cac6

	end: html<TextField>`
	<${DesignSystem.tagFor(IconExclamationMark)}
	severity="error"
	class="error-icon"
	></${DesignSystem.tagFor(IconExclamationMark)}>
	<span part="actions">
	<slot name="actions"></slot>
	</span>
	${errorTextTemplate}
	`

So I'm not sold on the assertion that every template must be forked for us to add new slots to our components, even today.

Tooltip implementation leaks into every other component.

I'm not exactly sure what are the cons this statement is trying to express. We call having a start slot that supports an icon a feature not a leak of icon implementation into components. Is there some concern this is expressing?

Suggested change

	- Expensive to implement and maintain. <span style="color:red">**Requires forking and modifying the template of every component that wants to support a tooltip.**</span> (Though code duplication could be avoided by using shared template fragments.) Tooltip implementation leaks into every other component.
	- Requires per element modification to add new tooltip slots. While we have added new slots to existing elements, there may be situations where it is required to fork a template to support adding a tooltip slot. The exact cost would need prototyping / investigation.

[rajsite]

Based on the other discussion I'm actually a bit more convinced that while still per-component work, we could implement this pattern today with just a slightly less optimal pattern by dynamically inserting slots into templates.

[rajsite]

I'm not sure this is true. We can easily add new attributes to controls and make shared patterns for adding attributes. It's also very possible that we don't necessitate a template change in tooltip logic. The tooltip logic could be very standalone, ie register listeners on elements in the template and show the tooltip dynamically (document.createElement the tooltip and insert it).

[rajsite]

I'll mention it in one spot but please remove the html style formatting with <span style="color:red">. It doesn't render on GitHub and makes the markdown harder to read.

[rajsite]

I think "proven" is a strong assertion, I'd be interested in knowing if those design system authors and their users actually prefer that pattern and if so how they came to that design.

Suggested change

	- Proven pattern: used by Carbon and Atlassian Design Systems
	- Pattern used by Carbon and Atlassian Design Systems

[rajsite]

Suggested change

	- Proven pattern: used by Adobe Spectrum Design System
	- Pattern used by Adobe Spectrum Design System

[rajsite]

It's only "reasonable" compared to the previous example

Suggested change

	- Reasonable DOM structure, i.e. tooltip sibling of anchor element
	- Elements as siblings is less counter-intuitive than the "Tooltip takes anchor element as content" example.

[rajsite]

I think we need an interactions / UX discussion on mobile and touch compatibility of tooltips as well as keyboard accessibility of tooltips.

[rajsite]

@m-akinc if this is not being actively worked on can you switch to draft?

[rajsite]

@m-akinc this issue has not been active for about a month, closing, can be re-opened to address concerns