✅ Deploy Preview for carbon-components-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	69279ac
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/64a6fe41ef896b0008c0b982
😎 Deploy Preview	https://deploy-preview-14015--carbon-components-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	69279ac
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/64a6fe4151ad2b0008e17b25
😎 Deploy Preview	https://deploy-preview-14015--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@francine pushed up some fixes, namely adding the font-family declaration to the type-style declaration blocks in the type package

@francinelucca The text change is coming from the -webkit-font-smoothing: antialiased that is applied to the body, and is inherited by all components. I'll see where it makes most sense to try and emit this to body somewhere

@francinelucca I've fixed the other issues. As far as the type issue, I've added it to our config.scss that is pulled in by each component, since it handles all of our environment tokens. This is the simplest solution, however, we could do it a few other ways but would involve either touching every single component stylesheet and importing a new utility, or adding it to the type-token definition and bloating it a bit.

It seems like adding it to config is causing other issues. I'm almost wondering if we should just expect users to do something like this:

@use '@carbon/styles/scss/type';
@use '@carbon/styles/scss/components/accordion';

@include type.reset();

and this would pull in all of the font families as well and would reduce a lot of the changes here. What do you think?

Reverted all type package changes, if a user is expecting to use Carbon type/fonts they would need to also pull in @carbon/styles/scss/type

if a user is expecting to use Carbon type/fonts they would need to also pull in @carbon/styles/scss/type

@tw15egan That's probably going to be the default expectation by and large from everyone, right? I think we need to heavily document this in the repo (@carbon/react readme, @carbon/styles readme, v11.md changelog, etc) and the website.

Is this isolated to only use-cases where component styles are brought in individually? Consumers won't need to do this if they just @use @carbon/styles?

@tay1orjones correct, if you pull in @carbon/styles, you get it all. This is only if you pull in individual component styles, you'd also need to make sure you are pulling in our type package.

@tw15egan That makes sense 👍

If they @include type.reset(); across multiple files, it'll still result in duplication in the final stylesheet, right? Do we need to create a new module that automatically emits the type reset via an @include so the sass module system would prevent that duplication and only emit it once?

I hadn't thought about that, I would assume the type.reset() would only be used once on the main scss file, as it just sets global styles that are inherited down