Repository navigation
Components: Add Avatar and AvatarGroup private components #75591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
a05171d
cb920cf
d24b8a5
f16792c
7d77380
7d32734
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Remove built-in `.is-active` status override; all statuses now get
uniform dimming so the consumer controls differentiation via the
dynamic `is-{status}` class.
- Preserve Tooltip on badge avatars when `label` differs from `name`,
so hovering reveals the full name even when the badge shows a
contextual label like "You".
- Replace `cloneElement` z-index injection in AvatarGroup with a CSS
`@for` loop on `:nth-child`, removing the legacy React API and its
type assertion.
- Add `role="group"` to AvatarGroup for screen reader context;
consumers provide `aria-label` via props.
- Add `aria-label` to the overflow indicator so "+2" reads as
"2 more".
- Add MixedBadgeAndTooltip story covering badge, tooltip, and label
combinations in a group.
- Improve JSDoc: clarify `badge` requires `name`, describe `status`
as an open-ended styling hook.
- Add CHANGELOG entry.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,7 +20,7 @@ export type AvatarProps = { | |
| label?: string; | ||
| /** | ||
| * Whether to show the hover-expand badge that reveals the user's | ||
| * name (or `label`) on hover. | ||
| * name (or `label`) on hover. Requires `name` to be set. | ||
| * | ||
| * @default false | ||
| */ | ||
|
|
@@ -38,15 +38,13 @@ export type AvatarProps = { | |
| * CSS color value for an accent border ring around the avatar. | ||
| * | ||
| * When not provided, no border is rendered and the hover badge | ||
| * uses the admin theme color as its background. | ||
| * and avatar status uses the admin theme color as its background. | ||
| */ | ||
| borderColor?: string; | ||
|
Comment on lines
+42
to
+48
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting to think how we might want to think about token usage here rather than hard-coded values. In other places we've expressly moved away from supporting hard-coded values in favor of tokens (example). Although in how this is used in real-time collaboration with a bunch of different colors for each collaborator, I'm not sure we can really tokenize this as-is, without either baking in tokens for complementary colors (like what you're exploring in #74875), or wrapping every
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, ideally this is locked to tokens, but realistically I think it needs to support arbitrary colors. Especially since different uses might need to generate their own colors. If we could provide a method for doing that from the theme package we might be able to tighten that up. But until then it probably needs to accept hex values. |
||
| /** | ||
| * The current status of the user. When set, the avatar image is | ||
| * dimmed to indicate a non-default state. | ||
| * | ||
| * - `'active'`: 20% image opacity (e.g. typing, editing). | ||
| * - `'idle'`: 30% image opacity (e.g. session timeout). | ||
| * A status string applied to the avatar. When set, the image is | ||
| * dimmed to indicate a non-default state. A corresponding | ||
| * `is-{status}` class is added for custom styling. | ||
| */ | ||
| status?: string; | ||
| /** | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering about alignment between these props and how we think of the
labelprop inIconButton, where we intentionally try to discourage mismatch between the accessible name and the tooltip content, though I think the use-case of something like "You" is interesting to consider, and feels similar in purpose to the sort of suffixing that was implemented inIconButton's shortcut support (e.g. maybe still deriving tooltip from name, but allowing the option for additional suffixing detail).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm happy to name things whatever y'all think is best. The intent was just to have one prop that provides the accessible name that's used for the tooltip and generating any fallback initials. This would be the "main" name or label or whatever. In addition to that I wanted to provide a secondary label/name/whatever to use contextually if we need to call a collaborator/user/entity something different. I can see this being useful when agents or other connected agentic things start appearing as collaborators. Instances where an entities exact name is less important than the role they're playing in the given situation. Happy to align that with how the button or other components handle that difference in meaning.