MDX: sbdocs classes are applied to html elements, and they collide with styles applied from classnames.

[rey-wright]

Describe the bug Storybook CSS is cancelling out CSS for classNames that I'm writing.

To Reproduce

1. Create a .mdx file with the following:

import { Meta } from "@storybook/addon-docs/blocks";

<Meta title="Foo/Bar"  />

<Preview>
  <h2 className="font-big">Hello World</h2>
</Preview>

2. Import a CSS file into your preview.js file:

import "../src/index.css";

3. Create the css file with the following:

.font-big { font-size: 40px }

4. When you do all of this and load the above story, you should notice in the source code, Storybook has applied a set of classes to this element, and it will override the font style you set.

Expected behavior I only expect the classes to be applied to actual markdown, not html. It doesn't seem very safe for people who are absolutely creating api's that accept html, to pass storybook classes onto this. Even if that was the case, it seems like Preview should be able to shield against this, or this should be some sort of configuration.

An alternative: There should be some feature to allow us to load our CSS "after" the Storybook CSS has loaded.

Screenshots

Code snippets If applicable, add code samples to help explain your problem.

System:

Environment Info:

  System:
    OS: macOS Mojave 10.14.5
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  Binaries:
    Node: 10.16.0 - /usr/local/bin/node
    Yarn: 1.19.1 - /usr/local/bin/yarn
    npm: 6.11.3 - /usr/local/bin/npm
  Browsers:
    Chrome: 80.0.3987.122
    Firefox: 67.0.1
    Safari: 12.1.1
  npmPackages:
    @storybook/addon-a11y: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-actions: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-backgrounds: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-centered: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-docs: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-knobs: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addon-links: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/addons: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/react: ^6.0.0-alpha.20 => 6.0.0-alpha.20 
    @storybook/theming: ^6.0.0-alpha.20 => 6.0.0-alpha.20 

Additional context This is similar to #8504, except I feel there's a big safety risk of applying storybook css to user supplied html, where the documentation may not display what the output of something actually is.

[shilman]

@rey-wright does this also happen inside <Story> blocks?

[rey-wright]

Thanks for the response. It fortunately does not happen inside of <Story> blocks as well.

I guess maybe then this is a question: Is this a design decision? Sometimes I don't want to have stories and want to document html & CSS classes... so right now I'm just having to define these things in a different javascript file and import them inside of mdx, which gives me what I want.

Happy to close this if it's a decision decision and not a bug. I'll probably forego using <Story> blocks and just define these in external files, but yeah this happening doesn't feel like the greatest.

Anyway, thanks for answering, you're a beast... really like the work and evolution happening within Storybook documentation right now.

[shilman]

Thanks @rey-wright. 🙏 The theming was very carefully designed since it’s very delicate situation with user and docs styles potentially clashing. However, it was designed back when the ONLY thing inside preview blocks was Story blocks. Now that preview can contain other “user” code, we can probably apply the same logic to Preview. Leave this open and I’ll see what i can do!

[radum]

I just hit this wall as well myself. It would be really useful if we can wrap some code in mdx and have it as raw as possible.

And then the global imported css file will take care of the styling.

[paroxyzm]

Thank you @rey-wright - you saved my day, the trick with importing external component into MDX file works flawlessly. Below, a snippet of code I use to work around this issue:

// Documentation.mdx
import { Meta } from '@storybook/addon-docs/blocks';
import { ComponentWithoutSbStyles } from "./ComponentWithoutSbStyles.component";

<Meta
    title="Welcome/Component"
    parameters={{ previewTabs: { canvas: { hidden: true } } }}
/>

<ComponentWithoutSbStyles/>

[dpickett]

I'm seeing this behavior as well. Even if you create a separate component, the applied theme creates challenges if you want to document general CSS / a design system using body font-sizes and other items that are relative.

Can we just not apply these classes to elements that are inside a <Story> component?

[DennisJamin]

This unfortunately also happens to md content that's passed into parameters.docs.description.component.

I'm using a tsx file to document my stories and import a README.md to pass along any extra documentation that shouldn't be part of the stories but should be part of the docs tab. I am using code examples there to display the use of components, however the classes that are passed onto the components are unexpected and pass along unwanted styling to the components' children / slots.

Not sure if as intended, but if you're using MDX stories, a possibility would be to wrap the components in components. Doing so keeps theming from adding classes to the child components..

e.g.

import { Canvas, Meta } from '@storybook/addon-docs/blocks';

<Meta title="components/Example" />

<Canvas>
    <Story name="Default">
        <Example> // Story child component no longer gets classes appended
            <div slot="body">Test 2</div>
        </Example>
    </Story>
</Canvas>

[tsteuwer-accesso]

I'm having this issue as well with our component library. Any updates on this? I, unfortunately, can't use in my mdx because of some sort of conflict in another issue with Webpack 5. Something we have to use.

[MikeMatusz]

I also came across some issues because I was trying to create a landing page for our Angular library documentation. Wrapping in a Canvas is very constraining in terms of layout, and writing the landing page as a React component is hardly ideal given it's an Angular library. I think a simple way to either disable built-in styles on a page level, or a new wrapper component that doesn't have any of it's own styles or functionality like Canvas would be a helpful addition for scenarios like this where you intentionally want to deviate from the mold.

[herzaso]

Any news on this? I'm using version 7.0.0-beta.38 and the workarounds specified here no longer work (external React component / using Canvas and Story as wrappers). The only workaround that I have found was to add important: true to the configuration which is far from Ideal and I probably won't be able to use it

[G9000]

Any news ? 👀

[JReinhold]

I would expect this use case to be solved with the <Unstyled /> doc block introduced in 7.0

https://storybook.js.org/docs/api/doc-block-unstyled#unstyled

[Sidnioulz]

It would also be possible, in Storybook, to wrap all the sbdocs and generated emotion classes in a :where selector, which reduces specificity and gives precedence to user-defined CSS. This is what Starlight does for instance.