Available since v0.1.0

[focused=true|false]

Stable

Checks whether the element currently holds document focus. Implemented as document.activeElement === element.

Syntax

fs-assert-<type>="<selector>[focused=true]"
fs-assert-<type>="<selector>[focused=false]"

When to use it

  • Reveal-and-focus flows where an input should auto-focus after a modal opens
  • Keyboard navigation verification — "after Tab, focus should land on the next input"
  • Confirming focus moves correctly after a toast dismiss or modal close

Example — auto-focus on modal open

<button
  fs-assert="search/open-modal"
  fs-trigger="click"
  fs-assert-visible=".search-modal .search-input[focused=true]">
  Search
</button>

Passes when the search modal is visible AND the search input inside it has focus.

Semantics

  • Point-in-time check. The modifier reads document.activeElement at the moment of evaluation. It does not listen to focus events.
  • A single focus at a time. focused=true can only be true for one element per document.
  • IFrames have their own active elements. Focus inside an iframe means the iframe is the active element from the parent document's perspective.

Pairs well with

Gotchas

  • Focus races with assertion timing. In frameworks that insert an element and focus it in separate microtasks, the assertion may run between the two. Use fs-assert-updated or a small timeout to give the focus call a chance to land.
  • .focus() called on a non-focusable element is a no-op. Divs and spans without tabindex can't hold focus. The assertion will silently fail.
  • Browser quirks on dynamic insertion. autofocus on elements inserted after initial page load is unreliable. Some browsers honor it, some don't. Call .focus() explicitly if the contract matters. See HTMX framework notes for the swapped-input pattern.

See also