giseldo/neodataset huggingface dataset:
GlCarousel: flaky visual test

`GlCarousel` sometimes [fails](https://gitlab.com/gitlab-org/gitlab-ui/-/jobs/886328002) with some unnoticeable differences that don' seem to be ever caused by any of our changes.

The fact that we're loading images from a remote source to populate the slides might be responsible for those inconsistent results. Let's try storing them locally to see if it helps in the long run.

Story points: 1.0
Scoped labels: scoped text needs visible underline on hover

## Problem

The scoped text portion of the label doesn’t have a visible underline when text is reversed (white) on the left, but should, for interactive states.

![CleanShot_2020-12-23_at_09.52.35](/uploads/650be2a85843012c094af0981e2dbfb4/CleanShot_2020-12-23_at_09.52.35.gif)

## Solution

![Screen_Shot_2021-04-19_at_12.09.44_PM](/uploads/8e8518ec1ad3a715298157686bc89aff/Screen_Shot_2021-04-19_at_12.09.44_PM.png)

Figma: https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=1531%3A2

Story points: 1.0
Add additional percentage width utility classes

We need additional utility classes for percentage widths for https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49551.

`10p` `20p` `40p`

**Proposal**

```
.gl-w-10p {
  width: 10%;
}
.gl-w-20p {
  width: 20%;
}
.gl-w-40p {
  width: 40%;
}
```

Story points: 1.0
GlTab: Misalignment when mixing tabs with and without counters

## Problem to solve

When mixing tabs with and without counters it causes the selected border of the tab without a counter to be misaligned. 

## Screenshots

![image](/uploads/96c72bab635446bf633dceff9306af88/image.png)

## Proposed solution

1. Set `GlTab` to use `display: flex`
2. Add spacing between the label and counter

## Additional notes

_Tested in Chrome Version 86.0.4240.198 (Official Build) (x86_64)._

Story points: 1.0
Remove (or document) duplicate buttons in tab component

#### Background

I was working on [pipeline tabs](https://gitlab.com/gitlab-org/gitlab/-/issues/230728) to our tabs component and noticed we duplicate the buttons on the right, show them on desktop view, and hide them on mobile (where the "mobile" block of buttons appears).

| Desktop | Mobile |
| ------ | ------ |
| ![Screen_Shot_2020-11-18_at_3.49.33_PM](/uploads/be6bd8143f6c06ffd230ab55d7474697/Screen_Shot_2020-11-18_at_3.49.33_PM.png) | ![Screen_Shot_2020-11-18_at_3.49.44_PM](/uploads/ed42292e7c851f14f1995a4a2d39cf95/Screen_Shot_2020-11-18_at_3.49.44_PM.png) |

Before migrating, we are just using the usual classes to change alignment/styling based on screen width. After migrating, the buttons have to be duplicated and then hidden/shown.

#### Questions

- Assuming the above is the design we want to achieve (@tauriedavis is it?), is there another way we could go about this without duplicating code? Is there a way to account for an optional button section within the tab component?

#### What next?

I'm not on the frontend or foundations team so it's not really my call, but here are a few ideas:

1. Leave everything as-is, and continue duplicating the buttons
   - if we want to refactor this later, we should keep track of these somehow
   - update the tab migration epic to include instructions for duplicating buttons
2. Stop the tab migration altogether and either
   - Update the tabs component to account for buttons
   OR
   - Change the design

cc @agulina @afontaine

Story points: 3.0
GlEmptyState - Image doesn't fill space

### Summary

The `GlEmptyState` has a `svgHeight` parameter, but setting it only sets the height. The width doesn't auto fill.

### Screenshots

![image](/uploads/8d7c99056288e37016c13da9cf9fb7e2/image.png)

### Proposed Solution

Set the img class to `gl-max-w-full!`.

Story points: 1.0
Style Accordions component

# What

After Accordions being built in https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1066 this will ensure it's styled (~"pajamas::style") properly according to spec:

* [Design specifications](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=3463%3A0)
* [Documentation](https://design.gitlab.com/components/accordions)

Story points: 1.0
Build Accordion component in gitlab-ui

# What

There is already an existing component to show/hide content, Collapse.

However, it doesn't follow the Pajamas specification: 
* [Design specifications](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=3463%3A0)
* [Documentation](https://design.gitlab.com/components/accordions)

Story points: 2.0
Remove visual_gitlab_integration CI job

We [recently](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1762) had to allow the `visual_gitlab_integration` job to fail when it started failing for no obvious reason.

While this job has been useful to prevent some CSS leak issues in the past, it doesn't seem like we've had such issues lately thanks to some CSS structure changes.

We feel like the cost of fixing the job might be greater than the resulting benefit. In consequence, let's remove this job altogether!

Let's also remove the `Include GitLab CSS` checkbox which produces the same results as the CI job.

Related internal discussion: https://gitlab.slack.com/archives/CH9QG9TAQ/p1606510558271600

Story points: 1.0
Update component code adding description for form input fields

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/642, we added an optional description area below the title of an input field. This issue is to update the component code.

| Former text input limitations | Proposed change - adds description field under label |
| ------ | ------ |
| ![image](/uploads/d776db3b7bb741ff37aa95ea9775ade0/image.png) | ![image](/uploads/86b01958e0fbb48cc0d8bf894ee3a043/image.png) |
| Descriptions could only go below the text input ("help text") | Adds a description field under the label (doesn't limit designers to using the help text below the input field for a description |



## Implementation Plan
- In gitlab-ui add a `labelDescription` and `label` prop to https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/src/components/base/form/form_group/form_group.vue

- Add `label` slot to https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/src/components/base/form/form_group/form_group.vue
so end up with something like 

- Update story book examples + add examples
- Update unit tests and manually test in gitlab codebase.

```
<template>
  <b-form-group v-bind="$attrs" class="gl-form-group" :label-class="actualLabelClass">
    <template #label>
      <template v-if="label">{{ label }}</template>
      <gl-form-text v-if="labelDescription" class="gl-mt-3">{{ labelDescription }}</gl-form-text>
    </template>

    <slot v-for="slot in Object.keys($slots)" :slot="slot" :name="slot"></slot>
  </b-form-group>
</template>
```

Story points: 2.0
Allow setting full width on GlDatepicker

To handle this use case, we would need to add this custom CSS.

```css
.board-sidebar-due-date .gl-datepicker,
.board-sidebar-due-date .gl-datepicker-input {
  width: 100%;
}
```

Adding the `.gl-w-full` utility does widen the container, but not the input.

<details>
<summary>Screenshot: full width datepicker input and container</summary>

![image](/uploads/482fa25942249b48cf1686d4fa61931f/image.png)
</details>

----

As a proposal, we can add a `block` prop as we do on `GlDropdown`.

Story points: 1.0
Official support of Node.js 14.x

Node.js 14.x, released on 2020-04-21, was marked as LTS on 2020-10-27, so gitlab-ui has to support that version of Node.js.

cf.

- https://nodejs.org/ja/blog/release/v14.15.0/
- !1689 (#975)
- gitlab!43808 (gitlab#258963 gitlab#258964)

Story points: 2.0
GlButton: label variant should not render a <button>

This follows-up on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38421#note_421432692

`GlButton` supports a `label` mode that can be used to render text with some basic button styles. Currently, this variant renders an inactive `<button>`, which seems bad practice in terms of accessibility as the label should be presentational only, so it would be preferable to render a `<span>` or a `<div>` instead.

When used in a button group, the actual button in the group could leverage the `aria-labelledby` attribute to reference the label button.

Story points: 2.0
Let GlTab extend `title-link-class` prop value

When using `GlTab` it would be convenient to pass a class to the link, such as [in this scenario](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42236/diffs#note_415030061).

Given the [current implementation](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/tabs/tab/tab.vue#L12) it is not possible.

We should add support for it.

Story points: 1.0
Css utilities in display.css do not follow responsive naming pattern

The following discussion from !1704 should be addressed:

- [ ] @rob.hunt started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1704#note_408495978):  (+1 comment)

    > **Question (non-blocking):** This file doesn't seem to follow our [naming pattern](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/doc/contributing/adding_css.md#responsive-utilities) for responsive utilities. Should we create an issue to fix these or are you aware of one already? :thinking:

Story points: 2.0
Provide option to trigger event on GlBanner button click

## Issue
From the discussion https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37658#note_40484599, currently the GlBanner takes props to allow adding a link for the Call to Action button component that gets rendered, but this does not cover scenarios where the action we want to perform is not simply navigating to a new url, for example triggering a modal window.

Additionally, if we have not already done so, we should migrate the `GlDeprecatedButton`

## Possible solutions
* The could be updated to emit a `click` event when the Call to action button is clicked, this would allow users to hook perform an action after the button click
* We could convert the Call to Action to a `<slot>`, allowing the user to provide their own code in place of the Call to Action button.

Story points: 2.0
Setup @storybook/addon-docs

Install and setup `@storybook/addon-docs` to enable [DocsPage](https://storybook.js.org/docs/vue/writing-docs/docs-page), [Component Story Format (CSF)](https://storybook.js.org/docs/vue/api/csf) and [MDX](https://storybook.js.org/docs/vue/api/mdx).

Story points: 2.0
Follow-up from "feat(css): add gl-pt-md-n2/gl-mt-md-n2 classes"

The following discussion from !1664 should be addressed:

- [ ] @sarahghp started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1664#note_400841497):  (+1 comment)

    > Thanks, @dstull and @oregand.
    > 
    > ![image](/uploads/727b70f047929a513d1c68355a9a52e5/image.png)

Story points: 1.0
Follow-up from "feat(css): add gl-display-md-block class"

Replace `d-md-block` with `gl-display-md-block` class in GitLab

The following discussion from !1660 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1660#note_399607631):  (+2 comments)

    > should we do a follow up to replace any use of `d-md-block` in GitLab after this is released?  How is that handled usually and how often do we update `gitlab-ui` in GitLab?

Story points: 1.0
Migrate default export to named export(s) in src/directives/safe_html/safe_html.js

- [ ] Convert the default export to named export(s) in `src/directives/safe_html/safe_html.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/utils/use_fake_date.js

- [ ] Convert the default export to named export(s) in `src/utils/use_fake_date.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/utils/charts/data.js

- [ ] Convert the default export to named export(s) in `src/utils/charts/data.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/directives/tooltip.js

- [ ] Convert the default export to named export(s) in `src/directives/tooltip.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/utils/validation_utils.js

- [ ] Convert the default export to named export(s) in `src/utils/validation_utils.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/components/mixins/button_mixin.js

- [ ] Convert the default export to named export(s) in `src/components/mixins/button_mixin.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/directives/resize_observer/resize_observer.js

- [ ] Convert the default export to named export(s) in `src/directives/resize_observer/resize_observer.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/directives/collapse_toggle.js

- [ ] Convert the default export to named export(s) in `src/directives/collapse_toggle.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/directives/modal.js

- [ ] Convert the default export to named export(s) in `src/directives/modal.js`.
- [ ] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [ ] Remove the override from `.eslintrc.yml`.
- [ ] Put an MR up, and integration MRs if needed.
- [ ] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/components/base/form/form_checkbox_tree/models/tree.js

- [x] Convert the default export to named export(s) in `src/components/base/form/form_checkbox_tree/models/tree.js`.
- [x] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [x] Remove the override from `.eslintrc.yml`.
- [x] Put an MR up, and integration MRs if needed.
- [x] Follow the standard review process.

Story points: 1.0
Migrate default export to named export(s) in src/components/base/form/form_checkbox_tree/models/node.js

- [x] Convert the default export to named export(s) in `src/components/base/form/form_checkbox_tree/models/node.js`.
- [x] Make sure that internal `import` statements are also updated to reflect this change.
    * WARNING: some of the default exports might be used outside of GitLab UI. Use your best judgement to determine when a given export might be used in consuming projects. Those cases should be flagged as breaking changes and should be submitted along with integration MRs in the projects we control.
- [x] Remove the override from `.eslintrc.yml`.
- [x] Put an MR up, and integration MRs if needed.
- [x] Follow the standard review process.

Story points: 1.0
GlSearchBoxByType calls input listener twice

The following discussion from gitlab!39630 should be addressed:

- [ ] @markrian started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39630#note_397284845):  (+6 comments)

    > **thought**: Rather than `watch`ing the model, we could instead just add an `input` event listener to the `GlSearchBoxByType`. WDYT?

Story points: 1.0
Add 2nd Y-axis for column chart and stacked column chart

Broken down from https://gitlab.com/gitlab-org/gitlab-ui/-/issues/889#note_393850965

Add 2nd Y-axis for column chart (and stacked column chart)

![image](/uploads/5c2794a8b292fe55ef67fcb69e4c6bae/image.png)

Story points: 2.0
Add size (or similar) prop to form input

Our [design specs for inputs](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Pajamas-UI-Kit?node-id=2977%3A1) indicate that there are certain sizes (widths) that are allowed.

While the underlying `BFormInput` component already has a `size` prop, that changes the padding/margins around the input. In any case, our styles override that behaviour anyway. I suggest we repurpose the existing `size` prop to implement these widths.

![Screenshot_from_2020-07-24_19-01-36](/uploads/59446b278e5c1211a74824057425ca4a/Screenshot_from_2020-07-24_19-01-36.png)

The sizes are (based on the design spec):

| Name | (Max) Width |
| ------ | ------ |
| xs | 80px |
| sm | 160px |
| md | 240px |
| lg | 320px |
| xl | 560px |

## Questions

- What would be the _default_ size? Currently, inputs take up all available width; i.e., they're unbounded. Should that still be possible?
- Is setting this via `max-width` sufficient?

Story points: 2.0
GlAlert: Add slot for title

Add a title slot to the `GlAlert` component.

Why? It's sometimes necessary to add custom elements or styles to the title. For example the design in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36962#modal:

![image](/uploads/681153ac7cba5d752638f5e6c9c32b6d/image.png)

Story points: 1.0
Proposal: change border and box-shadow units from `rem` to `px`

## Background

There are a number of instances where we use `px-to-rem(1px)`. This causes some rounding errors and in turn can cause issues with rendering. 

```
px-to-rem(1px) == 0.06rem
0.06 * 16 = 0.96, i.e. less than 1px!
```
Stollen from https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1534

## Proposal

Replace `border` and `box-shadow` properties that are using `rem` with `px`. Here is a list of places to replace:

- [src/components/base/button/button.scss#L6](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L6)
- [src/components/base/button/button.scss#L11](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L11)
- [src/components/base/button/button.scss#L16](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L16)
- [src/components/base/button/button.scss#L21](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L21)
- [src/components/base/button/button.scss#L65](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L65)
- [src/components/base/button/button.scss#L90](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/button/button.scss#L90)
- [src/components/base/path/path.scss#L8](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/path/path.scss#L8)
- [src/components/base/segmented_control/segmented_control.scss#L5](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/src/components/base/segmented_control/segmented_control.scss#L5)

Story points: 2.0
Column + Line chart with 2 Y-axes

### Problem

When showing a chart containing data sets at different orders of magnitude (e.g. issues closed, 10; issues opened, 10; total issues 1,000), this reduces the size of the visualisations at lower orders of magnitude to a point where they aren't useful.

### Solution

* Add a variant to our [charts](https://design.gitlab.com/components/charts) component which has a second Y-axis.
* Add guidance to our documentation on using this (potentially confusing) pattern
* [See Figma prototype](https://www.figma.com/proto/GevTEMYLCPyWn2bo564C2V/Grouped-Stacked-Column?node-id=55%3A916&viewport=95%2C316%2C0.8319990634918213&scaling=min-zoom)

![image](/uploads/10359a184ebb3138efa520655adca82d/image.png)

Story points: 2.0