PR Checklist

• [x] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
  • This feature is not documented.
• [N/A] If applicable, have a visual design approval

PR Type

Remove undocumented feature.

What is the current behavior?

Various components use custom focus trap functionality, and this custom functionality is exported by the library.

What is the new behavior?

Various components use focus trap functionality from @angular/cdk, and the custom functionality is removed.

Does this PR introduce a breaking change?

Yes.

• The @angular/cdk package is now a required peer dependency.
• The clrFocusTrap directive has been removed. Please use the cdkTrapFocus directive from @angular/cdk instead.

fixes VPAT-3637

PR Type Feature - Accessibility

What is the current behavior? The currently selected date is not indicated to screen reader users.

What is the new behavior? The aria-label of the day is now showing the word "Selected".

Does this PR introduce a breaking change? No.

PR Checklist

Please check if your PR fulfills the following requirements:

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [x] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

Summary

Column customization in datagrids is a desired functionality by many customers. Currently Clarity provides such functionality through Column Selector, positioned in bottom left corner, yet many users don't recognize it as an actionable icon - some say it looks disabled, others don't even notice it.

Visually, Clarity Column Selector needs to be improved so that it looks like an action and gets noticed by users.

Use case

For large datagrids with many columns, customers need a way to manage the datagrid information that they're seeing. Many customers are unaware that such functionality exists and are frustrated that they cannot reduce the number of columns they're seeing.

User quotes: "the column selector is less obvious, you know, it took me a while to notice it and start use it.."

"So the different columns that are available, it would be nice to be able to customize the view, have potentially more items or be able to reduce the number of columns."

"but as we add more information, that's available, the ability to show and hide columns could be useful."

"It's just, as you say, you've got different, different columns there. One thing is it, would it be possible at all to choose which columns are displayed"

"So again, I would like to be able to choose it as a field, to be obviously hidden or displayed. "

"So I think it would be nice to have, and then obviously give us the option of being able to select that as being viewable or not a column to appear or be hidden"

This is a bug report for the @clr Angular or UI versions of the design system. For the web-component implementation of Clarity (@cds), visit vmware-clarity/core.

Describe the bug

As of clr/angular v13 the <clr-alert> component does not honor the clrAlertClosed attribute if the clrAlertClosable attribute is set to false

This prevents any alert that was open to be closed programmatically via the clrAlertClosed attribute

How to reproduce

Stackblitz reproduction: ( https://stackblitz.com/edit/clarity-dark-theme-clr13-cds6-aepmqd?file=src/app/app.component.html )

Steps to reproduce the behavior:

1. Add a <clr-alert> to a page
2. Set the clrAlertClosable attribute to false
3. Programmatically set the clrAlertClosed attribute to true
4. Observe that the alert remains open. This is the bug.

Expected behavior

I expect to be able to programmatically close clr-alerts via the clrAlertClosed attribute regardless of the state of the clrAlertClosable attribute. Previous versions allowed this behavior.

According to documentation the clrAlertClosable attribute should only control whether the alert can be closed when clicking the close 'x'.

Versions

Clarity version:

• [ ] v12.x
• [x] v13.x
• [ ] Other:

Framework:

• [x] Angular
• [ ] React
• [ ] Vue
• [ ] Other:

Framework version: Angular 13

Device:

• Type: [Dell Laptop]
• OS: [Windows 10]
• Browser [chrome]
• Version [103.0.5060.134]

Describe the bug

Currently in our project we use Clarity UI 12 with CDS Core 6 as we want to utilise the theming capabilities of Core 6 with the variables shim without upgrading Angular and the Clarity components. The issue is that we need to have two dependencies - @cds/core 5 and 6 because @clr/ui 12 has a peer dependency @cds/core 5 which we don't use.

Expected behavior

@clr/ui@12 should have a peer dependency @cds/core@>=5 since CDS Core is aiming to have backwards compatibility with older versions of @clr/ui.

Versions

Clarity version:

• [x] v12.x
• [x] v13.x
• [ ] Other:

Framework:

• [x] Angular
• [ ] React
• [ ] Vue
• [ ] Other:

Framework version: Angular 12

Device: Any

PR Checklist

Please check if your PR fulfills the following requirements:

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [x] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

Angular Wizard component shows vertical scroll bars. The issue is reproducible by using link from the documentation: https://angular.clarity.design/documentation/wizards#examples. Seems to be reproducible in Windows environment only. Mac OSX works fine.

Windows (Chrome): MacOSX (Chrome):

It is recommended to add controllable down arrow (left arrow) to clr vertical nav group component.

For example: <cds-icon *ngIf="hasChildren" shape="angle" class="nav-group-trigger-icon" [attr.direction]="expanded ? 'down' : 'right'" [attr.title]="expanded ? commonStrings.keys.collapse : commonStrings.keys.expand" >

PR Checklist

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

Refactoring (no functional changes, no api changes)

Other information

Entry components do not to be specified for libraries built with Ivy.

Just started with another PR and saw that there is a small error in the docs/CONTRIBUTING_DEVELOPMENT.md file.

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)
• [ ] If applicable, have a visual design approval

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [X] Documentation content changes
• [ ] Other... Please describe:

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

This fixes a regression that was introduced in #302.

PR Checklist

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

Bugfix

What is the current behavior?

The border between the column and the detail pane does not extend to the placeholder element below the rows.

What is the new behavior?

The border between the column and the detail pane extends to the placeholder element below the rows.

Does this PR introduce a breaking change?

No.

Summary

Requesting the creation of a custom drop-down component. This effort is intended to:

• Reduce the amount of misuse with the signpost and other Clarity components
• Reduce the count of questions, and maintenance & enhancement requests Clarity receives for currently misused components
• Establish a method in Clarity for solving similar problems where custom functionality is generally needed, but not at the expense of consistency

Key terms and concepts

Custom dropdown – A dropdown appearing component that allows for custom content to be injected into the area usually reserved for lists and menus in a more traditional dropdown.
Functional content – Collections of user interface controls aimed at facilitating the work or operation of one or more computer-based systems
Injection areas – Designated areas inside a component that enable product developers to inject their own functional content into a component.

Motivation

Custom Dropdowns are a generally accepted, and frequently utilized building block that is missing in the Clarity library. This is causing other components, such as the signpost, to be misused. This has led to additional complexity for misused components, as well as additional support, maintenance, and enhancement pressure.

Goals

• Provide users with a purpose-built component to use when constructing unique drop-down-style controls for their products
• Support scale by providing flexibility for multiple sizes and configurations of functional content withing the custom areas of the component

Future Goals

• Reduce misuse of the signpost
• The component should define injection areas, allowing consumers to more easily customize the base component to fit their needs, without putting undue burden on Clarity development.
• Injection areas should be defined, and contain a set of default controls relating to the area’s definition. Example: A filtering area with default filter UI.
• Injection areas should be approached like a “space plan” for custom content, where the spaces are defined, potentially with default elements, but can be used for other purposes as long as there is alignment with the defined use of the space.
• Provide guidance around acceptable content to be injected inside a custom dropdown, both through the component, and documentation.

Non-Goals

• Filtering functionality, or anything internal to the ”custom” part of the component

Problem statements

1. The only way to provide functional content in a mode, is inside a signpost or components that would be undesirable from UI perspective.
2. Designers frequently solve for product users' needs via drop-down-like components. Scenarios like filtering, view management, and complex selection all suggest this approach as a possible solution, but the onus falls on the designer to ensure that their design execution is consistent and fits the needs of other products with the same need. This typically doesn’t happen, resulting in multiple variations of similar functionality.
3. Developers looking to meet their UX team’s front-end requirements regularly employ a mix of different methods in order to accomplish these desired UIs. This typically involves leveraging a mix of techniques and components, as nothing exists specifically in Clarity to support this need.

Please feel free to contact myself or @lerch015 for additional information.

PR Checklist

• [x] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

Bugfix

What is the current behavior?

The tooltip content was hidden as soon as the user moused out of the trigger.

Issue Number: VPAT-617

What is the new behavior?

The tooltip content will stay visible if the user mouses from the trigger into the content. To support this, the tooltip content has an expanded hover target provided by the ::after pseudo element.

Does this PR introduce a breaking change?

No.

PR Checklist

• [N/A] Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features)
• [N/A] If applicable, have a visual design approval

PR Type

Bugfix

What is the current behavior?

The tree node content is not a label for the checkbox; therefore, it is not included in the checkbox's click target.

Issue Number: VPAT-791

What is the new behavior?

The tree node content is rendered in the checkbox's label; therefore, it is included in the checkbox's click target.

Does this PR introduce a breaking change?

Technically, yes. The internal DOM structure of the tree node component has been changed. The .clr-treenode-content element is no longer rendered for selectable tree nodes; instead, the tree node content is rendered inside the checkbox's label element.

PR Checklist

• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)
  • https://github.com/vmware-clarity/website/pull/58
• [N/A] If applicable, have a visual design approval

PR Type

Remove unnecessary code.

What is the current behavior?

The datepickerToggle exists and is only used as a fallback.

What is the new behavior?

The datepickerToggleChooseDateLabel and datepickerToggleChangeDateLabel strings should be used instead.

Does this PR introduce a breaking change?

Yes. The datepickerToggle common string property was removed. Use datepickerToggleChooseDateLabel and datepickerToggleChangeDateLabel instead.

Hi, please add these icons to the travel set whenever you see fit: https://www.figma.com/file/XPDArdkICmAkUeCXCYaplS/Clarity-Icons-3.0.0?node-id=0%3A5876&t=bLGfEkMty8G3giNZ-0

Thanks in advance!