giseldo/neodataset huggingface dataset:
Automatically add the appropriate `rel` attribute when using `GlButton` with `href`

When using `GlButton` with an `href` attribute (i.e. `<gl-button href="...">`), the developer needs to remember to add a `rel` attribute (if appropriate):

```html
<gl-button href="https://example.com" rel="noopener noreferrer">Click me</gl-button>
```

We should update `GlButton` to automatically apply the appropriate `rel` attribute, similar to what `GlLink` does. This would save developers from having to remember to add the `rel` attribute manually and enforce a consistent usage of `rel` across our product.

Based on an internal conversation with @ealcantara (https://gitlab.slack.com/archives/C0GQHHPGW/p1588601058335600?thread_ts=1588600819.335400&cid=C0GQHHPGW), this should relatively simple by including the `rel_mixin` in `button.vue`.

Story points: 1.0
Follow-up: Style form_input/textarea readonly and disabled states following Pajamas specs

The purpose of this follow-up issue is styling the form_input/textarea readonly/disabled states following Pajamas specs.

The following discussion from !1341 should be addressed:

- [ ] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1341#note_333107121):  (+1 comment)

    > Looks great! I think this is ready to merge. 
    > 
    > The ~~invalid~~ readonly/disabled textarea is incorrect, is there a separate issue to fix that or should we create one?
    > 
    > Also I'm not sure about the two way bound input. Do we use that anywhere? Can it be removed or do we need to update the text underneath to use the current font/spacing? This seems separate from this MR so happy to open a separate issue to take a look.

Story points: 1.0
Improve GlIntersectionObserver performance

## Description

The [`GlIntersectionObserver`](https://gitlab.com/gitlab-org/gitlab-ui/blob/314dda4b7e37ba103daaa797c37a718d504a5b3c/src/components/utilities/intersection_observer/intersection_observer.vue#L1) creates an [IntersectionObserver](https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserver) for every instance. When implementing the [`GlResizeObserver`](https://gitlab.com/gitlab-org/gitlab-ui/blob/225bf66a8818cbf7f74ae1339b8f19b856f25352/src/directives/resize_observer/resize_observer.js#L6) we learned that these observers are [meant to be shared](https://github.com/WICG/ResizeObserver/issues/59). This is because there's a bottleneck with passing messages from the native environment to the JavaScript environment.

## Demo

Here's a patch that creates a 100x10 table filled with `gl-intersection-observers` which each update with the [`intersectionRatio`](https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserverEntry/intersectionRatio) of the triggered event.

[0001-wip-big-table-example.patch](/uploads/287d49589b28d2182f76f6fc1298341f/0001-wip-big-table-example.patch)

| Observers created for every instance (on `master`) | Observers shared (this proposal) |
|---------|----------|
| ![20200311_lots_of_intersection_observers_slow](/uploads/8fae9d5c39c6db4d1eabd1afd4c05b1f/20200311_lots_of_intersection_observers_slow.mp4) | ![20200311_shared_intersection_observer](/uploads/a530a94a856ba91e2e5f9e99cbd5380b/20200311_shared_intersection_observer.mp4) |

- Notice that the first example the numbers take a long time to update. This is because there's a huge lag for triggering every "IntersectionObservable" callback.
- *side note:* I'm not sure where the decimals come from, but I think this has to do with the experimental nature of IntersectionObserver :shrug:
- Here's a dummy WIP patch used for the "Observers shared" example: [0002-wip-shared-intersection-observer.patch](/uploads/a4e94b9cce363c0a1b8f9660f46e98ab/0002-wip-shared-intersection-observer.patch)


## Proposal

I suggest following the implementation of [`ResizeObserver`](https://gitlab.com/gitlab-org/gitlab-ui/blob/225bf66a8818cbf7f74ae1339b8f19b856f25352/src/directives/resize_observer/resize_observer.js#L6) as an example for this behavior: 

- Let's just create one intersection observable for now (later we can figure out what to do if we want some more explicit options)
- Let's move this to a directive (this way we don't create unnecessary `<div>`s)

Story points: 2.0
Extend generate component to include basic unit test

When you run `yarn generate:component`, there is no base unit test created alongside the component file scaffold, nor is there any indication of where to add a test. 

So we will:

1. Add a very basic unit test scaffold to `yarn generate:component`
2. Extend the [contribute guide](https://gitlab.com/gitlab-org/gitlab-ui/-/doc/contributing/adding_components.md) to include information about adding component unit tests.

Story points: 1.0
Add Navbar Component

Coming from this comment: https://gitlab.com/gitlab-org/status-page/-/merge_requests/3#note_298425624

We are currently building the status page MVC and using the `gitlab/ui` lib heavily. 

One thing we would like is the ability to import a navbar/header from `gitlab/ui` which relies on the [bootstrap-vue navbar](https://bootstrap-vue.js.org/docs/components/navbar/) instead of needing to maintain custom header vue files and css.

Given that, I am opening this issue to tackle the idea of adding a header/navbar component to the library.

Story points: 2.0
GlSearchBoxByType debounce prop support

## The issue

Based on a conversation with @kushalpandya found here: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25061#note_290719425

`GlSearchBoxByType` wraps `BFormInput` but doesn't support the `debounce` functionality that the bootstrap form input does.

More information can be read here: https://bootstrap-vue.js.org/docs/components/form-input/#debounce-support

## Examples

```html
<gl-search-box-by-type v-model="namespaceSearch" :debounce="500" class="m-2" />
```

**Network Tab:**
![Screen_Shot_2020-02-20_at_8.44.20_AM](/uploads/793a13dbf3ba09e83890ed7da22acb24/Screen_Shot_2020-02-20_at_8.44.20_AM.png)

```html
<b-form-input v-model="namespaceSearch" :debounce="500" class="m-2" />
```

**Network Tab:**
![Screen_Shot_2020-02-20_at_8.43.10_AM](/uploads/a4cb18063d65b213eccbeda3390de162/Screen_Shot_2020-02-20_at_8.43.10_AM.png)

## Proposal

**Support the following props**

```js
debounce: {
  type: Integer
}
```

This would stop the model from updating until the debounce time has occurred

Story points: 2.0
GlAvatarsInline: Add tooltip to badge

When using `GlAvatarsInline`, a badge next to the avatars shows the number of remaining avatars when the total number of avatars exceeds the given `maxVisible` prop. Let's add a tooltip to the badge which shows the names.

We should consider the following:
1. We need to specify a prop which will be used for the tooltip content
2. We might need to add a threshold prop (either a `max characters to display` or `max names to display` so in case the of a large number of remaining avatars, the tooltip won't bloat.
3. We should also truncate the tooltip text via JS (and append `...`) when the threshold from (2) is exceeded.



Story points: 1.0
Fix fonts size of help text in radios/checkboxes

The following discussion from gitlab-org/gitlab-services/design.gitlab.com!1651 should be addressed:

- [ ] @pedroms started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1651#note_271309985):  (+4 comments)

    > @jboyson unsure if related to this MR, the help text paragraph `p` has an odd font-size:
    > 
    > ![image](/uploads/ee7235e8b6dbb5c4fc7c245a234a0685/image.png)

Story points: 1.0
Add disabled option to radio example

The following discussion from !1651 should be addressed:

- [ ] @jboyson started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1651#note_261290489):  (+4 comments)

    > @pedroms review please. Please let me know if you think we need a more detailed example.

Story points: 1.0
Follow-up from "ci: add automated integration branch CI job"

When https://gitlab.com/gitlab-org/gitlab/issues/22638 is merged, let's refactor the `create_integration_branch` CI job so it reads the package's URL from environment variables rather than passing through file artifacts.

The following discussion from !1007 should be addressed:

- [ ] @pgascouvaillancourt started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/1007#note_270619808):  (+1 comment)

    > **note:** We won't need to write the URL to a file anymore once https://gitlab.com/gitlab-org/gitlab/issues/22638 is resolved

Story points: 1.0
Abstract access to `nextTick()` in Jest tests into a utility function

This is about craziness like `wrapper.vm.nextTick()` and it's bad-brother `vm.vm.nextTick()`.

The following discussion from !999 should be addressed:

- [ ] @ntepluhina started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/999#note_268989062):  (+1 comment)

    > **nitpick**: out of the scope of the MR but `vm.vm` is triggering me so much :sweat_smile: could we use something like `wrapper` in future tests to distinguish VTU `Wrapper` from the actual Vue instance?

One of the possible solutions: manually update all suits with [the suggestion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/999#note_268739060) from https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/999.

However, a more abstract universal utility shared between all suits automatically would be preferable.

Story points: 2.0
Follow-up from "Add Search examples and mark search as built"

The following discussion from gitlab-org/gitlab-services/design.gitlab.com!1655 should be addressed:

- [ ] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1655#note_268796592):  (+3 comments)

    > Also I don't understand this text that says to set the content to "Something else"
    > 
    > ![Screen_Shot_2020-01-08_at_10.44.30_AM](/uploads/2df1808315cbf97977e710871bfaf4f3/Screen_Shot_2020-01-08_at_10.44.30_AM.png)
    > 
    > Should that be removed?

# Solution

Remove text button from below search bar

Story points: 1.0
Migrate away from deprecated slots syntax

The following discussion from !993 should be addressed:

- [ ] @ntepluhina started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/993#note_267967306): 

    > **nitpick**: Again, outside the current MR's scope :sweat_smile: `slot` attribute has been deprecated since Vue 2.6, could we please create a follow-up issue to replace them with `v-slot` directive? Warning: this might affect unit tests as vue-test-utils still work with Vue 2.5 syntax and you will need to stub a component to test its slots.

Story points: 2.0
Prevent style leaking into components

## The issue

Inheritable styles are being overridden. For example, Pajamas often leaks `line-height` and adds margins to headings (see image below).

## The fix? :thinking: 

Create a class that explicitly sets all known inheritable properties, and use this class on all components.

ex:

```css
.gl-reset {
  line-height: 1rem;
  font-size: 1rem;
  ...
}
```

## Build tool update? :thinking: 

Remembering to add `.gl-reset` to every component is potentially error-prone. Is it possible to update webpack to auto-include this class for every component?

## List of known inheritable properties

* border-collapse
* border-spacing
* caption-side
* color
* cursor
* direction
* empty-cells
* font-family
* font-size
* font-style
* font-variant
* font-weight
* font-size-adjust
* font-stretch
* font
* letter-spacing
* line-height
* list-style-image
* list-style-position
* list-style-type
* list-style
* orphans
* quotes
* tab-size
* text-align
* text-align-last
* text-decoration-color
* text-indent
* text-justify
* text-shadow
* text-transform
* visibility
* white-space
* widows
* word-break
* word-spacing
* word-wrap

## Example of the issue

https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1620#note_245401786

![image](/uploads/3927ca1641e8f80faad09d30a6676136/image.png)

## What success looks like

* [ ]  Ensure all current demos on design tab match design specs

Story points: 2.0
Use sass functions for box-shadow utilities

box-shadows do not lend themselves well to be "just" utility classes. We need some functions to make it easier to maintain shadows for use in components such as toggles, and buttons.

The following discussion from !876 should be addressed:

- [ ] @jboyson started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/876#note_239100122):  (+4 comments)

    > @ealcantara can I get some feedback on how I'm proceeding with these? This is the duplicate "boilerplate" code I was talking about.

Story points: 1.0
Prevent `segmented_control` forever loop edge case

## Description

There's an extreme edge case where usage of `segmented_control` could produce a forever loop. Let's figure out a nice way to prevent this from **ever** happening.

## Context

The following discussion from !689 should be addressed:

- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/689#note_235853534):  (+3 comments)

    > **suggestion (non-blocking):** I just realized that there's some cases where this `$emit('input')` on `watch('checked')` can cause a forever loop. Obviously we can't prevent the client of this component from doing something dangerous... If you think we can improve this, maybe it's worth a follow up issue :shrug:
    > 
    > While we're here what do you think of adding this bit where we don't submit a `oldValue` suggestion if it's equal to the new value (which can happen if they are objects/arrays). It's a bit paranoid I know....
    > 
    > <details>
    > 
    > ```patch
    > diff --git a/src/components/base/segmented_control/segmented_control.vue b/src/components/base/segmented_control/segmented_control.vue
    > index 5906b8dd..0f8e63e2 100644
    > --- a/src/components/base/segmented_control/segmented_control.vue
    > +++ b/src/components/base/segmented_control/segmented_control.vue
    > @@ -47,8 +47,12 @@ export default {
    >        if (!this.enabledOptions.some(({ value }) => value === newValue)) {
    >          // eslint-disable-next-line no-console
    >          console.warn(genericErrorMessage);
    > +
    > +        // prevent a forever loop when values are objects
    > +        const suggestion = oldValue && newValue !== oldValue ? oldValue : null;
    > +
    >          if (this.enabledOptions.length) {
    > -          this.$emit('input', oldValue || this.enabledOptions[0].value);
    > +          this.$emit('input', suggestion || this.enabledOptions[0].value);
    >          }
    >        }
    >      },
    > 
    > ```
    > 
    > </details>

/cc @xanf

Story points: 2.0
Style text badges

Style **text-only** variations of badges: https://design.gitlab.com/components/badge#design-specifications

Take into account **size** and **color** variations, and ignore the icons for now.

![Screenshot_from_2020-04-21_15-33-00](/uploads/0bc742ac131af789a037a0e422bea929/Screenshot_from_2020-04-21_15-33-00.png)

## Tasks

* [x]  Implement in GitLab UI https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1248
    * [x]  Make old `GlBadge` available as `GlDeprecatedBadge`
    * [x]  Implement new badge available as `GlBadge`
* [ ]  Create integration MR for GitLab ~~https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28356~~ https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31646
* [ ]  Create integration MR for [Status Page](https://gitlab.com/gitlab-org/status-page/)  ~~(currently blocked by https://gitlab.com/gitlab-org/status-page/-/merge_requests/78)~~ https://gitlab.com/gitlab-org/status-page/-/merge_requests/90
* [-]  Create integration MR for [Customer Portal](https://gitlab.com/gitlab-org/customers-gitlab-com)
    *  It turns out the Customer Portal doesn't use `GlBadge`, so no integration MR is necessary!
* [x] Create epic to migrate `GlDeprecatedBadge` usage to `GlBadge` https://gitlab.com/groups/gitlab-org/-/epics/3280
* [x]  Open issue under https://gitlab.com/groups/gitlab-org/-/epics/2964 to tackle slightly-wrong colours (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28356#note_337466265)
    * https://gitlab.com/gitlab-org/gitlab/-/issues/213570 will address the grays being different between gitlab-ui and GitLab. 

Story points: 2.0
Add a close button component

Some components (e.g., [alert](#454), [banner](#453)) include a close/dismiss button. It makes sense to extract this into a dedicated component, much like [BootstrapVue does](https://github.com/bootstrap-vue/bootstrap-vue/blob/v2.0.0-rc.28/src/components/button/button-close.js).

cc @samdbeckham

Story points: 1.0
gl-popover-title margin 0

From https://gitlab.com/gitlab-org/gitlab/merge_requests/18543#note_230295935

currently `.md h3` adds styles to popovers in markdown areas (i.e. chart tooltips). We should explicitly set `margin: 0` in the [popover styles](https://gitlab.com/gitlab-org/gitlab-ui/blob/79f157f1433bfc691f56aa3516f3b319bc3d0055/components/base/popover/popover.scss#L45) to prevent this

Story points: 1.0
Remove the Wiki

After adding the [`FAQ.md`](https://gitlab.com/gitlab-org/gitlab-ui/blob/master/FAQ.md) to the repo, I realized that there was already one in the Wiki: https://gitlab.com/gitlab-org/gitlab-ui/wikis/Frequently-asked-questions

When I asked on Slack what we should to about this, @gtsiolis suggested the following:

>  **Suggestion**: To avoid this from happening again, I vote for removing wiki altogether.
Wiki is already hidden for members and completely inaccessible for anonymous users because of the missing home page. See https://gitlab.com/gitlab-org/gitlab/issues/22319, https://gitlab.com/gitlab-org/gitlab/issues/22319, etc. Not sure if dogfooding two (one of them obsolete) wiki pages brings in much value.
>
> **To-do**: Let’s merge FAQ contents and also go through the roadmap page where most of the items have been completed or replaced with newer initiatives. Maybe consider moving one or two items from the roadmap wiki to the WG epic in https://gitlab.com/groups/gitlab-org/-/epics/950 if needed.

# Todos

- [x] Move [questions](https://gitlab.com/gitlab-org/gitlab-ui/wikis/Frequently-asked-questions) from the wiki to [`FAQ.md`](https://gitlab.com/gitlab-org/gitlab-ui/blob/master/FAQ.md)
- [x] Move [items from the roadmap](https://gitlab.com/gitlab-org/gitlab-ui/wikis/Roadmap) to the [epic](https://gitlab.com/groups/gitlab-org/-/epics/950) as needed
- [x] Remove the Wiki

Story points: 2.0
Reimplement storyshots integration to allow for local testing

Currently it is not possible to run visual regression tests locally (or update them locally) because the generated screenshots render differently from thew way they do in our CI job.  This is due to a difference in operating system and browser versions (different core OS elements, different font-rendering, etc).

I propose that we encapsulate our puppeteer/browser/os scripting for storyshots into a docker image that can be run both locally and in CI to produce deterministic visual regression snapshots regardless of ones working environment.

Story points: 2.0
Increase Chart type maintainability: Explore declarative child components

Seems like we have a lot of chart components that have overlapping options and duplicated code. We should evaluate how to move forward with maintaining new chart types with echarts so we reduce complexity and duplication.

One suggestion can be found at https://gitlab.com/gitlab-org/gitlab-ce/issues/66393#note_207221124 and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/32361#note_211103506

Story points: 5.0
Form style updates

1.  Textarea padding should be `8px 12px` (it's currently `6px 10px`)
2. Help text should be `#707070` (it's currently `#919191`)
3. Inputs are missing the clear icon
4.  disabled inputs styling is wrong

![Screen_Shot_2019-08-20_at_12.01.52_PM](/uploads/e02e53e354b5c741ae027bd83a219660/Screen_Shot_2019-08-20_at_12.01.52_PM.png)

4. I don't see this green validation in the specs so I'm not sure we need it here :thinking: 

![Screen_Shot_2019-08-20_at_12.04.44_PM](/uploads/cd3629764623ca9d3e5c7e32f10d9d67/Screen_Shot_2019-08-20_at_12.04.44_PM.png)




Also, we're missing several examples specified in the [specs](https://gitlab-org.gitlab.io/gitlab-design/hosted/design-gitlab-specs/forms-spec-previews/). For example, I didn't see these: 
*  an input with a character limit
*  input sizes
*  help text with a `more information` link

Story points: 3.0
Fix spacing in yAxis labels for charts

The yAxis has no spacing between the labels and the borders, like so: 

![Screen_Shot_2019-08-15_at_5.20.16_PM](/uploads/75bfdcedad99c8422780c33981441395/Screen_Shot_2019-08-15_at_5.20.16_PM.png)

This is a problem in the following charts: 

* Area Chart
* Chart
* Discreet Scatter Chart
* Line Chart

It should match what's in [GitLab UI](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/charts-area-chart--default).

Story points: 1.0
Use rems for everything instead of pixels

Follow-up to the discussion in https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/684#note_200806252

All spacing utility classes use pixels, based on Pajamas’ spacing specifications that use an 8px grid spacing system. However, using pixels doesn't allow elements and spacing to scale correctly if the user adjusts their browser zoom level (see https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/684#note_201375954)

Use rems for everything instead of pixels fixes this.

The `8px` spacing system from Pajamas uses pixels instead of rems because it's easier for everyone to understand the concept that way, and also because UI design software uses pixels. It would be harder to explain it if we said “We use 0.5rem as the base for determining our spacial system.” as this doesn't mean anything if we don't know the root size, so we would need to add “The root size is 16px”.

When translating designs to the browser, the expectation is that 16px in the design translates to 16px **rendered** in the browser, but that doesn't mean we can't use rems to specify it. So the current spacing utility classes implementation took a literal approach to the `8px` spacing system.

Story points: 2.0
Replace bootstrap overrides in the breadcrumb component

### Problem

The breadcrumb component was added in https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/387 but this also added some style overrides which affected existing components in the product like the breadcrumb for the repository path. See also relevant slack [discussion](https://gitlab.slack.com/archives/CK75EF2A2/p1565117360157200) (internal).

### Proposal

Let's replace the [overrides](https://gitlab.com/gitlab-org/gitlab-ui/blob/master/components/base/breadcrumb/breadcrumb.scss#L31-43) with `gl-*` classes.

Story points: 1.0
Add support for breadcrumb truncation

### Problem

The initial breadcrumb component [implementation](https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/387) does *not* support breadcrumb truncation.

### Proposal

Let's add support for breadcrumb truncation per [specs](https://gitlab-org.gitlab.io/gitlab-design/hosted/design-gitlab-specs/breadcrumbs-spec-previews/). See also component [documenation](https://design.gitlab.com/components/breadcrumbs#truncation) for truncation:

> Breadcrumbs should use the following rules to truncate items:
> - Use an ellipsis button to hide groups when there are three or more subgroups in the path.
> - Use an ellipsis button to hide all Wiki page breadcrumb items except the current page.
> - The top-level group and the subgroup closest to the project are never collapsed.
> - All breadcrumb items except the last one are truncated to 128px if there isn’t enough horizontal space to fit them on one line.

Story points: 3.0