Abstraction of style values into private css variables #2364
+40
−15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
This PR abstracts the style values out of the CSS declaration blocks and stores those style values as private CSS variables (similar to iui-field). This abstraction in a few components makes the code easier to expand in the future (e.g. #2373).
The benefit of this PR is less complicated selectors in #2373. For example, iTwinUI-css code sometimes has styles for different types of disabled (
[disabled], :disabled, [aria-disabled="true"], [data-iui-disabled="true"]
). Additionally, there are a quite a few cases to handle and multiple combinations between them. For instance, in tabs, a tab can be selected or not and could be green or not, which leads to four permutations.Thus, with this PR, #2373 just needs to override the values of these private variables without having to re-write the complex cases already handled by iTwinUI-css code.
One of the reasons I thought to not directly override the tokens was because of nested components. Suppose we have an iTwinUI component X and it can take anything as a child. We also other iTwinUI components Y and Z. Then suppose we do a global mapping of
--iui-color-text: --kiwi-color-text-neutral-primary
and then locally override the token in component X by doing--iui-color-text: --kiwi-color-text-neutral-secondary
since that has a unique text color. If component Y is now placed inside X, it may incorrectly use--kiwi-color-text-neutral-secondary
instead of--kiwi-color-text-neutral-primary
as its text color. We may not uncover this issue since our demos may never have component Y inside of component X. (sandbox to test this)More explanations of why I added each set of variables: #2364 (comment).
Since the new CSS variables added are private, I didn't think adding more variables to avoid problems like this would be an issue.
Apart from the rearrangement of the code, no changes were made to the actual styles.
Testing
Ensured that no image tests are failing.
Docs
N/A since no user facing change.
After PR TODOs