diff --git a/packages/@react-aria/button/docs/useToggleButtonGroup.mdx b/packages/@react-aria/button/docs/useToggleButtonGroup.mdx index f46f37cd6e5..983360bb9dd 100644 --- a/packages/@react-aria/button/docs/useToggleButtonGroup.mdx +++ b/packages/@react-aria/button/docs/useToggleButtonGroup.mdx @@ -252,7 +252,7 @@ By default, toggle button groups are horizontally oriented. The orientation prop ``` -## Accessiblity +## Accessibility A `ToggleButtonGroup` can be labeled using the `aria-label` or `aria-labelledby` props. diff --git a/packages/@react-aria/overlays/docs/usePopover.mdx b/packages/@react-aria/overlays/docs/usePopover.mdx index b7187bf2152..1820d926502 100644 --- a/packages/@react-aria/overlays/docs/usePopover.mdx +++ b/packages/@react-aria/overlays/docs/usePopover.mdx @@ -78,7 +78,7 @@ with . The `Popover` component uses an <> to render its contents in a React [Portal](https://reactjs.org/docs/portals.html) at the end of the document body, which ensures it is not clipped by other elements. It also acts as a focus scope, containing focus within the popover and restoring it to the trigger when it unmounts. handles positioning the popover relative to the trigger element, and closing it when the user interacts outside or presses the Escape key. - also hides content outside the popover from screen readers, which is important since the surrounding content won't be in context of the original trigger due to the portal. To allow screen reader users to dismiss the popover without a keyboard (e.g. on mobile), visually hidden <> elements are added at the start and end of the popover. An underlay is also used to prevent scrolling and interacting with elements outside the popover with a pointer, to avoid unintentially repositioning or closing it. + also hides content outside the popover from screen readers, which is important since the surrounding content won't be in context of the original trigger due to the portal. To allow screen reader users to dismiss the popover without a keyboard (e.g. on mobile), visually hidden <> elements are added at the start and end of the popover. An underlay is also used to prevent scrolling and interacting with elements outside the popover with a pointer, to avoid unintentionally repositioning or closing it. ```tsx example export=true render=false import type {AriaPopoverProps} from 'react-aria'; diff --git a/packages/@react-spectrum/autocomplete/docs/SearchAutocomplete.mdx b/packages/@react-spectrum/autocomplete/docs/SearchAutocomplete.mdx index 9649f5426ca..1a55e40e0f6 100644 --- a/packages/@react-spectrum/autocomplete/docs/SearchAutocomplete.mdx +++ b/packages/@react-spectrum/autocomplete/docs/SearchAutocomplete.mdx @@ -234,7 +234,7 @@ See Icon's [labeling](workflow-icons.html#labeling) section and Avatar's [access Mail - Send and recieve emails + Send and receive emails diff --git a/packages/@react-spectrum/filetrigger/docs/FileTrigger.mdx b/packages/@react-spectrum/filetrigger/docs/FileTrigger.mdx index 78af9195adc..5e83c3d440d 100644 --- a/packages/@react-spectrum/filetrigger/docs/FileTrigger.mdx +++ b/packages/@react-spectrum/filetrigger/docs/FileTrigger.mdx @@ -85,7 +85,7 @@ By default, the file trigger will accept any file type. To support only certain ## Multiple files -A file trigger can accept multiple files by passsing the `allowsMultiple` property. +A file trigger can accept multiple files by passing the `allowsMultiple` property. ```tsx example diff --git a/packages/@react-spectrum/icon/docs/custom-icons.mdx b/packages/@react-spectrum/icon/docs/custom-icons.mdx index 3a52da9d4e6..a52edff48e8 100644 --- a/packages/@react-spectrum/icon/docs/custom-icons.mdx +++ b/packages/@react-spectrum/icon/docs/custom-icons.mdx @@ -51,7 +51,7 @@ function CustomIcon(props) { ``` -Wrapping the SVG with Icon will ensure it recieves proper styling when used within React Spectrum components: +Wrapping the SVG with Icon will ensure it receives proper styling when used within React Spectrum components: ```tsx example import {Button, Text} from '@adobe/react-spectrum'; diff --git a/packages/@react-spectrum/progress/docs/ProgressCircle.mdx b/packages/@react-spectrum/progress/docs/ProgressCircle.mdx index 438db581757..061a1b4a401 100644 --- a/packages/@react-spectrum/progress/docs/ProgressCircle.mdx +++ b/packages/@react-spectrum/progress/docs/ProgressCircle.mdx @@ -45,7 +45,7 @@ keywords: [progress circle] ## Value ProgressCircles are controlled with the `value` prop. -By default, the `value` prop represents the current percentage of progress, as the minimum and maxiumum values default to 0 and 100, respectively. +By default, the `value` prop represents the current percentage of progress, as the minimum and maximum values default to 0 and 100, respectively. ```tsx example diff --git a/packages/@react-spectrum/tabs/stories/Tabs.stories.tsx b/packages/@react-spectrum/tabs/stories/Tabs.stories.tsx index a3cb3fc4337..a40a80533f3 100644 --- a/packages/@react-spectrum/tabs/stories/Tabs.stories.tsx +++ b/packages/@react-spectrum/tabs/stories/Tabs.stories.tsx @@ -374,10 +374,10 @@ ChangingTabTitles.story = { name: 'changing tab titles' }; -export const ChangingSelectionProgramatically: TabsStory = () => ; +export const ChangingSelectionProgrammatically: TabsStory = () => ; -ChangingSelectionProgramatically.story = { - name: 'changing selection programatically' +ChangingSelectionProgrammatically.story = { + name: 'changing selection programmatically' }; export const Links: StoryFn & {collapsed?: boolean}> = (args) => { diff --git a/packages/@react-spectrum/tabs/test/Tabs.test.js b/packages/@react-spectrum/tabs/test/Tabs.test.js index cfa024e2d40..46f1a0fa8e1 100644 --- a/packages/@react-spectrum/tabs/test/Tabs.test.js +++ b/packages/@react-spectrum/tabs/test/Tabs.test.js @@ -880,7 +880,7 @@ describe('Tabs', function () { expect(onSelectionChange).toHaveBeenCalledWith(defaultItems[0].name); }); - it('updates the tab index of the selected tab if programatically changed', function () { + it('updates the tab index of the selected tab if programmatically changed', function () { let Example = (props) => ( diff --git a/packages/@react-spectrum/tree/chromatic-fc/TreeView.stories.tsx b/packages/@react-spectrum/tree/chromatic-fc/TreeView.stories.tsx index 135fc8021dc..74e2df5d0c6 100644 --- a/packages/@react-spectrum/tree/chromatic-fc/TreeView.stories.tsx +++ b/packages/@react-spectrum/tree/chromatic-fc/TreeView.stories.tsx @@ -135,6 +135,6 @@ export const DisabledBehaviorAll: TreeViewStoryProps = () => ( ); -export const HiglightSelectionWithDisabledBehaviorAll: TreeViewStoryProps = () => ( +export const HighlightSelectionWithDisabledBehaviorAll: TreeViewStoryProps = () => ( ); diff --git a/packages/@react-types/calendar/src/index.d.ts b/packages/@react-types/calendar/src/index.d.ts index 53df3c72ce1..8d9e1e2381d 100644 --- a/packages/@react-types/calendar/src/index.d.ts +++ b/packages/@react-types/calendar/src/index.d.ts @@ -45,7 +45,7 @@ export interface CalendarPropsBase { autoFocus?: boolean, /** Controls the currently focused date within the calendar. */ focusedValue?: DateValue | null, - /** The date that is focused when the calendar first mounts (uncountrolled). */ + /** The date that is focused when the calendar first mounts (uncontrolled). */ defaultFocusedValue?: DateValue | null, /** Handler that is called when the focused date changes. */ onFocusChange?: (date: CalendarDate) => void, diff --git a/packages/@react-types/card/src/index.d.ts b/packages/@react-types/card/src/index.d.ts index 0c3cb1dae3b..ebd945b6887 100644 --- a/packages/@react-types/card/src/index.d.ts +++ b/packages/@react-types/card/src/index.d.ts @@ -32,7 +32,7 @@ interface LayoutOptions { collator?: Intl.Collator, // TODO: is this valid or is scale a spectrum specific thing that should be left out of the layouts? // Added here so we can keep the default item padding options within the layouts instead of having to - // do extra work in CardView to accomodate different sizing for scales + // do extra work in CardView to accommodate different sizing for scales scale?: Scale } @@ -51,7 +51,7 @@ export interface CardViewLayoutConstructor { } interface CardViewProps extends CollectionBase, MultipleSelection, Omit { - // TODO: Does LayoutContructor and Layout give enough info for a user to know what to put in their own custom layout? + // TODO: Does LayoutConstructor and Layout give enough info for a user to know what to put in their own custom layout? // Replaced with CardViewLayout so that they know they need to have keyboardDelegate stuff as well as collection, disabledKeys, etc layout: CardViewLayoutConstructor | CardViewLayout, // TODO: readd size when we get updated designs from spectrum diff --git a/packages/dev/docs/pages/blog/building-a-button-part-3.mdx b/packages/dev/docs/pages/blog/building-a-button-part-3.mdx index 5d4ee42cd7b..292a49aad0f 100644 --- a/packages/dev/docs/pages/blog/building-a-button-part-3.mdx +++ b/packages/dev/docs/pages/blog/building-a-button-part-3.mdx @@ -49,7 +49,7 @@ There are many nuances to this, however. For example, when clicking a text input Another challenge is that focus events may occur without any preceding user event. For example, when navigating through a form with the next and previous buttons on the software keyboard in iOS, only a focus event is fired, with no keyboard or pointer events before it. This can also occur when navigating with an assistive technology like a screen reader. In these cases, we don’t know how the navigation occurred, so we default to showing the focus ring to ensure the user knows where focus went. -However, we do not want programmatic `focus()` calls to affect the current input modality. The user may click on an element with the mouse, and in response focus is moved somewhere else programatically. For example, when clicking on a button to open a menu, focus is typically moved to the first menu item. However, because `focus` events are still fired when focusing an element programmatically, we need to ignore these events to ensure the focus ring does not appear or disappear based on programatic focus movement. +However, we do not want programmatic `focus()` calls to affect the current input modality. The user may click on an element with the mouse, and in response focus is moved somewhere else programmatically. For example, when clicking on a button to open a menu, focus is typically moved to the first menu item. However, because `focus` events are still fired when focusing an element programmatically, we need to ignore these events to ensure the focus ring does not appear or disappear based on programmatic focus movement. There are also various inconsistencies in the number and order of focus events across browsers. For example, Firefox fires two extra focus events when the user first clicks on any element in an iframe: first on the window, then on the document. Finally, it fires a focus event on the element itself. We need to ignore these extra focus events so they don’t unintentionally cause the focus ring to appear when using a mouse. @@ -67,7 +67,7 @@ Unfortunately, Safari both on macOS and iOS reaaaally doesn’t want to do this. Even with this setting turned on, however, Safari still does not focus buttons and other native form elements on mouse down or touch start. A [bug](https://bugs.webkit.org/show_bug.cgi?id=22261) for this has been open against WebKit since 2008, and it seems unlikely to be fixed any time soon. In this case, we do need to normalize this to ensure browsers are consistent. We can handle focusing the element programmatically on mouse down ourselves. -However, it gets even more tricky on iOS. While on macOS, Safari will respect our programatic focus, on iOS the browser attempts to forcibly blur the element *asynchronously* sometime after the `onClick` event is fired. This means that even programmatically, focusing the button will not work. 🤯 +However, it gets even more tricky on iOS. While on macOS, Safari will respect our programmatic focus, on iOS the browser attempts to forcibly blur the element *asynchronously* sometime after the `onClick` event is fired. This means that even programmatically, focusing the button will not work. 🤯 The only solution is to call `event.preventDefault()` on all mouse and touch events on the element, and handle focusing ourselves. This ensures that the browser does not perform any of its default behavior, including this forced blur, but it means that we’ll have to handle all of the default browser behavior ourselves. diff --git a/packages/dev/docs/pages/blog/rtl-date-time.mdx b/packages/dev/docs/pages/blog/rtl-date-time.mdx index b415d34d36e..7021c140b34 100644 --- a/packages/dev/docs/pages/blog/rtl-date-time.mdx +++ b/packages/dev/docs/pages/blog/rtl-date-time.mdx @@ -77,7 +77,7 @@ Below is a simplified code example of how we utilize Unicode characters to enfor ## DateFields -Date fields, on the other hand, were much more complicated to solve in comparsion. Since we were relying on `display: flex` to format the date segments, the resulting format appeared to mirror the order in which the segments were stored, as returned by [DateFormatter](https://react-spectrum.adobe.com/internationalized/date/DateFormatter.html#dateformatter). This suggested that we could apply a similar approach to what we used for time fields — forcing a left-to-right direction on the date segments. +Date fields, on the other hand, were much more complicated to solve in comparison. Since we were relying on `display: flex` to format the date segments, the resulting format appeared to mirror the order in which the segments were stored, as returned by [DateFormatter](https://react-spectrum.adobe.com/internationalized/date/DateFormatter.html#dateformatter). This suggested that we could apply a similar approach to what we used for time fields — forcing a left-to-right direction on the date segments. However, this assumption proved too broad. In some locales, such as Arabic (`ar-AE`), the date segments were already correctly formatted. In particular, we found that in Arabic, the separators between date segments contained [right-to-left marks](https://en.wikipedia.org/wiki/Implicit_directional_marks) which were returned by the `Intl.DateTimeFormat` API. This causes the separators to be positioned to the left of the preceding text. When we tried enforcing a left-to-right direction like we did in time field using the same solution, the date field was formatted as `2 2022/ 12/` instead of `2022/12/2` due to the presence of the right-to-left marks interfering with the LRI Unicode. In contrast, Hebrew did not have such markers. Therefore, we had to adopt a different approach that accounted for these variations. @@ -111,7 +111,7 @@ However, this assumption proved too broad. In some locales, such as Arabic (`ar- ``` -Through much trial and error, we discovered that appplying the [left-to-right embedding (LRE) Unicode](https://unicode.org/reports/tr9/#Explicit_Directional_Embeddings) on each date segment displayed date fields in Hebrew as left-to-right but also preserved the right-to-left marks on the separaters in Arabic, ensuring that dates in both languages were formatted correctly. While we could have added Unicode to the segments like we did with the time fields, we opted for the [equivalent CSS](https://unicode.org/reports/tr9/#Markup_And_Formatting) approach instead to avoid modifying the DOM. This CSS is applied on date segments with placeholder or actual values to avoid the behavior discussed earlier with shifting segments. Through additional testing, we found that we should only apply left-to-right embedding on numeric values. If the value was displayed as text (e.g. "November" instead of "11"), we did not apply this CSS. +Through much trial and error, we discovered that applying the [left-to-right embedding (LRE) Unicode](https://unicode.org/reports/tr9/#Explicit_Directional_Embeddings) on each date segment displayed date fields in Hebrew as left-to-right but also preserved the right-to-left marks on the separaters in Arabic, ensuring that dates in both languages were formatted correctly. While we could have added Unicode to the segments like we did with the time fields, we opted for the [equivalent CSS](https://unicode.org/reports/tr9/#Markup_And_Formatting) approach instead to avoid modifying the DOM. This CSS is applied on date segments with placeholder or actual values to avoid the behavior discussed earlier with shifting segments. Through additional testing, we found that we should only apply left-to-right embedding on numeric values. If the value was displayed as text (e.g. "November" instead of "11"), we did not apply this CSS. ## Keyboard Navigation @@ -136,7 +136,7 @@ Below is an example of a date field in Hebrew with the correct date format but i diff --git a/packages/dev/s2-docs/src/PropTable.tsx b/packages/dev/s2-docs/src/PropTable.tsx index e4e0416bc14..8f45cfb0d1c 100644 --- a/packages/dev/s2-docs/src/PropTable.tsx +++ b/packages/dev/s2-docs/src/PropTable.tsx @@ -162,12 +162,21 @@ function Rows({props, showDefault, showRequired}: {props: TInterface['properties return properties.map((prop, index) => ( - + {prop.name} {!prop.optional && showRequired - ? + ? : null } diff --git a/packages/dev/s2-docs/src/searchUtils.tsx b/packages/dev/s2-docs/src/searchUtils.tsx index 9cd92bc3ca7..35811ea6aac 100644 --- a/packages/dev/s2-docs/src/searchUtils.tsx +++ b/packages/dev/s2-docs/src/searchUtils.tsx @@ -464,7 +464,8 @@ export function sortItemsForDisplay(ite if (!aIsIntro && bIsIntro) { return 1; } - return 0; + // Sort alphabetically by name + return a.name.localeCompare(b.name); }); } return items; diff --git a/packages/dev/s2-docs/src/types.tsx b/packages/dev/s2-docs/src/types.tsx index d9295b9278d..68b6aba53fb 100644 --- a/packages/dev/s2-docs/src/types.tsx +++ b/packages/dev/s2-docs/src/types.tsx @@ -543,7 +543,16 @@ export function InterfaceType({properties: props, showRequired, showDefault, isC {prop.name} {!prop.optional && showRequired - ? + ? : null } diff --git a/packages/react-aria-components/docs/FileTrigger.mdx b/packages/react-aria-components/docs/FileTrigger.mdx index 7743307537c..4a0275497e8 100644 --- a/packages/react-aria-components/docs/FileTrigger.mdx +++ b/packages/react-aria-components/docs/FileTrigger.mdx @@ -112,7 +112,7 @@ By default, the file trigger will accept any file type. To support only certain ## Multiple files -A file trigger can accept multiple files by passsing the `allowsMultiple` property. +A file trigger can accept multiple files by passing the `allowsMultiple` property. ```tsx example diff --git a/packages/react-aria-components/docs/ToggleButtonGroup.mdx b/packages/react-aria-components/docs/ToggleButtonGroup.mdx index 6f18522e6ca..9cb1d335d30 100644 --- a/packages/react-aria-components/docs/ToggleButtonGroup.mdx +++ b/packages/react-aria-components/docs/ToggleButtonGroup.mdx @@ -340,7 +340,7 @@ By default, toggle button groups are horizontally oriented. The orientation prop -## Accessiblity +## Accessibility A `ToggleButtonGroup` can be labeled using the `aria-label` or `aria-labelledby` props.