giseldo/neodataset huggingface dataset:
Toggle > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the toggle component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Toast > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the toast component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Tabs > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the tabs component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Table > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the table component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Spinner > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the spinner component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Sorting > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the sorting component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Socks > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the socks component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Skeleton loader > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the skeleton loader component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Segmented control > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the segmented control component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Search > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the search component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Radio button > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the radio button component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Labels and linking

## Purpose

>>In this context, the text “Code owners” isn't explicit that it navigates to the code owners file, because it's also used as a label for the list of code owners of the current file.
> 
> @pedroms I think this is a great point and something we should evaluate — should a label be allowed to link? And how does visual label relate to `label` (which wouldn't necessarily make sense in this context)? At the moment this text only visually appears as a label, and nothing about it, other than the preceding ':' indicates as much, which is why I'm inclined to proceed.

Per the discussion in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117251#note_1353052885, this issue is to discuss the following:

- Should text that _appears_ as a label (although isn't actually a `label`) be allowed to link?
  - If yes, what link variant is most appropriate?

For example, the "Code owners" text in the following screenshot.

![CleanShot_2023-04-19_at_15.11.48_2x](/uploads/dadb264ad9c9ed05fe91fca0e7abd923/CleanShot_2023-04-19_at_15.11.48_2x.png)

## Next steps

- Document a decision in Pajamas.

Story points: 1.0
Add new design-focused section to Pajamas

## Purpose

Create a new section in the Pajamas website to house DesignOps content and make the UI kit documentation more visible and structured.

### Proposed structure

---

<small>**DesignOps**</small>

- Component lifecycle
- Pajamas UI Kit
  - _Sections from the current md file…_
  - Release notes

---

The content in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/doc/pajamas-ui-kit.md to this section to break it out into sub pages, make it available in Pajamas search, and have better formatting for visuals.

Story points: 2.0
Link > Finalise design specs

Issue to track efforts to finalise the design specs for links

# Proposed link styles

The following documents the intention, rather than the prescription for the actual CSS to be used.

Class names placeholder to make it easier to read.

There are certainly better ways to achieve the same thing.

[Play with the styles in context in this codepen](https://codepen.io/danmh/pen/rNZGKbm).

```scss

// Inline links assumed the default

a {
  color: $blue-700;
  text-decoration: underline;
  text-decoration-color: rgba($blue-700, .72);   // allows underline tone to match background
  text-underline-offset: 2px;                    // we should make this a relative value, 
                                                 // as it breaks when the browser font size is changed 
  transition: background-color 100ms linear, color 100ms linear,
               border 100ms linear, text-decoration-color 100ms linear; 
                                                 // builds on existing link transition styles, adds text-decoration-color
  
  &:hover {
    color: $blue-800;
    text-decoration: underline !important;       // allows other link types to have underline on hover
                                                 // even if they have text-decoration: none for the rest state
    text-decoration-color: currentColor;
  }
  
  &:focus-visible {
    color: $blue-800;
    text-decoration: underline !important;
    text-decoration-color: currentColor;
    outline: 2px solid #428fdc;   // existing focus styles
    outline-offset: 2px;          // existing focus styles
  }
  
  &:active {
    color: $blue-900;
    text-decoration: underline;
    text-decoration-color: currentColor;
    transition: none;             // makes the click or press feel snappy
  }
}

a.ui-link {
  text-decoration: none;          // no underline in rest state
}

a.meta-link {
  text-decoration: none;
  
  &.meta-link-dark {
    color: $grey-900;
    &:hover {color: $grey-950;}
    &:active {color: $black;}
  }
  
  &.meta-link-subdued {
    color: $grey-700;
    &:hover {color: $grey-800;}
    &:active {color: $grey-900;}
  }
}

a.mention {
  padding: 0 2px;                // these are no change from existing styles
  background-color: $blue-100;
  border-radius: 4px;
  text-decoration: none;
  
  &.mention-current {
    background-color: $orange-100;
  }
}
```

## Rational

Why blue-700  
Why opacity  
Why underline at all  
etc  
etc

### Next

- [ ] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1551+

### Unblocks

- [ ] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/880+
- [ ] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1217+
- [ ] https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1084+
- [ ] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1536+
- [ ] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1554+


### Related to

- https://gitlab.com/gitlab-org/gitlab/-/issues/336819+

Story points: 2.0
Add structure visual and list. for link

### Description

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

Add link structure diagram

Related to: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1444+

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [~] When applicable, [create an issue using the `Figma update` issue template][pajamas-figma-update-template] to update the component in Figma, and mark it as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
1. [~] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a GitLab UI issue using the `Component` issue template][gitlab-ui-component-template]. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [~] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Component Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 1.0
Breadcrumb component updates

# Breadcrumb

The breadcrumb is a component that is less isolated than other components because it’s navigation based on the page it’s within, and is bound by the layout and behavior constructs of that page along with other content and functionality.

Updates to the breadcrumb can’t happen without considering the impact to its own UX, and to the UX of the page in which it’s placed. For that reason, there are two parallel categories of considerations that have to be addressed: component-specific, and the relationship with other elements.

## Component-specific

<details><summary>View details</summary>

- Responsive - Wrapping and truncation
	- Truncation based on width or character count? Both?
	- Where truncation occurs in the string?
	- At wider views, should we allow larger strings to be expanded, potentially creating an unwieldy string in primary real estate? 
- States
	- Interactive states, such as hover and focus
	- Current page state
- Design spec updates (border, separator, states, etc.)
- Semantics and [accessibility updates](https://gitlab.com/groups/gitlab-org/-/epics/6879) for current implementation
- Migration

**Deliverables:**

- [Updated design specs](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1533)
- Updated Pajamas documentation
- Component updates in GitLab UI
- Component migration

</details>

## Relationship with other elements

<details><summary>View details</summary>

- **[Navigation](https://gitlab.com/gitlab-org/gitlab-ui/-/issues/2141) — specifically the sidebar show/hide icon placement and behavior (priority)**
- DOM order with other elements, like alerts, banners, and broadcast messages
- Within [headers](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/3263)
	- Sticky behavior
	- Page actions
- Fluid and fixed width layout settings

**Deliverables:**

- **Navigation + breadcrumb requirements and specs (priority)**
- Identify and document potential patterns that use a breadcrumb
- Updated Pajamas documentation

</details>

## Resources

- [A collection of 40+ breadcrumb components from various design systems](https://arc.net/e/F3F0AA49-51B1-4254-BD21-A450640C83E1)
- [Pajamas > Breadcrumb](https://design.gitlab.com/components/breadcrumb)
- [GitLab UI > Breadcrumb](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-breadcrumb--default)

Story points: 5.0
Dropdown > Document height options

### Description

Document height options (fit contents height vs. fixed height). There are use cases where we want the dropdown to shrink to it's content (fit contents) and others where we want to keep its initial height (fixed height).

| Contents size | Keep initial height |
| ------ | ------ |
| ![image](/uploads/79f6e6c264a0dce355312c72599dc237/image.png) | ![image](/uploads/d3d6b212f69cc7da039ccde5184051cc/image.png) |

### Checklist

Make sure the following are completed before closing the issue:

1. [X] Assign the correct component label to this issue.
1. [ ] Create an MR with the additions or updates needed.
1. [ ] When applicable, [create an issue using the `Figma update` issue template][pajamas-figma-update-template] to update the component in Figma, and mark it as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
1. [ ] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a GitLab UI issue using the `Component` issue template][gitlab-ui-component-template]. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Component Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 1.0
Dropdown > Update design spec to include min/max width

## Purpose

Based on the implementation plan in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1507#implementation-plan, the **dropdown** design specs should be updated to include the recommended minimum and maximum widths.

This doesn't have to be a component setting, but that is an option if the configuration is easy enough to implement and the design experience isn't impacted.

## Specs

Make dropdown's width more flexible:

* [x] min-width: 16rem (256px)
* [x] max-width: 28.5rem (456px)
* [x] max-height: 19.5rem (312px)

Story points: 2.0
Dropdown > Direction for rendering overflowing, non-wrapping text within items

In some cases, we might need to display long non-wrapping texts within a dropdown's items. For example, the notification settings display the user's emails, which might overflow the dropdown menu:

![Screenshot_2023-01-03_at_8.41.24_AM](/uploads/5ca3d1a413d52a539ce89f18ad5e5e4e/Screenshot_2023-01-03_at_8.41.24_AM.png)

## Implementation plan

- [ ] `GlTruncate`: ensure the rendered element has an accessible `aria-label` attribute.
- [ ] `GlCollapsibleListbox`
  - [ ] Make dropdown's width more flexible:
    - [ ] `min-width: 15rem`
    - [ ] `max-width: 28.5rem`
  - [ ] Leverage `GlTruncate` to truncate long items' names. This should be probably be the consumer's responsibility, so this can be a recommendation in the docs.
- [ ] Ensure the notifications settings render properly as per https://gitlab.com/gitlab-org/gitlab/-/issues/373843#note_1227467886.

Story points: 2.0
Button > Add note about icon indicating action

## Purpose

Icon only buttons shouldn't act as a toggle where the icon might change depending on state. For example, ![eye.svg](/uploads/8d7f9c533374ec1ef07ab58fcfbc184f/eye.svg) changing to ![eye-slash.svg](/uploads/c8cdb864cae90e67f1534b8d2f527f92/eye-slash.svg) on click because the state can be confusing. Does it mean that the current state is A and clicking goes to B, or the opposite?

This issue is to initiate documenting the recommendation.

Story points: 1.0
Update severity guides for errors

## Purpose

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/contents/usability/error-prevention.md?plain=1#L13 there's reference to old button content that can be updated. Along with the the entire section will reviewed to make sure it's accurate.

>The destructive action can easily be undone and no actual data was lost. Consider adding no friction at all in order to streamline the interface, especially in places where the action needs to be performed in bulk. These kinds of destructive actions can be exempt of being **[elementary](/components/button/#elementary) styled and can instead be [neutral](/components/button/#neutral) styled buttons.** (Emphasis added)

Story points: 1.0
Pajamas navigation refinements

## Purpose

A followup from #1443 to further refine the navigation with the following:

- Update the Pajamas lockup and ensure a common left edge (alignment) for all elements.
- Ability to expand multiple sections at once. This is a common accordion-like pattern that would allow a user to compare the options in different sections. While this UX might not be ideal for some sites, it can be a benefit for a user of Pajamas to get a better understanding why there are **Form elements** in one section, and **Forms** in another.
- Sticky expanded sections. Since some sections (like **Components**) are quite long, having the parent category item sticky when expanded can help a user maintain context for the current section they're navigating.
- Update design of search to be more integrated into the sidebar (inspired by the recent update to the dropdown design).

| **Before** | **After** |
| ------ | ------ |
| ![CleanShot_2022-11-15_at_15.27.07_2x](/uploads/8301cb427469b78bf66e01a215e5c87f/CleanShot_2022-11-15_at_15.27.07_2x.png) | ![image](/uploads/8f6ee6079020c5cc846a22404d1bfb37/image.png) |

[![Figmacon.svg](/uploads/45f9a446f4122aef0e50b97cb651f039/Figmacon.svg) View the working file in Figma →](https://www.figma.com/file/qYQOk3DhrswWIsRnoUTJ6J/%231378-Pajamas-IA-JE?node-id=708%3A4482&t=TDoghMezobgvIbnA-11)

**Note:** The _before_ screenshot is from !3115's review app.

Story points: 3.0
Pajamas site mobile nav

## Purpose

As a followup to !3115 there are some additional improvements needed for the mobile navigation of the Pajamas website.

From https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/3115#note_1171724042:

> …move from a partial cover to a full-width/overlay menu to:
> 
> 1. Add a close button in correct focus order, potentially using a × icon
> 1. Remove overflow scroll of page content while menu is open (swipe moves content body not menu items)
> 1. Allow increase in touch targets in menu for mobile
> 1. Rethink ≡ overlapping page content on scroll

Story points: 3.0