[This includes: (1) finding any other places in existing docs site that references SCSS variables (e.g., we’ve only updated the “Colors” page thus far; needs to be replaced with CSS variables; (2) Documentation for theme authors on how to override the core design tokens and/or implement their own.]
[Not Yet Ticketed/Scoped] Would still like to try to do more nuanced performance benchmarking on the new way of ingesting Paragon’s CSS vs. how we did it before. For example, none of Paragon’s CSS will go through Webpack build compilation so tools such as PurgeCSS, etc. won’t work to reduce Paragon’s CSS asset size.
[Not Yet Ticketed/Scoped] Further QA to ensure no regressions of style properties, a11y, and/or functionality of components. I expect we will continue to find minor issues that need to be addressed.
[Not Yet Ticketed/Scoped] Discovery: expose design tokens tooling as a REST API so MFEs can do runtime theming based on dynamic, user-driven values (e.g., Enterprise theming, partner theming, etc.). Not a prerequisite for initial design tokens release.
[Not Yet Ticketed/Scoped] Supporting consumers in migrating off deprecated components, as these are removed with design tokens release.
[Not Yet Ticketed/Scoped] Supporting consumers in migrating off FontAwesome, as the remaining support for this is removed with design tokens release.
[Not Yet Ticketed/Scoped] Understand the nuances of peer dependencies to enable the design tokens release across shared components and libraries so consumers don’t get blocked on peer dependency issues to understand the appropriate sequencing of releases.