<app-info-tip> is the small info “?” you place beside a field label to explain a term without cluttering the form. On hover or focus it reveals a viewport-aware popover; the library owns the button, the positioning, and the hover/focus dismiss — you supply only the content and its label.
Its look comes entirely from the shared @webority/theme, so the Razor <app-info-tip> and the React <AppInfoTip> render identically on every Webority surface. The content is always the caller's — an app that backs the tip with a glossary wraps this and passes the looked-up entry; the glossary never enters the shared library.
Playground
Every attribute, live. Clear both label and content to see the tip render nothing — the markup underneath is the exact call that produced it.
Neither attribute → renders nothingWith no label and no content, the tag helper suppresses its output entirely — a glossary miss simply hides the tip rather than showing an empty popover.
Beside a label
The tip sits inline, right after the label text. Hover or focus the “?” to open the popover; it flips above/below to stay in view.
A tip next to a field label
The button carries a label announced to screen readers; the content fills the popover.
Risk tolerance
Show code
<span class="label d-inline-flex align-items-center gap-1">
Risk tolerance
<app-info-tip label="What is risk tolerance?">
The maximum acceptable annual loss probability under IEC 62305. Values above this threshold require additional protection measures.
</app-info-tip>
</span>
Behaviour is handled for youOpening, viewport-edge flipping, and dismiss on pointer-leave / blur all come from the component. It renders nothing at all when there is no content — so a missing glossary entry simply hides the tip rather than showing an empty popover.
Rich content
The content is any short block — a sentence, a short list, an inline code reference. Keep it brief: a tip explains, it doesn’t document.
A tip explaining a formula
Collection area
Show code
<span class="label d-inline-flex align-items-center gap-1">
Collection area
<app-info-tip label="How is collection area computed?">
The equivalent ground area (m²) that attracts the same number of strikes as the structure — derived from its length, width, and height.
</app-info-tip>
</span>
Title, body, or both
Pass a label for the popover heading, content for its body, or both. With only one, the popover adapts — a heading-only or a body-only card. A body-only tip still gets an accessible trigger name.
Each combination
Left: heading + body. Middle: heading only. Right: body only.
By default the popover opens with auto — it picks the side with room and flips to stay in view. Pin it to a side with placement: top, bottom, left, or right.
Open on any side
Hover each “?” to see where its popover opens.
TopBottomLeftRight
Show code
<app-info-tip label="Top" placement="top">Opens above.</app-info-tip>
<app-info-tip label="Bottom" placement="bottom">Opens below.</app-info-tip>
<app-info-tip label="Left" placement="left">Opens to the left.</app-info-tip>
<app-info-tip label="Right" placement="right">Opens to the right.</app-info-tip>
Width
width sets how wide the card may grow before its text wraps: sm (220px), md (276px, the default), lg (360px) or xl (480px). It is a maximum, so a short tip stays as narrow as its text.
Four widths, same text
Hover each “?”. The same long explanation wraps at each width.
A field label uses a term the user may not know and you want an on-demand explanation.
The help is secondary — useful, but not something every user needs to read.
You want accessible hover/focus behaviour without wiring a tooltip yourself.
Reach for something else when
The message must be seen by everyone, persistently, in context. → AppAlert
It is a permanent hint under a field the user should always read. → the hint prop on AppInput
You would otherwise expose the text via a native title="". → AppInfoTip
It is a brief, transient confirmation after an action. → toast
Best practices
Do
Risk tolerance
Give the tip a descriptive label (a real question) so it’s clear what the “?” explains, and keep the body to a sentence.
Don't
Risk tolerance
A vague "info" label and a wall of text overload a tip — move long explanations into a linked doc.
Do
Collection area
Attach the tip to the exact term it explains, inline with the label — the “?” sits where the question arises.
Don't
Collection area
Burying the explanation elsewhere (or omitting it) forces the user to leave the field to understand it.
Every option
The whole surface of the component, one cell per value — placement, every title/body combination, and the edge cases a normal example doesn't show.
placement — all five
placement="auto"
Label
placement="top"
Label
placement="bottom"
Label
placement="left"
Label
placement="right"
Label
title / body combinations
label + content
label only (heading, no body)
content only (body, generic trigger name)
neither (suppresses output — nothing here)
content edge cases
long body — wraps rather than overflowing
rich markup content (not just plain text)
Attributes
Attribute
Type
Default
Description
label
string
—
Accessible name for the “?” trigger, and the popover heading (data-bs-title). Omit for a body-only tip (falls back to "More information" as the accessible name).
placement
auto | top | bottom | left | right
auto
Where the popover opens; auto flips it to stay in view (data-bs-placement).
width
sm | md | lg | xl
md
The widest the card grows before its text wraps: 220, 276, 360 or 480px. A maximum, so a short tip stays as narrow as its text.
(content)
markup
—
The popover body — same as React's children. Omit for a heading-only tip. With neither label nor content, the tag helper suppresses its output.