@patternfly/patternfly 4.202.2 → 4.203.0

package/docs/pages/accessibility-guide.md

@@ -1,161 +0,0 @@
----
-id: Accessibility guide
----
-
-<a href="/a11y-report.html">Current a11y status</a>
-
-*Please note, this guide is a work in progress and will be updated regularly. We welcome your comments and feedback.*
-
-The goal of software accessibility is to remove barriers and create inclusive product experiences that work for everyone, regardless of physical ability.
-
-Since accessibility is best achieved when considered early in the design and development process, we ask everyone who contributes to or consumes PatternFly to understand accessibility needs and how they can be met. The following guide provides techniques and suggestions to help you design, develop, and test UIs to ensure that everyone has a good user experience.
-
-## Understanding users’ needs
-
-Great user experiences don’t just happen; they’re designed, tested, and refined with the user in mind. To develop inclusive products, it’s important to understand the varying needs of a wide range of users and consider the assistive tools and methods they use. This section provides information to help you better understand and address the needs of these [different user groups](https://a11yproject.com/posts/myth-accessibility-is-blind-people/).
-
-Note: It’s possible for a user to fall into more than one group, or to use tools and devices designed for a different user group. One of the greatest benefits of an inclusive design practice is that methods designed for a specific user group will often provide benefits to everyone.
-
-### No vision
-
-Users with no vision rely on screen readers to access web sites and applications. Often, screen reader users will navigate a page by browsing specific elements, like headers, links, or form elements. Use semantic elements and check that labels are meaningful when pulled out of context.
-
-### Low vision
-
-Users with low vision can have different needs depending on the nature of their visual impairment. Users may have difficulty with color differentiation, blurriness, or lack of vision in central or peripheral areas. These needs mean that interfaces should not rely on color to communicate information, palettes need to have sufficient contrast, and layouts should be responsive when font sizes are increased.
-
-### Motor
-
-Users with poor motor control can use a range of devices to access contents. Users who rely on a keyboard need elements that are keyboard accessible and highly visible when in focus. Users who rely on a mouse or touch need target areas that are large enough to be hit easily.
-
-### Cognitive
-
-Users who have difficulty processing information benefit from well-written content. Information should clear, concise, and easy to scan. Consider visual hierarchy, chunk content into short, related sections, and avoid long paragraphs.
-
-## Designing and developing for accessibility
-
-Our goal is to meet [level AA in the Web Content Accessibility Guidelines 2.1](https://www.w3.org/WAI/WCAG21/quickref/?currentsidebar=%23col_customize&levels=aaa). To help you get started, the following sections break some of these down by area of focus.
-
-## Checklists
-
-### What PatternFly should address
-
-If you use PatternFly, or contribute to PatternFly as a designer or developer, these are the items that are expected to be covered in PatternFly:
-
-| Guideline  | Link  |  |  |  |  |
-| --- | --- | --- | --- | --- | --- |
-| Semantic html structures are used to accurately communicate purpose and relationship of UI elements | [WCAG 1.3.1](https://www.w3.org/WAI/WCAG21/quickref/#info-and-relationships) | `design` | `html` | `css` |  |
-| Color is not the only method of communication. Providing meaning through color is supplementary to providing meaning with text | [WCAG 1.4.1](https://www.w3.org/WAI/WCAG21/quickref/#use-of-color) | `design` | `html` | `css` |  |
-| Colors used provide sufficient contrast | [WCAG 1.4.3](https://www.w3.org/WAI/WCAG21/quickref/#contrast-minimum) and [1.4.11](https://www.w3.org/WAI/WCAG21/quickref/#non-text-contrast) |  |  | `css` |  |
-| Font sizes can scale up to 200% without loss of content or functionality, and up to 400% without needing to scroll in more than one direction.  | [WCAG&nbsp;1.4.4](https://www.w3.org/WAI/WCAG21/quickref/#resize-text) and [1.4.10](https://www.w3.org/WAI/WCAG21/quickref/#reflow) |  |  | `css` |  |
-| Styles that affect text spacing (line height, space between paragraphs, letter spacing, and word spacing) can be increased without loss of content or functionality | [WCAG 1.4.12](https://www.w3.org/WAI/WCAG21/quickref/#text-spacing) |  |  | `css` |  |
-| Contents that appear on hover and focus are dismissable, hoverable, and persistent | [WCAG 1.4.13](https://www.w3.org/WAI/WCAG21/quickref/#content-on-hover-or-focus) |  | `html` | `css` | `js` |
-| All functionality is keyboard accessible | [WCAG 2.1.1](https://www.w3.org/WAI/WCAG21/quickref/#keyboard) and [2.1.2](https://www.w3.org/WAI/WCAG21/quickref/#no-keyboard-trap) |  | `html` |  |  |
-| Order of elements in the HTML and in the layout follow a logical order | [WCAG 1.3.2](https://www.w3.org/WAI/WCAG21/quickref/#meaningful-sequence) and [2.4.3](https://www.w3.org/WAI/WCAG21/quickref/#focus-order) | `design` | `html` | `css` |  |
-| Elements with focus are clearly visible | [WCAG 2.4.7](https://www.w3.org/WAI/WCAG21/quickref/#focus-visible) |  |  | `css` |  |
-| Flashing content | [WCAG 2.3.1](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=231#three-flashes-or-below-threshold) |  |  | `css` |  |
-| Functionality that uses complex gestures can also be operated with a single pointer without a path based gesture | [WCAG 2.5.1](https://www.w3.org/WAI/WCAG21/quickref/#pointer-gestures) | `design` |  |  |  |
-| Pointer events can be cancelled  | [WCAG 2.5.2](https://www.w3.org/WAI/WCAG21/quickref/#pointer-cancellation) | | | | `js` |
-| Visible labels of UI components are either the same as the accessible name or used in the beginning of the accessible name | [WCAG 2.5.3](https://www.w3.org/WAI/WCAG21/quickref/#label-in-name) |  | `html` |  |  |
-| The target area for clickable elements is at least 44 by 44 [CSS pixels](https://www.w3.org/TR/WCAG21/#dfn-css-pixels) | [WCAG 2.5.5 (AAA)](https://www.w3.org/WAI/WCAG21/quickref/#target-size)* |  |  | `css` |  |
-| An accessible name is provided for all elements | [WCAG 4.1.2](https://www.w3.org/WAI/WCAG21/quickref/#name-role-value) | `design` | `html` |  |  |
-| Status messages can be programmatically determined through role or properties | [WCAG 4.1.3](https://www.w3.org/WAI/WCAG21/quickref/#status-messages) |  | `html` |  |  |
-
-*WCAG 2.5.5 is included for reference only. This guideline suggests a size that is larger than what PatternFly requires.
-
-### What products should address
-
-If you consume PatternFly in your product, these are the items that are outside the scope of PatternFly, and should be addressed by the product developers and designers:
-
-
-| Guideline  | Link  |  |  |
-| --- | --- | --- | --- |
-| Skip to main links | [WCAG 2.4.1](https://www.w3.org/WAI/WCAG21/quickref/#bypass-blocks) |  | `development` |
-| Page titles | [WCAG 2.4.2](https://www.w3.org/WAI/WCAG21/quickref/#page-titled) |  | `development` |
-| Links — If more than one link has the same label, it should also have the same url. Screen reader users can access the list of links that are on a page, which pulls the links out of context. If you have links with different URLs but the same label, then add additional text to provide context to the screen reader user. | [WCAG&nbsp;2.4.4](https://www.w3.org/WAI/WCAG21/quickref/#link-purpose-in-context) | `design`  | `development` |
-| Landmarks — Use landmark roles to clearly identify regions that communicate page structure. If more than one landmark role occurs in the page, use aria-label to differentiate the landmark elements | [ARIA11](https://www.w3.org/TR/WCAG20-TECHS/ARIA11.html) | `design`  | `development` |
-| Headings — Heading text should be descriptive. Correct heading levels should be used to communicate the outline of the page. | [WCAG 2.4.10](https://www.w3.org/WAI/WCAG21/quickref/#section-headings) and [H42](https://www.w3.org/TR/WCAG20-TECHS/H42.html) | `design`  | `development` |
-| Contents — Should be meaningful, clear, and concise |  | `design` |  |
-
-## Guidelines and references
-
-- [Web Content Accessibility Guidelines 2.1](https://www.w3.org/TR/WCAG21/)
-- [WebAIM's WCAG 2.0 Checklist](https://webaim.org/standards/wcag/checklist)
-- [A11Y Project Checklist](https://a11yproject.com/checklist)
-
-### PatternFly guidelines
-These are guidelines that we have defined for PatternFly.
-
-#### Experience parity
-  - There should be parity between the screen reader contents and visibly rendered contents (refer to the [first note for aria-hidden](https://www.w3.org/TR/wai-aria/#aria-hidden)).
-  - There should be parity among all input types: touch, mouse, and keyboard.
-      - Don’t optimize the experience for one input type at the expense of another.
-      - Contents that a user can interact with using a mouse are also accessible using touch or keyboard.
-      - Don’t show interactive elements on hover. Interactive elements that can display in a popup must display on click/touch/Enter events.
-  - There should be parity between hover and focus events.
-      - Any information that’s available on hover for the mouse user should be available on focus for the keyboard-only user, and also available to the screen reader user using `aria-describedby` (refer to [Tooltips & Toggletips example from Inclusive Components](https://inclusive-components.design/tooltips-toggletips/)).
-
-## Techniques
-
-The [WCAG 2.0 techniques](https://www.w3.org/TR/WCAG20-TECHS/Overview.html#contents) provide examples on how to meet accessibility guidelines. Any techniques that are adopted as standard within PatternFly for handling specific patterns are included below.
-
-### Labels and accessible names
-
-- #### Form fields
-  - Use explicit linking between `label` and form input elements (e.g. `input`, `textarea`, or `select`) when both elements are present. Aside from providing an accessible name to screen readers, this method also increases the clickable area of the form element by making the label clickable, too. ([H44](https://www.w3.org/TR/WCAG20-TECHS/H44.html))
-  - When a `label` element cannot accompany a form input element:
-      - Provide the label using `aria-label` or `aria-labelledby`. ([ARIA14](https://www.w3.org/TR/WCAG20-TECHS/ARIA16.html))
-      - In a single-field form, the submit button label can serve as the field label for sighted users ([G167](https://www.w3.org/TR/WCAG20-TECHS/general.html#G167)) as well as assistive devices when using `aria-labelledby`
-- #### Landmark roles
-  - Screen reader users can navigate to sections of a page when [landmark roles](https://www.w3.org/TR/wai-aria-1.1/#landmark_roles) are used. Whenever a landmark role is used more than once, provide a name using `aria-label` or `aria-labelledby` to provide context for that landmark. ([ARIA6](https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html), [ARIA16](https://www.w3.org/TR/WCAG20-TECHS/ARIA16.html))
-  - While [`toolbar`](https://www.w3.org/TR/wai-aria-1.1/#toolbar) is not a landmark role, the same rule applies to this role.
-- #### Icons
-  Icons can either be decorative or semantic. Icons are **decorative** if you can remove an icon without affecting the information that is presented on the page. Icons are **semantic** when they provide information that otherwise isn't present, such as indicating status, indicating type of alert message, or replacing text as button labels. When an icon is semantic, the meaning must be provided in alternative ways to the user. The following guidelines should be followed when using icons within PatternFly components.
-  - Add `aria-hidden="true"` for all icons, either to the icon element or a parent element of the icon. This renders the icon as something that assistive devices can ignore.
-  - Additionally, for **semantic** icons:
-      - Add a label for the icon in tooltip text that displays on hover, and also on focus for focusable elements.
-      - For interactive elements like `<a>` and `<button>` where an icon is used as the label instead of text, provide the label on the interactive element using `aria-label`. For example:
-      ```html noLive
-      <button class="..." aria-label="Close dialog">
-        <i class="..." aria-hidden="true"></i>
-      </button>
-      ```
-      - For non-interactive icons, include `.pf-screen-reader` text near the icon. Depending on the component, the `.pf-screen-reader` text might not be a direct sibling to the icon element. For example, in the alert component, the icon label text is adjacent to the message. This way, when `role="alert"` is added to `.pf-c-alert__body` for dynamically displayed alerts, the type of message is announced along with the message text.
-      ```html noLive
-      <div class="pf-c-alert pf-m-success" aria-label="Success alert">
-        <div aria-hidden="true" class="pf-c-alert__icon">
-          <i class="fas fa-check-circle"></i>
-        </div>
-        <div class="pf-c-alert__body">
-          <h4 class="pf-c-alert__title">
-            {{#> screen-reader}}Success:{{/screen-reader}} Success alert title
-          </h4>
-        </div>
-      </div>
-      ```
-
-
-### Trapping focus
-The recommended interaction pattern for the modal components like the modal or popover is to trap focus within the modal element of the component when it becomes visible. For keyboard-only users that use the tab key to navigate the interface, this means that focus cannot be shifted outside of the modal when using the tab key. Instead, when focus leaves the last focusable item, it should be placed on the first focusable item of the modal. For screen reader users, the other contents on the page should be hidden from the screen reader. 
-
-The method we recommend <a href="#testing">based on the screen reader / browser combinations we use for testing</a> is to apply `aria-hidden="true"` to the parent wrapping element of the page contents. Note that the modal element of the component must not be a descendent of this element with `aria-hidden="true"` and should be included as a sibling to this element.
-
-
-
-## Testing
-Many accessibility issues can be found by doing a few simple checks:
-
-1. Use an accessibility audit tool to check for violations. If you are using PatternFly in your project, we recommend using [aXe: The Accessibility Engine](https://www.deque.com/axe/) to check for accessibility violations. If you are contributing to PatternFly, refer to our [README.md](https://github.com/patternfly/patternfly/blob/main/README.md#testing-for-accessibility) on how to run this tool.
-2. Test keyboard accessibility, and check that these requirements are met:
-    - All functionality is keyboard accessible
-    - Order of elements in the HTML and in the layout follow a logical order
-    - Elements with focus are clearly visible
-3. Disable styles, then test the information architecture and presence of adequate text labels. The [WAVE browser extension from WebAIM](https://wave.webaim.org/extension/) provides this feature if it isn't available in the browser you are using. 
-4. Test with any screen reader available in your operating system. Screen readers that we target for testing PatternFly are:
-    - JAWS with Chrome, Windows ([keyboard shortcuts](https://dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts))
-    - Voiceover with Safari, Mac ([keyboard shortcuts](https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts))
-    - NVDA with Firefox, Windows ([keyboard shortcuts](https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts))
-5. Check color contrast for:
-    - Text color against background color ([Understanding WCAG 1.4.3](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))
-    - Text color against link color ([Technique G183](https://www.w3.org/TR/WCAG20-TECHS/G183.html))
-    - Visible boundaries of buttons and form elements against adjacent background color ([Understanding WCAG 1.4.11](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html))

package/docs/pages/contribution.md

@@ -1,109 +0,0 @@
----
-id: contribution
-title: Contribution guidelines
----
-
-## Component, layout, demo creation
-### Naming blocks
-
-Components, layouts, and demos (blocks) should be in individual folders named using Pascal case (AaaBbb). This is the name that will appear in the navigation of the workspace.
-Example: `Button`, `SecondaryNav`
-
-### Handlebars names
-
-The main handlebars file for a block should be named using kebab case. For example, the secondary navigation would be made up of `secondary-nav.hbs` with elements defined in `secondary-nav-item.hbs` and `secondary-nav-link.hbs`.
-
-### Handlebars utilities
-| Property | Usage                                                          | Example
-| ------------ | --------------------------------------------------- | -------------
-| `uniqueId`   | Creates a unique id | badge-{{uniqueId}}
-| `concat`   | Join multiple strings or variables together |  {{concat 'Hello' ' world' '!!!'}} results in Hello world!!!
-| `contains` | Tests to see if a string contains another string | &lbrace;&lbrace;#contains alert--modifier 'pf-m-amazingmodifier'&rbrace;&rbrace;<br />&nbsp;&nbsp;&lt;span&gt;Text&lt;/span&gt;<br />&lbrace;&lbrace;else&rbrace;&rbrace;<br />&nbsp;&nbsp;&lt;span&gt;Alternate text&lt;/span&gt;<br />&lbrace;&lbrace;/contains&rbrace;&rbrace;
-
-## Documentation
-For each example you should provide the relevant accessibility and usage guidance as well as any additional notes that could be helpful. Any information that is not specific to an example should be included at the bottom of the page.
-
-A good example of this approach is the [table component](/components/table).
-
-## Modifiers
-### Modifier parameter
-
-Every block and element should have a parameter allowing for modifier classes and attributes to be passed in. These should be named in kebab case with the block/element name plus `--modifier` and `--attribute` respectively.
-For example:
-
-```html noLive
-<!-- Component definition -->
-<div class="pf-c-grid{{#if grid--modifier}} {{grid--modifier}}{{/if}}"
-  {{#if grid--attribute}}
-    {{{grid--attribute}}}
-  {{/if}}>
-  {{> @partial-block}}
-</div>
----
-<!-- Using the component in handlebars -->
-{{#> grid grid--modifier="pf-m-gutter" grid--attribute='id="grid-id" aria-label="Grid usage example"'}}
-  [content]
-{{/grid}}
-```
-
-When including a partial within a partial, by default, handlebars will pass along the parent context to it's children. This would mean the value of any property specified by the parent is also used by the children.
-
-If there is a possibility of a block nested inside another block of the same type and you want to isolate that nested block, add a new context. For example - see how the nested box is defined below with 'newcontext' added as an attribute:
-
-```html noLive
-{{#> grid grid--modifier="pf-m-gutter" grid--attribute='id="base-grid" aria-label="Base grid"'}}
-  {{#> grid-item grid-item--modifier="pf-m-6-col" grid-item--attribute='id="base-grid-item" aria-label="Base grid item"'}}
-    {{#> grid newcontext}}
-      {{#> grid-item}}
-        (nested grid and grid-item will not inherit --modifier or --attribute values)
-      {{/grid-item}}
-    {{/grid}}
-  {{/grid-item}}
-{{/grid}}
-```
-
-### Common modifier class names
-
-Modifier classes help us to create variations of blocks. Reuse names as much as possible to avoid confusion.
-
-| Modifier class name | Outcome                                                             |
-| ------------------- | ------------------------------------------------------------------- |
-| `pf-m-gutter`   | Adds vertical (if applicable) and horizontal gutters to the element |
-
-
-## Pull request guidelines
-
-In order to streamline reviews and set expectations, the following should be expected when submitting a pull request:
-
- - All pull requests should have an issue that the work relates to.
-
- - A single reviewer should follow the PR through from start to finish after it has been submitted - if somebody else needs to follow it through to completion, please make that transition clear in the PR comments.
-
- - As much as possible, comments should be actionable. It should be clear to the contributor exactly what needs to change. If there are open questions that require in-depth conversation, consider meeting or using [slack](http://slack.patternfly.org) to quickly arrive at an actionable conclusion.
-
- - If the main issue has been addressed but there is still work that arises from the PR, please open an issue with the necessary information (and referencing this original PR) to follow up on afterwards.
-
- - The reviewer should consider the following as they review:
-    1) Have all css naming conventions been followed?
-    2) Have the classes been documented?
-    3) Are all variables declared locally and referencing global defaults?
-    4) Have you verified the examples match the design?
-    5) Does the responsive behavior work correctly?
-    6) Have the accessibility standards been followed?
-    7) Is the example resilient - if you put more content in it, do things start to break?
-
-
-## Adding a custom icon
-
-Below are the steps for adding a custom icon to the [pficon icons](/icons) icon font. Adding this icon in core will also add the icon to the [react-icons](https://github.com/patternfly/patternfly-react/tree/main/packages/react-icons) library as an SVG.
-
-- Get the new source SVG from design.
-- Edit `src/icons/definitions/pf-icons.json` to add the new icon.
-  - Add a new entry with a unique name (placed in alphabetical order) and the height, width, and path from the source SVG.
-- Remove the existing pficons SVGs from `src/icons/PfIcons/`. Any files there are just used to build the icon font.
-- Run `npm run build:pficons` to create the SVGs (stored in `src/icons/PfIcons/`) from `pf-icons.json` that will be used to build the icon font.
-- Run `npm run build:pficonfont` to build the icon font files (stored in `src/patternfly/assets/pficon/`) from the SVGs in `src/icons/PfIcons/`.
-- Edit `src/patternfly/assets/pficon/pficon.scss` and prefix the `src: url()` paths for the icon font files with the global icon font path (e.g., `url('#{$pf-global--fonticon-path}/pficon.woff2')`).
-- Run `./scripts/iconList.sh` to update `src/site/pages/icons.md`, which serves the pficon icon preview page on the dev server served at `/icons`.
-- Restart the dev server and verify the icons look correct on `/icons`.
-  - **Note**: This step may require clearing your cache.

package/docs/pages/guidelines.md

@@ -1,367 +0,0 @@
----
-id: Guidelines
----
-
-Please enforce these guidelines at all times. Small or large, call out what's incorrect.
-
-Every line of code should appear to be written by a single person, no matter the number of contributors.
-
-This set of rules generate some constraints and conventions. If you run into instances where a convention isn’t obvious or a solution could be handled in a few different ways, contact the PatternFly community, have a conversation about how to handle it and update this guidelines when needed.
-
-## Separation of UI structure concerns
-
-PatternFly is made out of isolated and modular structures that fall into 2 categories:
-
-- Layouts
-- Components
-
-### Layouts
-
-Layouts are the containers that allow for organizing and grouping its immediate children on the page.
-
-- A layout never imposes padding or element styles on its children.
-
-The classes are prefixed with `-l` (after the PatternFly prefix `pf-`), for example: `.pf-l-split` or `.pf-l-stack`.
-
-### Components
-
-Components are modular and independent structures concerned with how a thing looks.
-
-- A component always touches all four sides of its parent container.
-- The component itself never has widths, floats or margins.
-- The first element in a component should never use top margins and should touch the top of its component.
-- Components should include semantic markup and necessary ARIA tags to implement the [accessibility guidelines](/accessibility-guide).
-
-The parent container of a component is prefixed with `-c` (after the PatternFly prefix `pf-`), for example: `.pf-c-alert` or `.pf-c-button`.
-
-### When to create a new component
-
-As a general rule, create an extension to an element with BEM modifiers if it’s a change of color or scale. If the change generates a new entity, then create a new component.
-
-Repetition is better than the wrong abstraction.
-
-## Additional features
-
-### Utilities
-
-PatternFly is made up of isolated components that don't allow dependencies. Therefore, the use of helpers or utility classes is discouraged.
-
-However, from time to time it is recognized that an exception to the PatternFly styling may be needed for a special case. For those instances, utility classes are supplied to assist in allowing minor styling changes without creating the need for adding custom CSS.
-
-A utility class is prefixed with `-u` (after the PatternFly prefix `pf-`), for example: `.pf-u-align-content-center`.
-
-### Demos
-
-Demos show how components and layouts can be put together to build more complex structures.
-
-- A demo never includes its own styles. If styling is necessary to implement a desired demo, then new components or layouts, or variants of the components or layouts used, should be created instead.
-- A demo doesn't add any accessibility tags that aren't already in the components. All accessibility should be handled at the component level.
-
-## Variables
-
-PatternFly follows a two-layer theming system where **global variables** always inform **component variables**. Each one of those layers follow a set of very specific rules.
-
-### Global variables
-
-The main reason to have global variables is to maintain consistency. They adhere to the following rules:
-
-- They are prefixed with the word `global` and follow the formula `--pf-global--concept--PropertyCamelCase--modifier--state`.
-  - a `concept` is something like a `spacer` or `main-title`.
-  - a `PropertyCamelCase` is something like `BackgroundColor` or `FontSize`.
-  - a `modifier` is something like  `sm`, or `lg`.
-  - and a `state` is something like  `hover`, or `expanded`.
-- They are concepts, never tied to an element or component. This is incorrect: `--pf-global--h1--FontSize`, this is correct: `--pf-global--FontSize--3xl`.
-
-For example a global variable setup would look like:
-
-```scss
-  // --pf-global--concept--size
-  --pf-global--spacer--lg: .5rem;
-  --pf-global--spacer--xl: 1rem;
-  --pf-global--spacer--2xl: 2rem;
-
-  // --pf-global--PropertyCamelCase--modifier
-  --pf-global--FontSize--3xl: 2rem;
-  --pf-global--FontSize--2xl: 1.8rem;
-  --pf-global--FontSize--lg: 1rem;
-
-  // --pf-global--PropertyCamelCase--state
-  --pf-global--link--TextDecoration--hover: #ccc;
-
-  // --pf-global--PropertyCamelCase--modifier
-  --pf-global--Color--100: #000;
-
-  // --pf-global--concept--modifier
-  --pf-global--primary-color--100: #00f;
-```
-
-### Component variables
-
-The second layer is scoped to themeable component custom properties. This setup allows for consistency across components, generates a common language between designers and developers, and gives granular control to authors. The rules are as follows:
-
-- They follow this general formula `--pf-c-block[__element][--modifier][--state][--breakpoint][--pseudo-element]--PropertyCamelCase`.
-  - `--pf-c-block` refers to the block, usually the component or layout name (i.e., `--pf-c-alert`).
-  - `__element` refers to the element inside of the block (i.e., `__title`).
-  - `--modifier` refers to a modifier class such as `.pf-m-danger`, and is prefixed with `m-` in the component variable (i.e., `--m-danger`).
-  - `--state` is something like `hover` or `active`.
-  - `--breakpoint` is a media query breakpoint such as `sm` for `$pf-global--breakpoint--xs`.
-  - `--pseudo-element` is one of either `before` or `after`.
-- The value of a component variable is **always** defined by a global variable.
-- It's possible to include multiple elements, modifiers, states, and breakpoints in a single component variable.
-- The order of elements, modifiers, states, and breakpoints in the variable name should match the selector order.
-
-For example:
-
-```scss
-// Component scoped variables are always defined by global variables
---pf-c-alert--Padding: var(--pf-global--spacer--xl);
---pf-c-alert--hover--BackgroundColor: var(--pf-global--BackgroundColor--200);
---pf-c-alert__title--FontSize: var(--pf-global--FontSize--2xl);
-
-// --block--PropertyCamelCase
-.pf-c-alert {
-  padding: var(--pf-c-alert--Padding);
-}
-
-// --block--state--PropertyCamelCase
-.pf-c-alert {
-  &:hover {
-    background-color: var(--pf-c-alert--hover--BackgroundColor);
-  }
-}
-
-// --block__element--PropertyCamelCase
-.pf-c-alert__title {
-  font-size: var(--pf-c-alert__title--FontSize);
-}
-
-// A more complex example
-.pf-c-switch {
-  @media (max-width: $pf-global--breakpoint--sm) {
-    .pf-c-switch__input {
-      &:disabled {
-        ~ .pf-c-switch__toggle {
-          &::before {
-            background-color: var(--pf-c-switch--sm__input--disabled__toggle--before--BackgroundColor);
-          }
-        }
-      }
-    }
-  }
-}
-```
-
-### Comment all magic values
-
-If a situation arises where a value needs entering into the style sheets that isn't already defined in the global variables this should serve as a red flag to you.
-
-In the case where a 'magic' value needs entering, ensure a comment is added on the line above to explain its relevance.
-
-## Harry Robert's Guidelines
-
-PatternFly follows [Harry Robert's CSS Guidelines](https://cssguidelin.es/) with some exceptions, deviations and additions.
-
-### Exceptions
-
-PatternFly doesn't follow these rules:
-
-- [Table of contents](https://cssguidelin.es/#able-of-contents)
-- [Titling](https://cssguidelin.es/#titling)
-- [Anatomy of a Ruleset](https://cssguidelin.es/#anatomy-of-a-ruleset)
-- [Multi-line CSS](https://cssguidelin.es/#multi-line-css)
-- [Indenting](https://cssguidelin.es/#indenting)
-- [Meaningful Whitespace](https://cssguidelin.es/#meaningful-whitespace)
-- [80 Characters Wide](https://cssguidelin.es/#characters-wide)
-
-### Deviations from Harry Robert's Guidelines
-
-#### HTML
-
-**Practicality over purity**. Strive to maintain HTML standards and semantics, but not at the expense of practicality. Use the least amount of markup with the fewest intricacies whenever possible.
-
-#### Comment and organization
-
-Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
-
-Be sure to write in complete sentences for larger comments and succinct phrases for general notes.
-
-Follow this comment structure:
-
-1. Block
-1. Sections
-1. Line
-
-```scss
-// Section level comment
-.selector {
-  line-height: 1.5; // Line level comment
-  color: #333;
-}
-```
-
-##### 1. Section
-
-This comment is a section divider or describes a block of code.
-
-- Leave one blank lines above.
-
-##### 2. Line
-
-Describes a specific line of code.
-
-### Additions to Harry Robert's Guidelines
-
-#### Lintable CSS rules
-
-The [CSS linter](https://stylelint.io/) is PatternFly's single source of truth for CSS syntax, declaration order, and other CSS rules like disallow type selectors, disallow vendor prefixes, and more.
-
-#### Shorthand notation
-
-Limit the use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include:
-
-- `padding`
-- `margin`
-- `font`
-- `background`
-- `border`
-- `border-radius`
-
-```scss
-// Bad
-.element {
-  margin: 0 0 10px;
-  background: #f00;
-  background: url("image.jpg");
-  border-radius: 3px 3px 0 0;
-}
-
-// Good
-.element {
-  margin-bottom: 10px;
-  background-color: #f00;
-  background-image: url("image.jpg");
-  border-top-left-radius: 3px;
-  border-top-right-radius: 3px;
-}
-```
-
-The [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/CSS/Shorthand_properties) and [Harry Robert](https://csswizardry.com/2016/12/css-shorthand-syntax-considered-an-anti-pattern/) both have great articles on shorthand properties for those unfamiliar with notation and behaviour.
-
-### Sass
-
-PatternFly uses [Sass](http://sass-lang.com/) to preprocess CSS.
-
-As a general rule don't overcomplicate Sass, keep it easy to parse for a normal human.
-
-#### Nesting
-
-As a general rule avoid Sass nesting to increase specificity. Try not to nest more than three layers deep.
-
-Limit nesting to the following use cases:
-
-1. Modifiers
-1. Media queries
-1. States, pseudo-classes, and pseudo-elements
-1. Combinators
-
-##### 1. Modifiers and elements of a block
-
-* Do not use [Sass's parent selector](https://css-tricks.com/the-sass-ampersand/) mechanism to construct BEM elements.
-* Do use that method to create compound selectors with modifier classes.
-
-```scss
-// Good
-.pf-nav {
-  // styles
-
-  &.pf-m-vertical {
-    // styles
-  }
-}
-
-.pf-nav__item {
-  // styles
-}
-
-// Bad
-.pf-nav {
-  // styles
-
-  &__item {
-    // styles
-  }
-}
-
-.pf-m-nav.pf-m-vertical {
-  // styles
-}
-```
-
-##### 2. Media queries
-
-Component-specific media queries should be nested inside the component block. Remember that PatternFly is mobile first. **Do progressive enhancement, not gracefully degradation.**
-
-PatternFly has 5 breakpoints:
-
-```scss
-  $pf-global-breakpoint--xs: 0;
-  $pf-global-breakpoint--sm: 576px;
-  $pf-global-breakpoint--md: 768px;
-  $pf-global-breakpoint--lg: 992px;
-  $pf-global-breakpoint--xl: 1200px;
-```
-
-To make sure you are writing mobile first, always do `min-width`:
-
-```scss
-.pf-nav {
-  // mobile styles
-
-  // Styles for small view ports and up
-  @media (min-width: $pf-global-breakpoint--xs) {
-    // non-mobile styles
-  }
-}
-```
-
-##### 4. States, pseudo-classes and pseudo-elements
-
-States of a component should be included as a nested element. This includes hover, focus, and active states:
-
-```scss
-.pf-c-button {
-  background: var(--pf-c-button--Background);
-
-  &:hover {
-    background: var(--pf-c-button--hover--Background);
-  }
-}
-```
-
-
-#### Sass variables
-
-We create global Sass variables to keep a Bootstrap theme in sync. These values also inform our component level variables.
-
-#### @mixin and @extend
-
-Since our components are isolated and modular try to avoid `@mixin` and `@extend` because they generate a dependency.
-
-#### Nested calc() functions
-
-There is currently a bug in cssnano ([issue #64 on postcss-calc](https://github.com/postcss/postcss-calc/issues/64)) that causes nested `calc()` CSS functions to be removed. So a function like `calc(5 * calc(3 - 1))` becomes `calc(5 * 3 - 1)`. It's worth noting that this problem only impacts our distribution package. Nested `calc()` functions work fine in the development environment.
-
-PatternFly developers should avoid nested `calc()` CSS functions until this bug is resolved and the package is updated in the [patternfly repository](https://github.com/patternfly/patternfly). If you're interested in following this issue, you can do so in [issue #1295 on patternfly](https://github.com/patternfly/patternfly/issues/1295).
-
-#### Hover styles
-
-While the default styles applied to an element might not provide a visual indication of target area, the styles that display on hover should. To ensure that these styles accurately convey the target area of an element where the user can click, `:hover` styles should be applied to the clickable element of a component, and not to a larger wrapping element.
-
-## References
-
-This guide is inspired by people we follow and respect:
-
-- **[Mark Otto](http://markdotto.com/):** [Code Guideline](http://codeguide.co/)
-- **[Robert Harris](http://csswizardry.com/):** [CSS Guidelines](http://cssguidelin.es/)
-- **[Gravity Department](http://gravitydept.com/)**: [Style Guide Field Manual](http://manuals.gravitydept.com/code/css/style-guide)
-- **[Kitty Giraudel](http://kittygiraudel.com/):** [SASS Guidelines](https://sass-guidelin.es/)