@workday/canvas-kit-docs 7.0.0-alpha.90-next.17 → 7.0.0-alpha.91-next.18

package/dist/mdx/react/button/button/Button.mdx

@@ -39,7 +39,7 @@ action. Multiple primary buttons make it confusing for the user to understand wh
 should take. Not all screens require a Primary Button.
 
 Primary Buttons have four sizes: `extraSmall`, `small`, `medium`, and `large`. Icons are supported
-for every size and can be positioned to the `left` or `right` with the `iconPosition` prop.
+for every size and can be positioned at the `start` or `end` with the `iconPosition` prop.
 
 <ExampleCodeBlock code={Primary} />
 
@@ -62,7 +62,7 @@ Buttons can be used on most pages without restrictions and work well for multipl
 weight. They can be used in conjunction with a Primary Button or independently.
 
 Secondary Buttons have four sizes: `extraSmall`, `small`, `medium`, and `large`. Icons are supported
-for every size and can be positioned to the `left` or `right` with the `iconPosition` prop.
+for every size and can be positioned at the `start` or `end` with the `iconPosition` prop.
 
 <ExampleCodeBlock code={Secondary} />
 
@@ -85,7 +85,7 @@ not visible until it is interacted with. Use Tertiary Buttons for supplemental a
 More”, “Read More” or “Select a File”. Tertiary Buttons are frequently used on Cards.
 
 Tertiary Buttons have three sizes: `extraSmall`, `small`, and `medium`. Icons are supported for
-every size and can be positioned to the `left` or `right` with the `iconPosition` prop.
+every size and can be positioned at the `start` or `end` with the `iconPosition` prop.
 
 <ExampleCodeBlock code={Tertiary} />
 

package/dist/mdx/react/color-picker/color-input/ColorInput.mdx

@@ -105,12 +105,12 @@ standards.
 
 <ExampleCodeBlock code={Error} />
 
-## Props
+## Color Input Props
 
 Undocumented props are spread to the underlying `<input type="text">` element.
 
 <ArgsTable of={ColorInput} />
 
-## Specifications
+## Color Input Specifications
 
 <Specifications file="ColorPicker.spec.ts" name="ColorInput" />

package/dist/mdx/react/color-picker/color-preview/ColorPreview.mdx

@@ -42,12 +42,12 @@ relative to the Color Preview. `labelPosition` accepts the following values:
 
 <ExampleCodeBlock code={LabelPosition} />
 
-## Props
+## Color Preview Props
 
 Undocumented props are spread to the underlying `<input type="text">` element.
 
 <ArgsTable of={ColorPreview} />
 
-## Specifications
+## Color Preview Specifications
 
 <Specifications file="ColorPicker.spec.ts" name="ColorPreview" />

package/dist/mdx/react/layout/Flex.mdx

@@ -6,27 +6,38 @@ import Usage from './examples/Flex/Usage';
 import {FlexStyle} from './examples/PropTables.splitprops.tsx';
 
 
-# Flex
+# Canvas Kit Flex
 
 `Flex` is a low-level layout component that provides a common, ergonomic API for building
 one-dimensional layouts with
 [CSS Flexbox](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Flexbox).
 
-## Table of Contents
+## Installation
 
-- [Flex](#flex)
-  - [Table of Contents](#table-of-contents)
-  - [Usage](#usage)
-  - [What's the difference between `Flex` and `Box`?](#whats-the-difference-between-flex-and-box)
-  - [Flex Props](#flex-props)
-  - [Examples](#examples)
-  - [Exhaustive Prop List](#exhaustive-prop-list)
+```sh
+yarn add @workday/canvas-kit-react
+```
 
 ## Usage
 
+### Basic Example
+
 <ExampleCodeBlock code={Usage} />
 
-## What's the difference between `Flex` and `Box`?
+### Rows and Columns
+
+You can nest `Flex` components to build layouts with rows and columns.
+
+<ExampleCodeBlock code={FlexLayout} />
+
+### Small Containers
+
+You can also use `Flex` to create layouts within smaller containers, such as this card example
+below:
+
+<ExampleCodeBlock code={FlexCard} />
+
+### Flex vs. Box
 
 `Flex` is built with `Box` and has access to all `BoxProps`. The main differences between `Box` and
 `Flex` are:
@@ -49,17 +60,6 @@ through style props as well. There are seven flex container props:
 
 <ArgsTable of={FlexStyle} />
 
-## Examples
-
-You can nest `Flex` components to build layouts with rows and columns.
-
-<ExampleCodeBlock code={FlexLayout} />
-
-You can also use `Flex` to create layouts within smaller containers, such as this card example
-below:
-
-<ExampleCodeBlock code={FlexCard} />
-
-## Exhaustive Prop List
+### Flex Props (Exhaustive List)
 
 <ArgsTable of={Flex} />

package/dist/mdx/react/layout/Stack.mdx

@@ -9,7 +9,7 @@ import HStackCards from './examples/Stack/HStackCards';
 import VStackCards from './examples/Stack/VStackCards';
 
 
-# Stack, HStack, and VStack
+# Canvas Kit Stack
 
 `Stack`, `HStack`, and `VStack` are higher-level layout components that provide an ergonomic API for
 building one-dimensional layouts with consistent spacing between elements. They're built on top of
@@ -17,48 +17,13 @@ building one-dimensional layouts with consistent spacing between elements. They'
 horizontal or vertical orientation. `HStack` and `VStack` will only align items in a horizontal or
 vertical orientation, respectively.
 
-## Table of Contents
-
-- [Stack, HStack, and VStack](#stack-hstack-and-vstack)
-  - [Table of Contents](#table-of-contents)
-  - [Stack](#stack)
-    - [Usage](#usage)
-    - [What Stack Is & Isn't](#what-stack-is--isnt)
-    - [Setting Direction](#setting-direction)
-    - [Setting Space](#setting-space)
-    - [Managing Child Elements](#managing-child-elements)
-      - [Basic Usage](#basic-usage)
-      - [Using `shouldWrapChildren`](#using-shouldwrapchildren)
-      - [Using `Stack.Item`](#using-stackitem)
-    - [Valid Children](#valid-children)
-    - [Examples](#examples)
-  - [HStack](#hstack)
-    - [Usage](#usage-1)
-    - [Example](#example)
-  - [VStack](#vstack)
-    - [Usage](#usage-2)
-    - [Example](#example-1)
-  - [Exhaustive Prop List](#exhaustive-prop-list)
-
-## Stack
+## Installation
 
-`Stack` is a composable component that's helpful for creating layouts with equal spacing between
-elements. It can create horizontal or vertical stacks of elements.
-
-### Usage
-
-```tsx
-import {Stack, StackStyleProps} from '@workday/canvas-kit-react/layout';
+```sh
+yarn add @workday/canvas-kit-react
 ```
 
-### What Stack Is & Isn't
-
-The most important distinction to make with `Stack` is that it is _not a grid._ Grid components are
-able to align items along two dimensions (rows and columns), and `Stack` is only built to support
-one dimension (rows _or_ columns). That said, you can nest horizontal and vertical `Stack`
-components to create grid-like layouts.
-
-### Thinking in Stacks
+## Usage
 
 `Stack` is a higher-level layout component, meaning:
 
@@ -67,14 +32,39 @@ components to create grid-like layouts.
 
 `Stack` has three core opinions that guide its API:
 
-- space should be equal between child elements
-- space should only exist between child elements
-- children should be semantic elements
+- Space should be equal between child elements
+- Space should only exist between child elements
+- Children should be semantic elements
 
 Much of layout design is founded on these opinions. Whether its creating lists of navigation links,
 groups of cards, or collections of buttons, once you think in stacks, you'll see them everywhere.
 
-### Setting Direction
+### Basic Example
+
+`Stack` is a composable component that's helpful for creating layouts with equal spacing between
+elements. It can create horizontal or vertical stacks of elements.
+
+> The most important distinction to make with `Stack` is that it is _not a grid._ Grid components
+> are able to align items along two dimensions (rows and columns), and `Stack` is only built to
+> support one dimension (rows _or_ columns). That said, you can nest horizontal and vertical `Stack`
+> components to create grid-like layouts.
+
+`Stack` uses CSS pseudo-classes to apply margin to child elements. This makes it really simple to
+get consistent spacing between child elements without much manual effort. Below is a basic example.
+Note that `Stack` does not add any space above or below the child elements. This helps your element
+fit nicely within their containers.
+
+<ExampleCodeBlock code={BasicStack} />
+
+Use this approach when:
+
+- You want consistent space between child elements
+- You don't need to apply custom margin to child elements
+  - Specifically `marginLeft`/`marginInlineStart` for horizontal stacks and `marginTop` for vertical
+    stacks
+- You don't want to add extra markup to wrap child elements
+
+#### Setting Direction
 
 The direction of the child elements is set with the `flexDirection` prop. This prop supports four
 directions: `column`, `column-reverse`, `row`, and `row-reverse`. By default, it will set the
@@ -86,7 +76,7 @@ direction to `row` as is consistent with the CSS Flexbox spec.
 > Note: `spacing` also supports bidirectionality automatically. This means you don't need to think
 > about it for localization as long as you properly pass the `direction` to the `theme` object un
 
-### Setting Space
+#### Setting Space
 
 The space between child elements is set with the `spacing` prop, which supports all space token and
 string values. `Stack` intentionally only sets space between elements and never outside. For
@@ -94,13 +84,13 @@ example: a vertical stack of three elements would only have margin added to the
 and third child elements. Keeping space between elements makes building layouts more block-like and
 predictable.
 
-### Managing Child Elements
+#### Managing Child Elements
 
 There are three ways to manage space between child elements with `Stack`.
 
-- implicit spacing applied directly to child elements (default behavior)
-- implicit wrapping child elements with `shouldWrapChildren`
-- explicit wrapping child elements with `Stack.Item`s.
+- Implicit spacing applied directly to child elements (default behavior)
+- Implicit wrapping child elements with `shouldWrapChildren`
+- Explicit wrapping child elements with `Stack.Item`s.
 
 Each approach has its own benefits and limitations, which are discussed in further detail below. We
 chose to implicitly apply spacing to child elements as the default behavior because it requires the
@@ -109,77 +99,7 @@ hatches for when the default behavior becomes forced. Should you find none of th
 for your use case, we recommend using `Flex` instead of `Stack`, which will provide you with more
 flexibility.
 
-#### Basic Usage
-
-`Stack` uses CSS pseudo-classes to apply margin to child elements. This makes it really simple to
-get consistent spacing between child elements without much manual effort. Below is a basic example.
-Note that `Stack` does not add any space above or below the child elements. This helps your element
-fit nicely within their containers.
-
-<ExampleCodeBlock code={BasicStack} />
-
-Use this approach when:
-
-- you want consistent space between child elements
-- you don't need to apply custom margin to child elements
-  - specifically `marginLeft`/`marginInlineStart` for horizontal stacks and `marginTop` for vertical
-    stacks
-- you don't want to add extra markup to wrap child elements
-
-A side-effect of `Stack`'s pseduo-classes is an increased style specificity. This specificity can
-override the child element's margin styles. If that creates a problem, there are two recommended
-options available:
-
-- Use the `shouldWrapChildren` prop (implicit option)
-- Use `Stack.Item` (explicit option)
-
-Both are discussed below.
-
-#### Using `shouldWrapChildren`
-
-The `shouldWrapChildren` prop will implicitly wrap each child in a `Stack.Item` component (which is
-a `Box`) and apply the margin to it instead of the child element provided. This allows you to
-control the margin of the child elements you provide and avoiding style collisions. The trade-off is
-that you do not have direct access to the `Stack.Item` being rendered. If having access to that
-element is necessary, using `Stack.Item` explicitly (as described below) could be the best solution.
-
-The example below is a bit contrived but has enough information to convey the point. In this
-scenario, we have a horizontal stack of `SecondaryButton`s that render an icon, but they are
-visually divided into separate groupings. The navigational buttons are on the left, and the
-additional actions are spaced slightly further to the right. You could use two separate horizontal
-stacks here to achieve the same result, but you could also use `shouldWrapChildren` and then put
-additional margin only where needed. Either approach would be fine; it's a matter of personal
-preference.
-
-<ExampleCodeBlock code={ShouldWrapChildren} />
-
-Use this approach when:
-
-- you want consistent space between child elements
-- you need to apply custom margin to particular children
-- wrapping each child element won't create issues with other semantic elements
-- you don't want to explicitly add extra markup to wrap child elements
-
-#### Using `Stack.Item`
-
-Sometimes inserting implicit wrapper elements can be problematic when you need access to those
-elements. In those situations, `shouldWrapChildren` is not the best choice, and you should opt for
-wrapping children in `Stack.Item`s. A `Stack.Item` is a `Box` with some preset styles which can be
-overridden if needed.
-
-In the example below, we wanted to keep our `li` elements as direct children of the `ul` stack. So
-we're wrapping each of the links with `Stack.Item`s, casting them as `li`s and applying custom
-styles to each. This would not be possible with `shouldWrapChildren`.
-
-<ExampleCodeBlock code={StackItems} />
-
-Use this approach when:
-
-- you want consistent space between child elements
-- you need to have direct access to `Stack.Item` wrappers
-- wrapping each child element won't create issues with other semantic elements
-
-### Valid Children
+#### Valid Children
 
 Because `Stack` applies styles to children, it requires its immediate children to be valid child
 elements. For example, text outside of an HTML tag would not render if it was an immediate `Stack`
@@ -197,18 +117,20 @@ const ValidChildrenExample = () => {
 };
 ```
 
-### Examples
+### Grid-like Layouts
 
 You can nest vertical and horizontal `Stack`s to create grid-like layouts. Here are three horizontal
 `Stack`s nested within a vertical `Stack`. The fourth row is a single `Flex` component.
 
 <ExampleCodeBlock code={NestedStacks} />
 
+### Small Containers
+
 You can also use `Stack` to manage smaller layouts, such as within Cards.
 
 <ExampleCodeBlock code={StackCard} />
 
-## HStack
+### HStack
 
 `HStack` works identically to `Stack` but is limited to only `row` and `row-reverse` directions. It
 defaults to `row` if no `flexDirection` is provided.
@@ -217,35 +139,72 @@ defaults to `row` if no `flexDirection` is provided.
 > the direction or spacing for localization. The direction switching is handled by the CSS Flexbox
 > spec, and the spacing will flip direction based on the `direction` provided in the `theme` object.
 
-### Usage
-
-```tsx
-import {HStack, HStackStyleProps} from '@workday/canvas-kit-react/layout';
-```
-
-### Example
-
 In this example, `HStack` is placing three cards in a row with small spacing between them.
 
 <ExampleCodeBlock code={HStackCards} />
 
-## VStack
+### VStack
 
 `VStack` works identically to `Stack` but is limited to only `column` and `column-reverse`
 directions. It defaults to `column` if no `flexDirection` is provided.
 
-### Usage
+In this example, `VStack` is placing three cards in a column with small spacing between them.
 
-```tsx
-import {VStack, VStackStyleProps} from '@workday/canvas-kit-react/layout';
-```
+<ExampleCodeBlock code={VStackCards} />
 
-### Example
+### shouldWrapChildren and Stack.Item
 
-In this example, `VStack` is placing three cards in a column with small spacing between them.
+A side-effect of `Stack`'s pseudo-classes is an increased style specificity. This specificity can
+override the child element's margin styles. If that creates a problem, there are two recommended
+options available:
 
-<ExampleCodeBlock code={VStackCards} />
+- Use the `shouldWrapChildren` prop (implicit option)
+- Use `Stack.Item` (explicit option)
+
+#### shouldWrapChildren
+
+The `shouldWrapChildren` prop will implicitly wrap each child in a `Stack.Item` component (which is
+a `Box`) and apply the margin to it instead of the child element provided. This allows you to
+control the margin of the child elements you provide and avoiding style collisions. The trade-off is
+that you do not have direct access to the `Stack.Item` being rendered. If having access to that
+element is necessary, using `Stack.Item` explicitly (as described below) could be the best solution.
+
+The example below is a bit contrived but has enough information to convey the point. In this
+scenario, we have a horizontal stack of `SecondaryButton`s that render an icon, but they are
+visually divided into separate groupings. The navigational buttons are on the left, and the
+additional actions are spaced slightly further to the right. You could use two separate horizontal
+stacks here to achieve the same result, but you could also use `shouldWrapChildren` and then put
+additional margin only where needed. Either approach would be fine; it's a matter of personal
+preference.
+
+<ExampleCodeBlock code={ShouldWrapChildren} />
+
+Use this approach when:
+
+- You want consistent space between child elements
+- You need to apply custom margin to particular children
+- Wrapping each child element won't create issues with other semantic elements
+- You don't want to explicitly add extra markup to wrap child elements
+
+#### Stack.Item
+
+Sometimes inserting implicit wrapper elements can be problematic when you need access to those
+elements. In those situations, `shouldWrapChildren` is not the best choice, and you should opt for
+wrapping children in `Stack.Item`s. A `Stack.Item` is a `Box` with some preset styles which can be
+overridden if needed.
+
+In the example below, we wanted to keep our `li` elements as direct children of the `ul` stack. So
+we're wrapping each of the links with `Stack.Item`s, casting them as `li`s and applying custom
+styles to each. This would not be possible with `shouldWrapChildren`.
+
+<ExampleCodeBlock code={StackItems} />
+
+Use this approach when:
+
+- You want consistent space between child elements
+- You need to have direct access to `Stack.Item` wrappers
+- Wrapping each child element won't create issues with other semantic elements
 
-## Exhaustive Prop List
+## Stack Props
 
 <ArgsTable of={Stack} />

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@workday/canvas-kit-docs",
-  "version": "7.0.0-alpha.90-next.17+1c0258d7",
+  "version": "7.0.0-alpha.91-next.18+f92b7ba5",
   "description": "Documentation components of Canvas Kit components",
   "author": "Workday, Inc. (https://www.workday.com)",
   "license": "Apache-2.0",
@@ -41,7 +41,7 @@
   ],
   "dependencies": {
     "@storybook/csf": "0.0.1",
-    "@workday/canvas-kit-react": "^7.0.0-alpha.90-next.17+1c0258d7"
+    "@workday/canvas-kit-react": "^7.0.0-alpha.91-next.18+f92b7ba5"
   },
   "devDependencies": {
     "fs-extra": "^10.0.0",
@@ -49,5 +49,5 @@
     "mkdirp": "^1.0.3",
     "typescript": "4.1"
   },
-  "gitHead": "1c0258d72c737b6a42791bad140183c01d736c03"
+  "gitHead": "f92b7ba590e19e7f55f7a6417d0d4b7ae3b1bba4"
 }