Source

Vanilla · debug profile

Rule resolution

Follow one matched element from an ordered rule list to its marker and activation behavior. The priority card matches both rules below, but the first matching rule owns it and produces exactly one marker.

Resolution pipeline

  1. SourceThe mounted source root defines the searchable document.
  2. Ordered selectorsRules are queried in their configured array order.
  3. First match ownsAn element found by an earlier rule is not claimed again.
  4. LabelThe owning rule computes the label during synchronization.
  5. MarkerOne marker record is created for the owned element.
  6. ActivationActivating the marker starts built-in behavior.
  7. Scroll targetThe scroll resolver selects a nested destination.
  8. Focus targetThe focus resolver reads the current application mode.
  9. Built-insCore scrolls first and then moves focus without scrolling again.
  10. Application eventmarker:activate runs after both built-ins.

Ordered rules

Rule order is priority order. The first matching rule owns an element. Both selectors match the priority card, so Rule 0 wins; Rule 1 remains the fallback for every other card.

Rule 0 · higher priority

.rule-card[data-priority="high"]

Label: Priority · <title>

Rule 1 · fallback

.rule-card

Label: <title>

When each function runs

Extension point Timing Responsibility
label(element) During synchronization Returns the marker label from current source content.
scroll.target(element) During activation Returns the element Core should bring into view.
focus.target(element) During activation, after scrolling Returns the element Core should focus.
marker:activate After built-in activation behavior Applies application-owned state and reports the public payload.

Resolver functions are synchronous computations, not lifecycle callbacks. They may read the matched element, its descendants, and current application state, but should remain inexpensive, side-effect free, and synchronous.

Try the lifecycle

Its computed marker label will update through normal mutation observation.

Focus target for the next activation

Primary action selected.

Last public activation payload

Activate a marker to inspect its owner and the completed focus behavior.

Source title
None
Selector
None
Rule index
None
Resolved label
None
Focus state
None

Review queue

Use the rail to navigate these six static cards. Marker clustering is disabled for a direct comparison.

Normal item · Rule 1

Release readiness

Confirm the package metadata, generated declarations, and consumer-facing examples before creating a release candidate.

This card matches only the fallback rule, so Rule 1 owns its marker behavior.

Priority item · Rule 0

Blocking deployment

This card matches both rules. Rule 0 owns it because rule order is priority order.

Even with overlapping selectors, the resolution pipeline creates one marker for this source element.

Normal item · Rule 1

Accessibility review

Review keyboard order, visible focus, accessible names, live updates, and contrast in the completed interface.

The rename control changes this heading so normal mutation observation can recompute the marker label.

Normal item · Rule 1

Security approval

Check dependency provenance, browser-facing boundaries, and the assumptions made by public integration surfaces.

Its nested header, rather than the whole card, is the scroll destination resolved during activation.

Normal item · Rule 1

Performance budget

Compare representative synchronization and activation costs without placing instrumentation inside resolver functions.

Resolvers remain synchronous and side-effect free, while the application reacts through the public event.

Normal item · Rule 1

Documentation handoff

Capture the ordered rule contract and distinguish synchronization-time functions from activation-time functions.

The two action buttons make the current focus resolver choice visible without changing Tracker configuration.