-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Theme bridge to v5.0.0
#2373
base: r/private-css-vars
Are you sure you want to change the base?
Theme bridge to v5.0.0
#2373
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
packages/itwinui-react/src/core/ThemeProvider/ThemeProvider.tsx
Outdated
Show resolved
Hide resolved
packages/itwinui-react/src/core/ThemeProvider/ThemeProvider.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: Mayank <mayank99@users.noreply.github.com>
Co-authored-by: Mayank <mayank99@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 3.17.0-dev.0 is released with accompanying instructions for consumers to try it out.
Early next week, we'll do some final cleanup before merging into main
.
packages/itwinui-react/src/core/ThemeProvider/ThemeProvider.tsx
Outdated
Show resolved
Hide resolved
packages/itwinui-react/src/core/ThemeProvider/ThemeProvider.tsx
Outdated
Show resolved
Hide resolved
packages/itwinui-react/src/core/ThemeProvider/ThemeProvider.tsx
Outdated
Show resolved
Hide resolved
@@ -74,4 +86,8 @@ export const argTypes = { | |||
control: { type: 'boolean' }, | |||
defaultValue: false, | |||
}, | |||
bridgeToFutureVersions: { | |||
control: { type: 'boolean' }, | |||
defaultValue: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we good to flip the defaults back now and make CI pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also we should rename this setting to "theme bridge" in our workshops as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, flipped the defaults back (3dea59e).
Will investigate into the remaining CI failures.
document.body.dataset.iuiTheme = theme; | ||
document.body.dataset.iuiBridge = bridgeToFutureVersions; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: Can we set everything on <html>
instead of setting some of these on <body>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, those two lines don't seem necessary, removed (52020e8).
display: inline-flex; | ||
flex-shrink: 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to move this change out into a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that sounds better, removed that line from this PR (52020e8). Added an after PR TODO to readd it in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make another release 3.17.0-dev.1
before this PR merges. We can temporarily add it back for the purpose of that release (otherwise the SideNavigation would look broken).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, right, added back (46eb69d).
packages/itwinui-css/src/expandable-block/expandable-block.scss
Outdated
Show resolved
Hide resolved
const root = document.body; | ||
const v5Root = document.documentElement; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar comment here as Ladle: can we set all attributes on the same element (<body>
or <html>
) instead of mixing and matching?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iui-root
cannot be on html
since iui-root
sets a font-size
of 0.875rem
(code) which would make the root font-size
as 0.875rem
and not 1rem
.
We can set the data attributes on html
without adding iui-root
as we are currently doing in react-workshop
for the page background ((code)). However, then iui-root
+ its theme related data attributes will still need to be placed somewhere.
To just have one place with the data attributes + the iui-root
class, we chose <body>
as that place in css-workshop
.
Regarding the selected lines, the reason we set color-scheme
on <html>
and not <body>
is because when placed on <html>
those iTwinUI v5 variables are available throughout the page and not just within 🥝-root
.
packages/itwinui-css/src/bridge.scss
Outdated
|
||
.iui-breadcrumbs { | ||
// Neutral color instead of accent | ||
--_iui-breadcrumbs-content-color-default: var(--iui-color-text); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can get rid of this, right? We decided to use the same set of color variables as current iTwinUI v3 implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
.iui-list-item { | ||
// Since iTwinUI v3 has hover background color but iTwinUI v5 doesn't | ||
--_iui-list-item-background-hover: transparent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is correct anymore. We do have a background hover in Kiwi.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, I see. I wasn't sure what hover color to give since we don't want to make the code more complex with color-mix
. So, I left the custom property declaration as-is but just updated the comment to reflect the new reason why it is there. (46eb69d).
If we indeed want a hover color, open to ideas for replacements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we shouldn't need this component-level override, right? It should automatically use whatever color we are setting globally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, but here there is no default background. On hover, it goes to --iui-color-background-hover
which is --iui-color-background
itself. Going from no background to background on hover didn't look correct to me in v5:
demo.mov
So, I thought to override it and remove it on hover. If others feel differently, I can change it.
Changes
#2364 refactors some code to introduce private css variables that help with the bridge code mapping (more info below). This PR will be merged after that PR.
Since
@itwin/itwinui-react@5.0.0-alpha.0
is now published, this PR implements a bridge for existing iTwinUI applications and packages to look similar to this future version and help in migration and early adoption.The
ThemeProvider
'sthemeOptions
now accepts a new option calledbridgeToFutureVersions
which when passed addsdata-iui-bridge='true'
to theiui-root
. It also wraps theiui-root
withRoot
fromitwinui-react v5
in order to load its CSS variables (--kiwi-…
).React:
<ThemeProvider themeOptions={{ bridgeToFutureVersions: true }} > … </ThemeProvider>
Rendered:
The presence of this data attribute activates the bridge code that maps the existing
--iui-…
CSS variables to--kiwi-…
variables fromv5
. It also adds some limited styles only whenever it was needed. Since some of these mappings are subjective, especially when something similar doesn't exist in iTwinUI-react v5, open to other views.The
bridgeToFutureVersions
option anddata-iui-bridge
names are bikesheddable. I also instead considered adding new accepted themes itself likedark-v5
andlight-v5
that thetheme
prop could accept. However, I felt those would lead to many code changes and potentially confusion and complexity. Open to other suggestions.The mapping code lies in
bridge.scss
that is exported byitwinui-css
in theitwinui.bridge
layer. There are some TODOs in that file for whenever I wasn't sure of the mapping. Open to comments on those, if any.This mapping was most tested in the dark theme. Some testing was done with the light theme too and will test more too. The high-contrast dark and high-contrast light themes continue using the regular dark and regular light themes. Once iTwinUI-react v5 supports high-contrast themes, we can make the necessary changes, if any, in the bridge.
TODO:
Testing
Manually tested in
react-workshop
,css-workshop
, andvite-playground
. AddedbridgeToFutureVersions
toggles inreact-workshop
andcss-workshop
next to the theme toggles.Docs
iTwinUI-react@5
's<Root>
on the users' side (#2373 (comment)).After PR TODOs
flex-shrink: 0
to iTwinUI v3'siui-button-icon
(#2373 (comment))status-hover
variables not being used anywhere in iTwinUi v3? Investigate. (162008f)