Blueprint: How can I activate the light theme within a dark theme container?

[zhaoyi0113]

Bluprint (http://blueprintjs.com/docs/) comes with a way to apply a dark styling to the UI kit, which I have as the default in my app. However, in a certain case I'd like a component to display in the light theme. To do the opposite I can add the pt-dark class, but I can't seem to find a corresponding way to apply the light theme in an container using pt-dark.

[bbenezech]

I had the same issue, but I'm afraid you can't with simple CSS atm.
ShadowDom http://caniuse.com/#feat=shadowdom or an iframe might do the trick for you :/

[giladgray]

@zhaoyi0113 @bbenezech sorry this is not possible, and will never be supported because it would easily double the volume of CSS.

a workaround is to place .pt-dark as low in the tree as possible, which probably requires using it multiple times. also leverage all of our $pt-dark-* Sass variables to set consistent colors as necessary.

[guiguan]

Should have made styles for components modular as well

[guiguan]

Now, I have to do something like this:

    // HACK workaround for https://github.com/palantir/blueprint/issues/1539
    setTimeout(() => {
      document.querySelector('.pt-popover.pt-minimal.pt-dark').classList.remove('pt-dark');
    });

which is really lame :(

[cmslewis]

@guiguan thinking on that more, it _would_ be cool to have dimensions and layout governed in core component styles, then introduce colors via theme classes:

.pt-slider {
    &.pt-theme-light {
        // Light styles
    }

    &.pt-theme-dark {
        // Dark styles
    }
}

But problems arise with CSS specificity when you try to support cascading themes (e.g. expecting dark themes to percolate all the way down the DOM tree when you apply pt-theme-dark to a top-level node):

.pt-slider {
    &.pt-theme-light,
    .pt-theme-light & {
        // Light local styles aren't guaranteed to override dark parent styles
    }

    &.pt-theme-dark,
    .pt-theme-dark & {
        // Dark local styles aren't guaranteed to override light parent styles
    }
}

Maybe you could add an extra class to bump the CSS specificity of local styles as needed:

.pt-slider {
    &.pt-theme-light,
    .pt-theme-light &,
    &.pt-theme-light.pt-theme-override {
        // ...
    }

    &.pt-theme-dark,
    .pt-theme-dark &,
    &.pt-theme-dark.pt-theme-override {
        // ...
    }
}

But even that isn't foolproof, plus you can see how all these selector variants would start to balloon the compiled CSS file sizes.

[guiguan]

Yes, that is problematic with traditional CSS handling. I think it can be solvable by using css in js approach, such as styled-components: https://www.styled-components.com/docs/advanced

[cmslewis]

Hmm, that's not _necessarily_ a CSS-in-JS approach at its core, but rather a context-passing technique. If we didn't include the .pt-dark & selectors everywhere, this approach would solve the problem. But then Blueprint's CSS API would be annoying, because you'd have to add pt-dark at every layer of the tree. (That would need to wait for a major-version bump and could be a pretty burdensome breaking change.)

@llorca @giladgray if you have any thoughts

[adidahiya]

This would be a pretty large styling overhaul and I don't think there are enough internal use cases to warrant it. This is not on our team's roadmap right now.

As with most feature requests, a concrete use case would be helpful. Anyone who's interested in this -- can you show us mockups of the UI you're trying to build?

[Slapbox]

I'd really like to see Blueprint@4 use styled-components or emotion.

We're using Blueprint a bit here a love it, but we use emotion for our internal/custom UI library. Going beyond dabbling with Blueprint in this situation though leads to unmaintainable spaghetti code. If Blueprint@4 was based on styled-components or emotion it would be the last UI library a desktop developer could ever need.