Update selectors used by feature tour steps to be explicit
- Dominant language
- JavaScript
- Stars
- 1.4k
- Forks
- 383
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 80
Description
## Feature Description
Feature (and other) tours use selector strings to identify the `target` of each step. Until now, these have used existing class names that are often also used for CSS styles. This can make it easy to break the step targeting for the tour unintentionally if that class is later changed or removed for other reasons. To avoid this, we should use a kind of tour-specific selector to decouple the behavioral targeting from presentational concerns.
---------------
_Do not alter or remove anything below. The following sections will be managed by moderators only._
## Acceptance criteria
* Each feature tour step and tooltip finds its target through a selector that exists only for tour targeting, not a CSS class used for styling, so renaming or removing a styling class doesn't change or break what it points to. This covers both the element a step highlights and the element its tooltip points to.
* This applies to every tour and tooltip that points at a Site Kit element:
* The welcome tour, in both the Analytics-connected and the Search Console-only variant.
* The shared key metrics tour.
* The Site Goals tour.
* The tooltip shown from the welcome modal, and the email reporting setup tooltip.
* A tooltip that points at the WordPress admin menu keeps its current selector, since Site Kit doesn't render that menu and can't add a tour selector to it.
* Every tour and tooltip behaves exactly as it does now: the same steps in the same order, each highlighting the same element with the same text in the same place, at all screen sizes.
## Implementation Brief
*
### Test Coverage
*
## QA Brief
*
## Changelog entry
*
Contributor guide
Assessment
This issue has not been assessed yet.