Skip to content
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

Open
wants to merge 50 commits into
base: r/private-css-vars
Choose a base branch
from
Open

Theme bridge to v5.0.0 #2373

wants to merge 50 commits into from

Conversation

r100-stack
Copy link
Member

@r100-stack r100-stack commented Dec 16, 2024

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's themeOptions now accepts a new option called bridgeToFutureVersions which when passed adds data-iui-bridge='true' to the iui-root. It also wraps the iui-root with Root from itwinui-react v5 in order to load its CSS variables (--kiwi-…).

React:

<ThemeProvider
  themeOptions={{
    bridgeToFutureVersions: true
  }}
>
  …
</ThemeProvider>

Rendered:

+ <div class="🥝-root" data-kiwi-theme="dark" data-kiwi-density="dense">
    <div
      class="_iui3160-root"
      data-iui-theme="dark"
      data-iui-contrast="default"
+   data-iui-bridge="true"
    >
      …
    </div>
+ </div>

The presence of this data attribute activates the bridge code that maps the existing --iui-… CSS variables to --kiwi-… variables from v5. 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.

[data-iui-bridge='true'] {
  * {
    --iui-color-background: var(--kiwi-color-bg-neutral-base);
    … // other mappings
  }
}

The bridgeToFutureVersions option and data-iui-bridge names are bikesheddable. I also instead considered adding new accepted themes itself like dark-v5 and light-v5 that the theme 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 by itwinui-css in the itwinui.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:

  • Make comments like "To match Kiwi/iTwinUI" to something more descriptive.

Testing

Manually tested in react-workshop, css-workshop, and vite-playground. Added bridgeToFutureVersions toggles in react-workshop and css-workshop next to the theme toggles.

Docs

  • Added changesets.
  • Add instructions on how to setup iTwinUI-react@5's <Root> on the users' side (#2373 (comment)).

After PR TODOs

  • Added flex-shrink: 0 to iTwinUI v3's iui-button-icon (#2373 (comment))
  • Are status-hover variables not being used anywhere in iTwinUi v3? Investigate. (162008f)

@r100-stack r100-stack self-assigned this Dec 16, 2024
@FlyersPh9

This comment was marked as off-topic.

@r100-stack r100-stack marked this pull request as ready for review December 17, 2024 17:16
@r100-stack r100-stack requested a review from a team as a code owner December 17, 2024 17:16
@r100-stack r100-stack requested review from mayank99, smmr-dn and FlyersPh9 and removed request for a team December 17, 2024 17:16
mayank99

This comment was marked as resolved.

@r100-stack

This comment was marked as resolved.

apps/css-workshop/src/pages/_layout.astro Outdated Show resolved Hide resolved
apps/css-workshop/package.json Outdated Show resolved Hide resolved
r100-stack and others added 3 commits December 20, 2024 15:55
Co-authored-by: Mayank <mayank99@users.noreply.github.com>
Co-authored-by: Mayank <mayank99@users.noreply.github.com>
Co-authored-by: Mayank <mayank99@users.noreply.github.com>
Copy link
Contributor

@mayank99 mayank99 left a 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.

apps/css-workshop/src/pages/_layout.astro Outdated Show resolved Hide resolved
pnpm-lock.yaml Outdated Show resolved Hide resolved
@@ -74,4 +86,8 @@ export const argTypes = {
control: { type: 'boolean' },
defaultValue: false,
},
bridgeToFutureVersions: {
control: { type: 'boolean' },
defaultValue: true,
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

Comment on lines 42 to 43
document.body.dataset.iuiTheme = theme;
document.body.dataset.iuiBridge = bridgeToFutureVersions;
Copy link
Contributor

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>?

Copy link
Member Author

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).

Comment on lines 42 to +43
display: inline-flex;
flex-shrink: 0;
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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).

Copy link
Member Author

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).

Comment on lines +149 to +150
const root = document.body;
const v5Root = document.documentElement;
Copy link
Contributor

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?

Copy link
Member Author

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.

image

apps/css-workshop/src/components/theme.js Outdated Show resolved Hide resolved

.iui-breadcrumbs {
// Neutral color instead of accent
--_iui-breadcrumbs-content-color-default: var(--iui-color-text);
Copy link
Contributor

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.

Copy link
Member Author

@r100-stack r100-stack Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, removed (46eb69d). Will update #2364 soon.


.iui-list-item {
// Since iTwinUI v3 has hover background color but iTwinUI v5 doesn't
--_iui-list-item-background-hover: transparent;
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

@mayank99 mayank99 Dec 24, 2024

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.

Copy link
Member Author

@r100-stack r100-stack Dec 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants