### Blazor integration
diff --git a/packages/nimble-components/src/select/specs/IxD.md b/packages/nimble-components/src/select/specs/IxD.md
index e0bb30a3be..30cfd2cff3 100644
--- a/packages/nimble-components/src/select/specs/IxD.md
+++ b/packages/nimble-components/src/select/specs/IxD.md
@@ -81,13 +81,13 @@ To allow end-users to enter a custom value, use a [**combobox**](/packages/nimbl
> NOTE: SEE FUTURE CONSIDERATIONS FOR MULTI-SELECTION
-To allow end-users to multi-select list options, use a [**tag picker**](/packages/nimble-components/src/tag-picker/specs/IxD.md).
+To allow end-users to multi-select list options, use a **tag picker**.
-To allow end-users to select from fewer than three options, use a [**radio group**](/packages/nimble-components/src/radio-group/specs/IxD.md).
+To allow end-users to select from fewer than three options, use a [**radio group**](/packages/nimble-components/src/radio-group/).
-To allow end-users to trigger an action instead of make a selection, use a [**menu button**](/packages/nimble-components/src/menu-button/specs/IxD.md).
+To allow end-users to trigger an action instead of make a selection, use a [**menu button**](/packages/nimble-components/src/menu-button/).
## Design
diff --git a/packages/nimble-components/src/table-column/breakpoint/IxD.md b/packages/nimble-components/src/table-column/breakpoint/IxD.md
index 6d541aa5e7..4766b1202b 100644
--- a/packages/nimble-components/src/table-column/breakpoint/IxD.md
+++ b/packages/nimble-components/src/table-column/breakpoint/IxD.md
@@ -113,9 +113,11 @@ When the user is focused on the breakpoint cell Space/Enter adds the breakpoint
When the user is focused on table row or group header only the keyboard shortcuts add the breakpoint.
- - On Mac: Cmd + B
- - On Windows/Linux: Ctrl + B
- - Alternatively, pressing F9 when focused on a table row toggles the breakpoint
+```
+- On Mac: Cmd + B
+- On Windows/Linux: Ctrl + B
+- Alternatively, pressing F9 when focused on a table row toggles the breakpoint
+```
## Open Issues
diff --git a/packages/nimble-components/src/table/specs/table-column-specs/table-column-text-field.md b/packages/nimble-components/src/table/specs/table-column-specs/table-column-text-field.md
index 0c0ed6f7f6..1c085e1f7e 100644
--- a/packages/nimble-components/src/table/specs/table-column-specs/table-column-text-field.md
+++ b/packages/nimble-components/src/table/specs/table-column-specs/table-column-text-field.md
@@ -44,7 +44,7 @@ _*Props/Attrs*_
_Type Reference_
-- [`TableColumn`](../table-columns-hld.md#tablecolumn)
+- [`TableColumn`](../table-columns-hld.md)
- [`TableStringField`](https://github.com/ni/nimble/blob/main/packages/nimble-components/src/table/specs/table-data-api.md#implementation--design) (section showing example types)
- [`TableCellState`](../table-columns-hld.md#tablecellstate-interface)
diff --git a/packages/nimble-components/src/wafer-map/specs/README.md b/packages/nimble-components/src/wafer-map/specs/README.md
index 4c13c64ad9..61008dc3ab 100644
--- a/packages/nimble-components/src/wafer-map/specs/README.md
+++ b/packages/nimble-components/src/wafer-map/specs/README.md
@@ -84,7 +84,7 @@ _The key elements of the component's public API surface:_
- Component Name: `nimble-wafer-map`
- Props/Attrs:
- - `dies` - this represents the input data, an array of `WaferMapDie`, which fills the wafer map with content.\
+ - `dies` - this represents the input data, an array of `WaferMapDie`, which fills the wafer map with content.
The **WaferMapDie** object contains the following attributes:
- x: number
- y: number
@@ -100,9 +100,9 @@ _The key elements of the component's public API surface:_
- `gridMinY` - represents the Y coordinate of the minimum corner of the the grid bounding box for rendering the wafer map. Leaving the value `undefined` will set the value to the minimum Y value of the bounding box of the input dies coordinates.
- `gridMaxX` - represents the X coordinate of the maximum corner of the the grid bounding box for rendering the wafer map. Leaving the value `undefined` will set the value to the maximum X value of the bounding box of the input dies coordinates.
- `gridMaxY` - represents the Y coordinate of the maximum corner of the the grid bounding box for rendering the wafer map. Leaving the value `undefined` will set the value to the maximum Y value of the bounding box of the input dies coordinates.
- - `colorScale` - represents the color spectrum which shows the status of the dies on the wafer.\
+ - `colorScale` - represents the color spectrum which shows the status of the dies on the wafer.
The objects we use internally for the colorScale are [d3.scaleOrdinal](https://observablehq.com/@d3/d3-scaleordinal) and [d3.scaleLinear](https://observablehq.com/@d3/d3-scalelinear). Basically, what this does is it associates a specific string (or in our case a value) with a specific color. The values which are not specified in the array, will be calculated as a interpolation from the provided colors for the linear scale or will be assigned to one of the specified color values from the provided colors for the ordinal scale.
- In the following example the colorScale object is defined as `WaferMapColorScale(['red', 'blue', 'green'], [1, 2, 8]);` and uses an internal linear scale\
+ In the following example the colorScale object is defined as `WaferMapColorScale(['red', 'blue', 'green'], [1, 2, 8]);` and uses an internal linear scale
The generated wafer using this color scale is: 
- `maxCharacters` - represents the number of characters allowed to be displayed within a single die, including the label suffix. As the die values are strings, we must have the liberty of limiting how many characters we are willing to display within a single die.
- `dieLabelsHidden` - a boolean value that determines if the die labels in the wafer map view are shown or not. Default value is false.
@@ -217,7 +217,7 @@ Whenever the loading of the wafer data (can and will happen in case we have many
### Accessibility
-Important: this is out of scope for the current implementation.\
+Important: this is out of scope for the current implementation.
Since the `nimble-wafer-map` component was designed to display tens of thousands of data points, it's challenging to provide Accessibility functionality which can read out loud the values displayed in a meaningful manner.
Based on the WAI documentation on [Complex Images](https://www.w3.org/WAI/tutorials/images/complex/), in the future we could provide a paragraph containing information about the name of the wafer that is displayed, the LOT where the wafer comes from and a general overview (e.g. % of the faulty dies on the wafer) of the status. This might give a pretty good description about what the displayed nimble component shows to the user. In order to achieve this, the ["img"](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/img_role) role will be set for the `` tag.
Please note that in the initial implementation we do not plan to gather and summarize any of this information so this will be part of future updates to this component.
diff --git a/packages/spright-components/src/chat/specs/README.md b/packages/spright-components/src/chat/specs/README.md
index 9303708d8b..503e6f260e 100644
--- a/packages/spright-components/src/chat/specs/README.md
+++ b/packages/spright-components/src/chat/specs/README.md
@@ -96,13 +96,16 @@ These components are competing against possible implementations within applicati
### Prior Art/Examples
-**Screenshot of Figma design of message and conversation component (light mode)**
+**Screenshot of Figma design of message and conversation component (light mode)**
+
-**Screenshot of Figma design of chat input component (light mode)**
+**Screenshot of Figma design of chat input component (light mode)**
+
-**Screenshot of Figma design of chat components embeded within larger pane (dark mode)**
+**Screenshot of Figma design of chat components embeded within larger pane (dark mode)**
+
---
@@ -365,7 +368,7 @@ _Consider the accessibility of the component, including:_
- _Components which delegate focus require all global ARIA attributes to be enumerated_
- _Components should either follow an existing [ARIA Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/) or provide thorough research indicating why a new pattern is appropriate. Research should include sources like [Open UI Community Group](https://github.com/openui/open-ui) and other popular design systems._
- _Behavior with browser configurations like "Prefers reduced motion"_
-- _Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](/packages/nimble-components/src/patterns/anchor/tests/anchor-patterns.mdx). The story should be updated to include the new component._
+- *Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](https://nimble.ni.dev/storybook/index.html?path=/docs/tests-anchor-patterns--docs). The story should be updated to include the new component.*
#### Input
diff --git a/specs/fast-project-realignment/README.md b/specs/fast-project-realignment/README.md
index c8bc620d55..4999f238b0 100644
--- a/specs/fast-project-realignment/README.md
+++ b/specs/fast-project-realignment/README.md
@@ -103,16 +103,16 @@ HLD Work item: [#2207](https://github.com/ni/nimble/issues/2207)
- Fork the `microsoft/fast` repo to `ni/fast` as a new top-level open source GitHub repository.
- FAST is licensed similarly to Nimble as MIT. That will be preserved in the fork. License should be [updated](https://softwareengineering.stackexchange.com/a/277699) to reflect NI contributions.
-- Make the `archives/fast-element-1` branch the default branch:
+ - Make the `archives/fast-element-1` branch the default branch:
- Keep the name `archives/fast-element-1` on the default branch.
- Delete branches other than the `archives/*` branches.
-- Update the packages to use the `ni` scope:
+ - Update the packages to use the `ni` scope:
- `@microsoft/fast-colors` to `@ni/fast-colors`.
- `@microsoft/fast-element` to `@ni/fast-element`.
- `@microsoft/fast-foundation` to `@ni/fast-foundation`.
- `@microsoft/fast-web-utilities` to `@ni/fast-web-utilities`.
- `@microsoft/fast-react-wrapper` to `@ni/fast-react-wrapper`.
-- Remove unused packages and code (refer to [`archives/fast-element-1`](https://github.com/microsoft/fast/tree/archives/fast-element-1)):
+ - Remove unused packages and code (refer to [`archives/fast-element-1`](https://github.com/microsoft/fast/tree/archives/fast-element-1)):
```
/examples
@@ -124,15 +124,15 @@ HLD Work item: [#2207](https://github.com/ni/nimble/issues/2207)
/specs
```
-- Update npm dependencies to latest.
-- Enable renovate updates.
-- Add CODEOWNERS configuration (exact owners TBD).
-- Update GitHub workflow:
+ - Update npm dependencies to latest.
+ - Enable renovate updates.
+ - Add CODEOWNERS configuration (exact owners TBD).
+ - Update GitHub workflow:
- Configure beachball to publish on each merge.
- Make minimal changes (continue to use `yarn`, `lerna`, `chai`, etc).
- If not a significant effort, switching external facing / globally required tools to align with Nimble would be preferable. In particular switching yarn and lerna to standard npm and npm workspaces would be beneficial for Nimble contributors.
-- Update top-level README / CONTRIBUTING to cover intentions of the repo / fork:
+ - Update top-level README / CONTRIBUTING to cover intentions of the repo / fork:
- A set of minimal changes to FAST to continue to adopt bug fixes and potentially minor features only with the goal of alignment / consistency (for example adding start / end slots or label slots consistently).
- Not a place for significant new features or component development.
- Treat the `ni/fast` repo similarly to how `microsoft/fast` was treated:
diff --git a/specs/labels-and-localization/README.md b/specs/labels-and-localization/README.md
index 04dd93a578..f34b0b2571 100644
--- a/specs/labels-and-localization/README.md
+++ b/specs/labels-and-localization/README.md
@@ -115,14 +115,17 @@ public numberFieldIncrement = 'Increment';
See the prototype branch: [localizable-labels-prototype-2](https://github.com/ni/nimble/compare/%40ni/nimble-angular_v16.6.3...localizable-labels-prototype-2?expand=1), but note the prototype used the name `i18n` instead of the current proposal `label-provider`.
-**nimble-components**
+**nimble-components**
+
We'll define a base class (prototype: [i18n-base.ts](https://github.com/ni/nimble/blob/b13117639de55db3086561edccc4dfe5994f9829/packages/nimble-components/src/i18n/i18n-base.ts)) for the label-providers, which handles setting the token values on the ancestor theme-provider. For each label-provider, we'll have a file declaring the DesignTokens, with a class deriving from the base class that has attributes+properties for setting the token values (prototype: [i18n/core](https://github.com/ni/nimble/blob/b13117639de55db3086561edccc4dfe5994f9829/packages/nimble-components/src/i18n/core/index.ts) and [i18n/table](https://github.com/ni/nimble/blob/b13117639de55db3086561edccc4dfe5994f9829/packages/nimble-components/src/i18n/table/index.ts)).
-**nimble-angular**
+**nimble-angular**
+
Each label-provider will have its own Angular directive and module (prototype: [nimble-i18n-core.directive](https://github.com/ni/nimble/blob/cf6a2e1ae010d00dc7253c25658dd5a17b5f6215/angular-workspace/projects/ni/nimble-angular/i18n/core/nimble-i18n-core.directive.ts) and [nimble-i18n-core.module](https://github.com/ni/nimble/blob/cf6a2e1ae010d00dc7253c25658dd5a17b5f6215/angular-workspace/projects/ni/nimble-angular/i18n/core/nimble-i18n-core.module.ts) for `label-provider-core`.)
We will probably also want to create secondary entry points in nimble-angular for each label-provider, which ensures that client apps won't necessary pull in all the Nimble labels from all label providers (unless they import them explicitly).
-In order to make it easy/automatic for clients to pick up new localized strings/labels when they uptake new nimble-angular versions, each label-provider has an additional directive that will set all of the Nimble-defined labels/strings, using Angular's `$localize` function on the English strings.
+In order to make it easy/automatic for clients to pick up new localized strings/labels when they uptake new nimble-angular versions, each label-provider has an additional directive that will set all of the Nimble-defined labels/strings, using Angular's `$localize` function on the English strings.
+
Prototype: [nimble-i18n-core-with-defaults.directive](https://github.com/ni/nimble/blob/cf6a2e1ae010d00dc7253c25658dd5a17b5f6215/angular-workspace/projects/ni/nimble-angular/i18n/core/nimble-i18n-core-with-defaults.directive.ts)
If we define descriptions for each string, we can include it so it appears in the message files, such as: ``$localize`:Nimble number-field increment button label:Increment` ``.
@@ -136,7 +139,8 @@ For each label-provider that an Angular app will use:
```
- If the app needs to customize any of the labels, they can do so via the label-provider directive API. Generally the root label-provider would use `withDefaults` to set all the labels to their localized values, and any nested ones would not.
-Once an Angular app uptakes the nimble-angular version that introduces these label-provider modules, and references the label-provider modules, running `ng extract-i18n` will result in the app pulling in Nimble-provided labels/strings for localization. (Prototype: [messages.xlf](https://github.com/ni/nimble/blob/d51ee14dc49db7070e5cab726c225f69635de17b/angular-workspace/projects/example-client-app/src/locales/messages.xlf), output of `ng extract-i18n`)
+Once an Angular app uptakes the nimble-angular version that introduces these label-provider modules, and references the label-provider modules, running `ng extract-i18n` will result in the app pulling in Nimble-provided labels/strings for localization. (Prototype: [messages.xlf](https://github.com/ni/nimble/blob/d51ee14dc49db7070e5cab726c225f69635de17b/angular-workspace/projects/example-client-app/src/locales/messages.xlf), output of `ng extract-i18n`)
+
When they pull in new nimble-angular versions in the future and re-run that command, the new strings will again be pulled in for translation automatically.
We expect most apps in SystemLink to consume both `nimble-label-provider-core` and `nimble-label-provider-table` as-is (in their app component HTML, as children of the `nimble-theme-provider`).
@@ -144,8 +148,10 @@ We expect most apps in SystemLink to consume both `nimble-label-provider-core` a
We can consider codegen-ing the Angular directives, which would let us avoid copy-pasting the English strings/ descriptions at the nimble-angular level, but at the expense of obfucscating some of the code (in the generator scripts).
**nimble-blazor**
-We currently don't have a good solution for Blazor clients to automatically pick up or localize our labels/strings.
-We do still plan to create Razor components for each label-provider, so that Blazor clients can manually specify/localize the labels if desired.
+We currently don't have a good solution for Blazor clients to automatically pick up or localize our labels/strings.
+
+We do still plan to create Razor components for each label-provider, so that Blazor clients can manually specify/localize the labels if desired.
+
(Prototype: [NimbleI18nCore.razor](https://github.com/ni/nimble/compare/@ni/nimble-angular_v16.6.3...localizable-labels-prototype-2?expand=1#diff-88863ebb8b90aab301573eeb66b6850c26327d12be6b0fa33bcd3cccaadca938) for `label-provider-core`).
If we have any clients that will be using Nimble Blazor and non-English locales, we should probably do additional research to see if we can come up with a more seamless approach. Note that the `label-provider-core` labels are not visible / are for accessibility only, so this may only be a priority for clients using the Nimble table (which will have visible strings needing localization).
@@ -259,7 +265,8 @@ We could still add on that approach in the future, for specific labels, if we id
### Codegen more of the code (including nimble-components)
See the prototype branch: [localizable-labels-prototype](https://github.com/ni/nimble/commit/0b088a67af4a860fce17003e37ea1bf8dfd10e8b). Note that this prototype had all of the labels on the theme provider itself.
-*nimble-components*
+*nimble-components*
+
We could define the labels in a JSON file (Prototype: [`labels.json`](https://github.com/ni/nimble/commit/0b088a67af4a860fce17003e37ea1bf8dfd10e8b#diff-0e77bd18c80fb68ad9624a1eeccbec4a539f98b92e2ff97a013f763cc897a8ce)):
```json
{
diff --git a/specs/nimble-blazor/blazor-net8-upgrade-hld.md b/specs/nimble-blazor/blazor-net8-upgrade-hld.md
index bb5dec23c6..967ca41b97 100644
--- a/specs/nimble-blazor/blazor-net8-upgrade-hld.md
+++ b/specs/nimble-blazor/blazor-net8-upgrade-hld.md
@@ -47,20 +47,20 @@ Related work items:
- NimbleBlazor 18.2.0
- Microsoft.AspNetCore.Components.Web 8.0.7
- Code owners: Eric Peterson, Anand Jain
-- ASW
- - ElectricVehicle (`/Source/ElectricVehicle`): `BatteryTestWebApplication.NetCore.csproj`, `EVTestUIPluginComponents.NetCore.csproj`
+ - ASW
+ - ElectricVehicle (`/Source/ElectricVehicle`): `BatteryTestWebApplication.NetCore.csproj`, `EVTestUIPluginComponents.NetCore.csproj`
- .NET 8
- NimbleBlazor 18.2.2
- Microsoft.AspNetCore.Components.Web 8.0.7
- Code owners: Jonathan Ou-yang, Fei Ma
- - LicenseManagement (`/Source/LicenseManagement`):
+ - LicenseManagement (`/Source/LicenseManagement`):
- `Licensing.ClientUtility.NetCore.csproj`: .NET 8
- `Licensing.ElectronBlazorUtilities.NetCore.csproj`, `Licensing.Wizard.NetCore.csproj`: .NET 6
- NimbleBlazor 18.2.2
- Microsoft.AspNetCore.Components.Web 8.0.7
- Code owners: Vineeta Chelamkuri, Tim Atwood
-- Skyline
- - `/WaferMapProcessorService/`
+ - Skyline
+ - `/WaferMapProcessorService/`
- .NET 6
- NimbleBlazor 17.4.3
- Code owners: Alon Aviv, Dror Lupu
@@ -85,7 +85,7 @@ Once we update to target .NET 8, remaining .NET 6 clients of Nimble Blazor can o
### Target both .NET 6 and .NET 8
It's possible for .NET projects to [target multiple framework versions](https://learn.microsoft.com/en-us/dotnet/standard/frameworks#how-to-specify-a-target-framework), meaning we could target both .NET 6 and .NET 8 with the following `csproj` configuration:
-`net8.0;net6.0`
+`net8.0;net6.0`
We've elected not to do this for the following reasons:
- Additional maintenance burden. Each target framework version can specify different dependencies/ dependency versions - we'd probably depend on different versions of `Microsoft.AspNetCore.Components.Web` for each .NET version, for example. This approach would require separate testing going forward. We would most likely need different JS initialization scripts for each .NET version (also implying that all of our Playwright tests would need to run against both versions).
diff --git a/specs/templates/custom-component.md b/specs/templates/custom-component.md
index db836df45b..c28e98ead2 100644
--- a/specs/templates/custom-component.md
+++ b/specs/templates/custom-component.md
@@ -111,7 +111,7 @@
- *Components which delegate focus require all global ARIA attributes to be enumerated*
- *Components should either follow an existing [ARIA Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/) or provide thorough research indicating why a new pattern is appropriate. Research should include sources like [Open UI Community Group](https://github.com/openui/open-ui) and other popular design systems.*
- *Behavior with browser configurations like "Prefers reduced motion"*
-- *Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](/packages/nimble-components/src/patterns/anchor/tests/anchor-patterns.mdx). The story should be updated to include the new component.*
+- *Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](https://nimble.ni.dev/storybook/index.html?path=/docs/tests-anchor-patterns--docs). The story should be updated to include the new component.*
### Mobile
diff --git a/specs/templates/fast-based-component.md b/specs/templates/fast-based-component.md
index 29a6253506..a44e39bf70 100644
--- a/specs/templates/fast-based-component.md
+++ b/specs/templates/fast-based-component.md
@@ -61,7 +61,7 @@
- *Documentation: Any requirements besides standard Storybook docs and updating the Example Client App demo?*
- *Tooling: Any new tools, updates to tools, code generation, etc?*
- *Accessibility: keyboard navigation/focus, form input, use with assistive technology, etc.*
- - *Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](/packages/nimble-components/src/patterns/anchor/tests/anchor-patterns.mdx). The story should be updated to include the new component.*
+ - *Support for standard link behaviors if the component is an anchor or contains an anchor. These behaviors are enumerated in the [anchor-patterns story](https://nimble.ni.dev/storybook/index.html?path=/docs/tests-anchor-patterns--docs). The story should be updated to include the new component.*
- *Mobile: small screens, touch interactions, mobile-specific integrations*
- *Globalization: special RTL handling, swapping of icons/visuals, localization, etc.*
- *Performance: does the FAST component meet Nimble's performance requirements?*
diff --git a/specs/templates/table-column-hld.md b/specs/templates/table-column-hld.md
index eca7452640..69db6bb03c 100644
--- a/specs/templates/table-column-hld.md
+++ b/specs/templates/table-column-hld.md
@@ -67,7 +67,9 @@ _Describe what the cell view will render._
_If an existing group header view element will be used instead of creating a new one:_
- A new element will not be created for the group header view. The column will specify the existing `tableColumnTextGroupHeaderViewTag` as the `groupHeaderViewTag` because the header will contain only text.
+```
+A new element will not be created for the group header view. The column will specify the existing `tableColumnTextGroupHeaderViewTag` as the `groupHeaderViewTag` because the header will contain only text.
+```
_Otherwise:_