giseldo/neodataset huggingface dataset:
Figma > Accordion use paragraph instead of labels style

Update text styles and address any layout regressions (will match GitLab UI).

| **Before** | **After** |
| ------ | ------ |
| ![image](/uploads/54da8cd9b4f6e8399c75d4c7d01fe1e4/image.png) | ![image](/uploads/a3e5f1efae318904ed0268d36cef599e/image.png) |

[View working branch in Figma →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/4ytND6X78TA9d8IPJGpYJv/%F0%9F%93%99-Component-library?node-id=425%3A0)

Story points: 1.0
Cleanup error page layout

The following discussions from !3050 should be addressed:

- [x] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/3050#note_1136458211): 

    > **nitpick(non-blocking):** We are repeating the `typography gl--flex-center gl-flex-direction-column gl-h-100vh` wrapper both here and in the `page-not-found` component. Perhaps we could de-duplicate this.

- [x] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/3050#note_1136458215): 

    > **thought(non-blocking):** We seem to be repeating a lot of code from the default layout here. I wonder if we could conditionally render the footer instead of creating a new layout, it would make things a bit easier to maintain.

- [x] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/3050#note_1136458218): 

    > **nitpick(non-blocking):** This might not be relevant in this layout since the homepage uses the default layout anyways.

Story points: 2.0
Pajamas Migration Day: December 2, 2022

As part of our ongoing [component migration push](https://gitlab-org.gitlab.io/frontend/epic-burndown-charts/fy23-q1/), we are hosting another Pajamas Migration Day!

- **When:** December 2, 2022
- **Who:** Everyone! FE, BE, Designers, Product, etc. Everyone is encouraged to contribute.
- **Where:** Your very own home or work space, but also join the `#pajamas_migration_day` slack channel to hang out and chat with fellow contributors!
- **Why:** We want to encourage a day of migrating legacy components / css to use Pajamas!
- **Bonus:** If you contribute three merge requests on Pajamas Migration Day, you can expense a meal for up to $25 USD! Please use the ~"Pajamas Migration Day" and ~"FY23::Q4" labels on your MRs to be eligible. In Expensify, use the `Meals Company Provided (Non-Client related)` category.

**Need help?** Ping any member of the [Foundations team](https://about.gitlab.com/company/team/?department=manage-foundations-team) for support or help throughout the day. We are here to assist!

## How to contribute

**If you are working on building your coding skills, check out these issues:**

- [HAML: Buttons](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Pajamas%20Migration%20Day&label_name%5B%5D=workflow%3A%3Aready%20for%20development&label_name%5B%5D=component%3Abutton&label_name%5B%5D=haml%20migration&first_page_size=20)
- [HAML: Cards](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Pajamas%20Migration%20Day&label_name%5B%5D=workflow%3A%3Aready%20for%20development&label_name%5B%5D=component%3Acard&label_name%5B%5D=haml%20migration&first_page_size=20)

**If you are confident in your coding skills, check out these issues:**

- [Dropdown migrations](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=opened&label_name%5B%5D=OKR&label_name%5B%5D=component%3Adropdown&assignee_id=None&first_page_size=20)
- [Remove select2 implementations](https://gitlab.com/groups/gitlab-org/-/epics/8738)
- [Extract Page Specific CSS Files](https://gitlab.com/groups/gitlab-org/-/epics/3694)

**Tip:** There does not need to be a specific issue open to contribute! Starting with MRs that migrate legacy code is a great way to contribute to the effort. If there are no issues to pick up, treat the day like a scavenger hunt!

**Reminder:** Please add the ~"Pajamas Migration Day" and ~"FY23::Q4" labels to your MRs, as well as the specific component label that relates to your change (for example: ~"component:alert")

Story points: 0.0
Update Pajamas navigation as a result of #1378

## Purpose

Update the Pajamas navigation (and related pages) based on conclusions and direction from the results of #1378.

## Scope

- Update the navigation structure.
- Update the navigation semantics to ensure accessibility.
- Update navigation design.

## Direction

[📐 Prototype →](https://codepen.io/lostsatellites/full/rNvbrao)

![image](/uploads/c0bd6960203d7acd0259db8fecc08e6d/image.png)

Story points: 3.0
Dropdown > Update docs to align with latest approach

## Purpose

As a next iteration we've discussed moving the listbox to a low-level component. What that means is that it isn't something to be used on it's own as an actual dropdown variant, but instead it's consumed by both the disclosure (optional) and combobox (required).

Likewise, it's been determined that the menu variant isn't something we'll proceed with for now since the disclosure can fir the use cases we have today in the product.

## Changes

- Place necessary listbox content within the [combobox](https://design.gitlab.com/components/dropdown-combobox) page.
- Deprecate the [listbox](https://design.gitlab.com/components/dropdown-listbox) page.
- From the [disclosure](https://design.gitlab.com/components/dropdown-disclosure) page, link to the new listbox section under combobox as the SSoT.
- Deprecate the [menu](https://design.gitlab.com/components/dropdown-menu) page.
- Consider adding decision trees in the _when to use_ section(s) to help determine what to use.

The above changes would leave us with only the disclosure and combobox dropdown variants. To avoid the use of a menu-like option, we could consider adding a line about what `role= menu` is and why we don't use it in both places.

Story points: 1.0
Disable Google Analytics (and therefore remove Cookie Banner) for design.gitlab.com

The cookie banner breaks stuff, see for example:

- https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1436
- https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/commit/15be27162585b06eb2d390cf0191890100a5622c

If we do not ship Google Analytics, we need no Cookie Banner, because we are not using Cookies otherwise.

Given that noone seems to have looked at Analytics in a while (at least when I asked), we should consider removing it and making our lives easier.

Story points: 1.0
Discovery > Look into possibilities of displaying ViewComponents in Pajamas

Now that we have [ViewComponents](https://gitlab.com/groups/gitlab-org/-/epics/8113), it would be great to get those displayed in Pajamas alongside the Vue components. 

As a first iteration, the `Implementation` tab could change to `Vue` and we could introduce a new tab per component called `View`.

One potential hurdle is that it needs to properly deployed to a Rails application, so we need to determine if this is possible or what options we have.

---

@thutterer 

> Prototype at https://gitlab.com/gitlab-org/frontend/playground/lookbook-app

Story points: 3.0
Add structure image for filter

[View working file in Figma (branch) →](https://www.figma.com/file/2XRq1MnIG69iti76Mh9HpJ/branch/X3R2AZyGx5IEAd2IqrMdTj/Pajamas-visual-examples?node-id=9981%3A21053)

Story points: 1.0
Introduce option to put selected items at top of dropdown

## Problem to solve

Without a dropdown pattern that shows the selected items at the top, I can't see what those selections are without a lot of scrolling in the dropdown. The truncation in the button suggests that there are more items, but how do I know what these are? Example from https://gitlab.com/gitlab-org/gitlab/-/issues/345430/designs/Runner_tag_field_states.png#note_1074738137:

<img src="/uploads/411cf209d509257ec56bdc8b8214ee2a/Screen_Shot_2022-08-23_at_2.08.30_PM.png" width="40%">

I'd have to scroll down through potentially hundreds of items to see what the `+2 more` refers to (and/or to unselect them). Sometimes the dropdown doesn't even show the complete list, which makes it impossible to find it unless I know what I'm looking for and can use the search to find it (and unselect it, for example). 

## Proposal

| 5 items | 6+ items creates a scrollable area |
| ------ | ------ |
| ![image](/uploads/a0519c2f232eda7f84a57b3205f35b41/image.png) | ![image](/uploads/6a4c06a5df719deb4aa02635991d0dac/image.png) |

In order to prevent the selection from moving around within the input, which could be a frustrating and disorienting experience, the selection should move _after_ the dropdown is closed so it's shown when it's re-opened. This is different than how it currently works in the Assignees dropdown.

Example: 

![Screen_Shot_2022-08-23_at_3.21.20_PM](/uploads/3d4f5b7fc9b869fa682dc694f9b5bad5/Screen_Shot_2022-08-23_at_3.21.20_PM.png)

As far as I can tell, this type of dropdown isn't available in [Pajamas](https://design.gitlab.com/components/dropdown-listbox), [gitlab-ui](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-dropdown--default), or the Figma library as a variant (only as an [instance](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/%F0%9F%93%99-Component-library?node-id=12053%3A6)).

Story points: 5.0
Typography scale(s) exploration

Update typography scale(s) and make use of them in GitLab UI & the product.

- Can we unify some of the scales?
- Build a new scale with variables so it can be optimised to different usecases
- Presenting type scales in GitLab UI and Pajamas
- Product integration
- Use base font size of 1rem (16px)
- Change font-sizes to rem (a11y)

Current scale: [GitLab UI](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/scss-typescale--default)

Figma WIP: [Component library →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/8eZJjsriZhPMHL7t1PoVJH/%F0%9F%93%99-Component-library?node-id=440%3A0&t=mKm3NIjPzREZn3q7-0)

Story points: 3.0
Inter typeface exploration

### Goal

Make Inter the new default font in GitLab UI & the product.

#### Steps
- Explore the use of Inter
- Variable font
- How we can roll this out
- Possible performance impacts
- Language support (i18n)
- Fallbacks

### Inter

![image](/uploads/f61bd34d79e9bffa1ae92dbc278b3752/image.png)

### Figma Test

[View branch in Figma →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/HIA8tpxKnRBR7bFP901AsS/%F0%9F%93%99-Component-library?node-id=440%3A0)

### Product Test

| Inter | system-ui in Mac OS (SF Pro) |
| ------ | ------ |
| ![inter](https://gitlab.com/groups/gitlab-org/gitlab-services/-/uploads/bcded4f9cfd68518969ffa3c69226a86/inter.png) | ![system-ui](https://gitlab.com/groups/gitlab-org/gitlab-services/-/uploads/5b8ca6e56c351b906107dcaae3854452/system-ui.png) |

Story points: 2.0
Define pattern for adding items to a list

### Background

Based on [the discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/368138#note_1037362165) with @mle, the improvement could be a community improvement.

So far, we only know that this Region exists in "Settings" and "Security Policy" if anyone knows where else we are using it, feel free to add.

cc: @gitlab-com/gitlab-ux/designers, Any suggestions or you notice the change won't work in certain area?

### Change Proposal

![select-approval-rule-region-improvement](/uploads/e5df095d660447cd3b0afa3a17de0a35/select-approval-rule-region-improvement.png)

Story points: 3.0
Typography > Note smallest recommended font size

## Purpose

Some instances of type are showing up that are smaller than the 12px allowed by the current type scales (UI type scale). 12px is a good minimum size and should be used in limited capacity for short meta-like copy and actions. There is no minimum mentioned in Pajamas (although it's implied by the type scale styles), and it'd be helpful to document.

There is subjectivity when it comes to font size and preference, but that's all the more reason to set a baseline and guidance. For example, browsers handle antialiasing differently and rendering "quality" will vary. GitLab makes use of system fonts, and some, like Helvetica, have tighter spacing and less character definition so that text is harder to read at small sizes. One user will not have the same eyesight as the next, so setting a minimum can also help remove subjectivity and preference for what should be the minimum size.

If content is worth displaying, then it should be worth displaying legibly.

### Considerations

- On mobile, if the font size of an input is not at least 16px, then input will be scaled up (at least in Safari).
- Typeface, font weight, color, line-height, measure, and style can all impact legibility.
- While WCAG doesn't prescribe a minimum font size, it does address contrast for type
- Pixels are referenced as the unit in this issue, but in code relative units should be used so that a user can scale the type in browser (using pixels prevents this). If a browser's default size is 16px (1rem), then 12px = 0.75rem.
- Screen resolution will impact legibility.

| **Helvetica, Firefox** | **Helvetica, Firefox, standard resolution** | **San Francisco, Firefox** |
| ------ | ------ | ------ |
| ![CleanShot_2022-08-03_at_08.59.44_2x](/uploads/b0b4cb53e2d29c3a6f4f530c3c5aff49/CleanShot_2022-08-03_at_08.59.44_2x.png) | ![CleanShot_2022-08-03_at_09.00.29_2x](/uploads/38dbe0873fa017a917fa562fb45356df/CleanShot_2022-08-03_at_09.00.29_2x.png) | ![CleanShot_2022-08-03_at_09.01.00_2x](/uploads/eb2235b1a554fb7e1de573d375e42b90/CleanShot_2022-08-03_at_09.01.00_2x.png) |

### Resources & reference

- Explore different type sizes and fonts in [CodePen](https://codepen.io/lostsatellites/pen/BarrNoE).
- https://stephaniewalter.design/blog/what-minimum-font-size-for-a-high-density-data-web-app-do-you-suggest/
- https://css-tricks.com/accessible-font-sizing-explained/

Story points: 1.0
FY23 Q3 Foundations KR3:  Identify opportunities to increase product designer efficiency in Figma. For example, component structure, libraries, internal plugins, etc

## Purpose

See [epic description](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/12).

## Steps

- [ ] Conduct a survey or host a synchronous brainstorming session to explore potential opportunities and workflows that would increase product designer efficiency in Figma.
- [ ] Identify top 2–3 items that would be the most helpful at this point in time.
- [ ] Create a roadmap for each item.

---

## Retrospection

### Good
* Some ideas were uncovered during the IA work.

### Bad
* The IA effort took too long and I didn't get to this.

### Try
* Breaking down even smaller.

Story points: 5.0
Rename foundations-color-palette component to color-palette

The following discussion from !2970 should be addressed:

- [ ] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2970#note_1025851626):  (+1 comment)

    > **note:** I forgot to give this component a more generic name during the initial implementation. Given that it works in both pages that render color palettes, we can probably rename this to simply `color-palette`. I will do that in a follow-up.

Story points: 1.0
Abstract color palettes out into a reusable Vue component

The following discussion from !2910 should be addressed:

- [ ] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2910#note_1010952473):  (+2 comments)

    > **thought:** There's a lot of duplicated code in this file. Now that we can use Vue components inside Markdown, we should probably think of a way to abstract the color palettes into a reusable component to clean this up a bit.

Story points: 2.0
FY23 Q3 Foundations KR2:  Gap analysis that determines what areas of Pajamas are missing or needing further refinement, and what the potential impact is

## Purpose

See [epic description](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/12).

## Steps

- [ ] Conduct an internal survey to better understand what perceived gaps are.
- [ ] Triage open issues to determine what topics and items are most commonly discussed.
  - [ ] Create sub-epics or new issues to organize by theme.
- [ ] Identify gaps in Pajamas design language. These are the areas that need clarified in order for anyone to have confidence and continuity when building an experience using the design system. For example, I know what component A does, but do I know how to use it with component B, or in a scenario where multiple components exist?
- [ ] Make proposals to close gaps.

---

## Retrospection

### Good
* Some ideas were uncovered during the IA work.

### Bad
* The IA effort took too long and I didn't get to this.

### Try
* Breaking down even smaller.

Story points: 3.0
Pajamas > Definitions

- Evaluate existing definitions found at https://design.gitlab.com/get-started/structure with a primary focus on: Foundations, Components, Regions, and Objects.
- Update definitions and create new ones for sections considered in the [IA exercise](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1378).

[Working file in Figma →](https://www.figma.com/file/qYQOk3DhrswWIsRnoUTJ6J/%231378-Pajamas-IA-JE?node-id=0%3A1)

Story points: 3.0
Draft: Pajamas scaffolding, structure, and ops

## Purpose

Pajamas provides foundational styles and element, component guidelines, abstracted objects, and UX content, but it's less clear on how to assemble all of these disparate parts. It's these middle guiding layers of the design system that need built out to provide more visual design direction and UI consistency when it comes to implementation.

At the same time, Pajamas needs a common vernacular with agreed upon definitions and categorization. For example, terms like "patterns," "organisms," and "regions" mean different things to everyone and time spent aligning on meaning stifles additions and system maturity. A large part of the initial effort will be to refine the GitLab design language and provide the consistent groundwork that efforts like "unboxing" and "beautification" — and future ones like them — need to stand on. Pajamas is not just _what_, but _how_, and this is what it means to have a design language and not just a design system. 

## Phases

1. **Pajamas scaffolding** (%"15.2")
   - Definitions
   - Website / design system IA and content mapping
   - Gap analysis:
     - Gaps in Pajamas design language
     - Gaps between Pajamas and product
2. **Pajamas structure** (TBD)
   - Website updates: Implement IA changes
   - SSoT: What would it take to make the Pajamas site the go-to?
3. **PajamasOps** (TBD)
   - Storybook: Playground, features, robust layouts, accessibility testing
   - Figma: Internal plugins, designer efficiency
   - Triage and contributions
   - Prioritization

## Outcomes

- Consistency in design execution and user experience
- Shared design language
- More informed decisions and contribution
- Pajamas → Product planning and prioritization

## Considerations

- Pajamas documentation should be prescriptive when necessary, and guiding when not. The aim is not to have a draconian system, but one that provides meaningful constraints to foster collaboration, provide clear and informed guidance, and inspire new possibilities.
- Refining the design language gives space for efforts like tokenizing and theming to have a meaningful place.
- Gap analysis helps to define not only what areas need building out, but also the size and impact of gaps between Pajamas and the product. For example, typography is foundational, but not consumed by the product.

## Resources and reference

- [IBM Design Language](https://www.ibm.com/design/language/)
- [Visual Design Language: The Building Blocks Of Design](https://www.smashingmagazine.com/2020/03/visual-design-language-building-blocks/)

Story points: 5.0
Illustration > Add XS grid size

## Purpose

A new extra small (XS) grid is being added to provide a size that illustration elements can be created at when they're used alongside other UI or to comprise part of a larger design.

For example, in https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/794 a "bidirectional-xs" illustration is being added to connect two logos. Because of our third-party trademark policy we didn't want to add this to one of the logos or combine them. The 72px grid here would've been too large in relation to the logos and placed emphasis in the wrong place.

36px was chosen instead of 32px (and base 8) in order to follow the illustration pattern where each size increases at 2x.

Story points: 1.0
Helping users > Update content guideline formatting

Follow up from https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2857#note_957102484:

>1. Make the "GitLab repository `/doc` directory" a link to that directory.
>1. Format the Content Guidelines as a list. I noticed it follows the same "when… do this" type of pattern from other sections and might be easier to parse each consideration as a separate bullet.

Story points: 1.0
Clarify in Pajamas whether a successful save should be an alert or a toast

### Problem to solve

We use an info alert on the user settings page to confirm a change, but elsewhere (e.g. the Vulnerability Report), after a successful bulk action, we use a toast notification to confirm the change has been made. 

On the [alerts](https://design.gitlab.com/components/alert/#when-to-use) page, Pajamas says:
> Reaffirm to the user that a prior action, likely in a different location or context, has been successful.

"When to use" on the [toast](https://design.gitlab.com/components/toast/#when-to-use) page, on the other hand, says:
> Provide a contextual message based on a user's action in the same view the action took place.

### Proposal

With all the types of alerts we can have in one area at one time (error, warning, etc) in some places, especially the security tab of the pipeline page (see designs in https://gitlab.com/gitlab-org/gitlab/-/issues/352880#note_961677263), we should use toast notifications to confirm a saved change. 

Either way, we should update the Pajamas docs accordingly (toast, alert, and [Instant Feedback](https://design.gitlab.com/product-foundations/saving-and-feedback#instant-feedback)) to be more clear which is the suggested pattern.

Story points: 3.0