feat(Chip): Add read-only, icon, badge variants; deprecate status label

[jmuzina]

Done

• Deprecates the Status Label component.
  • Updates usages of the status label component to use the readonly chip.
    • In examples
    • On the Vanilla docs site
• Adds the following variants to the Chip component
  • Read-only (subsumes the Status Label component)
  • With icon
  • With badge

Fixes #5535
Fixes WD-22497

TODO

• Add design guidelines per design docs
• Add accessibility guidelines
• Fix excess whitespace introduced by the example helper macro

QA

• Open chip examples and verify they appear as expected
• Review chip docs
  • Make sure to check the "Design guidelines" and "Accessibility" (WIP) tabs, as these have been updated / added.
  • Disregard excess whitespace in the chip markup - this will be addressed prior to final QA review
• Review status label docs and verify they have been marked as deprecated properly, with a link to the read-only chip.
• Review 4.25.0 release notes
• Browse around the Vanilla website and verify that the status label has been replaced with the readonly chip in all non-deprecated pages.
  • Sitewide side navigation, on recently updated components
  • What's New
  • In variant headings

Check if PR is ready for release

If this PR contains Vanilla SCSS or macro code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention
  • if existing APIs (CSS classes & macro APIs) are not changed it can be a bugfix release (x.x.X)
  • if existing APIs (CSS classes & macro APIs) are changed/added/removed it should be a minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) or macros should be listed on the what's new page.

Screenshots

[webteam-app]

Demo

Jenkins

demos.haus

[jmuzina]

Hey @timea-udvarhelyi , some updates and questions for you:

1. I've updated the "Anatomy" through "Properties" sections of the design guidelines docs. The "Styling" section from the Google doc seems like it's not fully finished and I know there were some comments there about tokens, what should I do here? I'll add the "Accessibility" section after our talk tomorrow.

• Update: just saw the response you posted about this section just 5 minutes ago - I'll have a look more in detail tomorrow morning :)

3. Can you have a quick look at the chip examples and let me know if they look about as you would expect? This doesn't need to be as rigorous or in-depth as a proper, final design review - just want to know if I've properly captured the changes before I move this out of draft state. The new variants are at the bottom of the page.

[jmuzina]

Added a draft for how we might lay out the accessibility docs.

Also added a draft for the tokens docs section.

@timea-udvarhelyi

[jmuzina]

Opening for design review.

There are still some updates to the Design docs pending.

• @timea-udvarhelyi to check on whether we should deploy the site with the images that are currently in use for the "do/don't" examples
• @timea-udvarhelyi to double check if the colors used in the component anatomy screenshot are approved for publishing
• @timea-udvarhelyi To make some adjustments to the "Styling" section of the docs, consolidating layout and spacing.

@timea-udvarhelyi let me know if these are accomplishable soon - I'd like to merge and release this tomorrow ideally. If needed we can deliver the documentation separately from the chip updates.

[timea-udvarhelyi]

@jmuzina I updated the anatomy image and checked the examples, there are permitted to be published except for one that I have changed in the doc.

The correct colors are used in the Figma component as tokens.

The MVP for the Styling and Accessibility sections are ready. I would like your help reviewing the spacing color and responsiveness sections. But this should not be a blocker.

The anatomy section has also been updated to contain the mention of the dismissible icon subcomponent.

I reviewed the icon radius change, it looks good to me! +1 from visual review

[jmuzina]

Additional notes from @timea-udvarhelyi :

• Shrink the width of the "default chip" and "read-only" chip columns in the design guidelines docs
• Replace the image for "default chip -> when to use -> use for filtering" - it is wrong
• If possible, update the status label used in the docs navigation to use the read-only chip

[advl]

Approved, Q/Ad with comments to learn from for the future :

• The "one component fits-all" approach is dangerous as it forces merging disjoint semantic representations ; a span and a button are very different elements and should not be used equally to represent the same signifier;
• The subcomponents should also enforce a stricter approach - the dismissable chip, containing a button in a span, equally contradicts the fact that the chip itself could be a button. This ends up causing additional issues, such variations of the hover visual feedback and of the clickable zone.

Nothing new here under the sun, only an indication that we need to land better our concept of defining singular components :)
Next components should pass acceptance criteria defined together to avoid similar issues; also the chip in its current state should preferably not be ported to the new design system.

Thanks @timea-udvarhelyi and @jmuzina for the great work and I wish you a great week-end,

[jmuzina]

@timea-udvarhelyi while applying the read-only chip to the Vanilla website, I noticed an interesting point we should probably hash out here:

Currently, chips have 20px bottom margin and 8px right margin, to space them away from content that follows (i.e, placing multiple chips next to each other, such as in Search & Filter)

If the read-only chip had the same margin, it would cause unexpected spacing in contexts where it is inline (such as navigation or tables)

So, I've set the read-only chips to have no margin:

However, this means that a cluster of read-only chips in succession would be very close together.

Would multiple read-only chips ever be used in the same block?

[timea-udvarhelyi]

@jmuzina there are use cases where we will have multiple read-only chips next to each other, but as a default state for using the read-only chip it makes sense to remove the bottom and right margins, as for groups of chips - would it be a solution to wrap them in a container?

[lyubomir-popov]

@jmuzina we can redefine what u-no-margin--bottom does - doesn't have to be 0. For example, headings have a bit of marign bottom when the class is applied, to keep things on the baseline grid. Same trick could work here.

[jmuzina]

The inline chip spacing ended up being solvable by using the already existing .is-inline state of the chip pattern. I've added guidance that read-only chips in inline contexts should use the .is-inline class.

I also noticed that, with our current spacing settings, placing a non-dense chip inline with paragraph text causes the parent element to grow vertically due to the chip padding. This would cause, for example, side navigation items with non-dense chips to be taller than the others:

List item with a status chip

List item without a status chip

And table cells (and by extension, rows) to be taller than they need to be:

Default chip

Dense chip

I've found that this can be avoided by using the Dense chip - see that all items with the same line count are now the same height:

I haven't been instructed to change any spacing across VF, so I have documented the Chip to explain when to use .is-dense in inline contexts:

As far as I can tell, visual regressions have been corrected and documentation is fully updated - moving this out of draft state for another round of design review with these fixes.

[jmuzina]

is-dense usage in tables/sidenav validated by @lyubomir-popov in mattermost
progressing to code/QA/percy re-review: @advl could you have a look please ?

[Copilot]

Pull Request Overview

This PR deprecates the legacy Status Label pattern, replacing its usage with the new read-only Chip variant, and adds icon and badge support to Chips.

• Deprecate and remove Status Label; replace with read-only Chips in docs and templates
• Introduce icon and badge variants in the Chip component and update examples
• Update SCSS imports and mixins to support the expanded Chip functionality

Reviewed Changes

Copilot reviewed 46 out of 46 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
templates/docs/whats-new.html	Swapped <span class="p-status-label"> for <span class="p-chip is-readonly is-inline">
templates/docs/settings/placeholder-settings.md	Replaced deprecated status label with a read-only chip in table
templates/docs/settings/animation-settings.md	Converted manual status label to {{ status("deprecated") }}
templates/docs/patterns/strip/index.md	Removed status label but no replacement chip or status helper
templates/docs/patterns/status-labels/index.md	Added deprecation notice and link to read-only Chip
templates/docs/patterns/chip/index.md	Added read-only/icon/badge sections and updated import snippet
templates/_layouts/docs.html	Updated side-navigation status badges to use Chips
templates/_layouts/_status-label.html	Changed default status-label span to a Chip span
scss/_patterns_status-label.scss	Marked status-label component as deprecated
scss/_patterns_chip.scss	Enhanced Chip mixin with icon, badge, and read-only support

Comments suppressed due to low confidence (1)

templates/docs/patterns/chip/index.md:81

• The class is-read-only is inconsistent with the mixin and other templates, which use is-readonly. Rename to is-readonly for consistency.

To create a read-only chip, use `<span class="p-chip is-read-only">`.