You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current implementation of design tokens, CSS variables are generated and then a Node script is run to replace the original SCSS variable values with the newly generated CSS variable containing the resolved value instead of the resolved value only being for the SCSS variable. For example:
/* before */$primary: #0A3055!default;
/* after */:root {
--pgn-color-primary-base: #0A3055;
}
$primary: var(--pgn-color-primary-base) !default;
However, as we migrate towards having Paragon compile its own CSS (see #2014), consuming applications will no longer have access to the SCSS variables/mixins currently provided by Paragon. The consequence here is that consuming applications will need to rely directly on the available CSS variables, etc. as opposed to the SCSS variables that happened to have CSS variables as their values.
Our original intent was to have the CSS variable as the value for the existing SCSS variables in an attempt to minimize the impacts for consuming applications who use the SCSS variables today. However, in doing so, we realized consuming applications would largely still be responsible for building Paragon's CSS instead of having the CSS compiled externally to consuming applications.
As such, the issue proposes we no longer continue with the strategy of continuing to use the existing SCSS variables throughout Paragon components and instead use the new CSS variables directly. This strategy would in effect be the same migration strategy that consuming MFEs would need to do when loading already-compiled CSS file(s) from Paragon or @edx/brand packages.
We do have some CLI tooling in place within Paragon that would help consuming applications with some of this (e.g., replace-scss-with-css) already, though it doesn't currently handle things like map-get($spacers, 2) -> var(--pgn-spacing-spacer-2) or @include media-breakpoint-up(md) (see #2015).
We will tackle the CLI tooling question as a separate discovery issue @adamstankiewicz
Ensure the component-specific CSS variables can still display on the docs site under the "Variables" section.
May need to generate component-specific stylesheets and aggregate them into one.
Remove SCSS variables in favor of strictly using CSS variables throughout Paragon codebase (i.e., no more SCSS variables defined with CSS variables as their values).
Ensure the SCSS variables displayed on component pages in the documentation website show the equivalent CSS variables definitions instead.
Consider other impacts to these proposed changes.
The text was updated successfully, but these errors were encountered:
adamstankiewicz
changed the title
[discovery] Remove SCSS variable usages in Paragon
[discovery] Remove SCSS variable usages in components and other custom styles
Feb 14, 2023
Description
In the current implementation of design tokens, CSS variables are generated and then a Node script is run to replace the original SCSS variable values with the newly generated CSS variable containing the resolved value instead of the resolved value only being for the SCSS variable. For example:
However, as we migrate towards having Paragon compile its own CSS (see #2014), consuming applications will no longer have access to the SCSS variables/mixins currently provided by Paragon. The consequence here is that consuming applications will need to rely directly on the available CSS variables, etc. as opposed to the SCSS variables that happened to have CSS variables as their values.
Our original intent was to have the CSS variable as the value for the existing SCSS variables in an attempt to minimize the impacts for consuming applications who use the SCSS variables today. However, in doing so, we realized consuming applications would largely still be responsible for building Paragon's CSS instead of having the CSS compiled externally to consuming applications.
As such, the issue proposes we no longer continue with the strategy of continuing to use the existing SCSS variables throughout Paragon components and instead use the new CSS variables directly. This strategy would in effect be the same migration strategy that consuming MFEs would need to do when loading already-compiled CSS file(s) from Paragon or
@edx/brand
packages.We do have some CLI tooling in place within Paragon that would help consuming applications with some of this (e.g.,replace-scss-with-css
) already, though it doesn't currently handle things likemap-get($spacers, 2)
->var(--pgn-spacing-spacer-2)
or@include media-breakpoint-up(md)
(see #2015).We will tackle the CLI tooling question as a separate discovery issue @adamstankiewicz
Note this issue is related to #1549.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: