Option for a namespaced preflight class

[jshimkoski]

When developing component libraries there is an inherit failing of the way in which preflight currently works, it overrides global styles.

In a typical app this is suitable but when you are writing a component library for consumption in other apps, this becomes troublesome and you must either reinvent the “preflight” wheel specific to your project, or just roll on without Tailwind CSS.

I propose the ability to use the “preflight” configure option to specify a “class” mode or maybe some sort of “namespace” mode, in which all of preflight would become a child of a specific class name.

This would provide component library authors the ability to use Tailwind CSS to its full potential, while also gaining modularity for their components.

Maybe further control over preflight would be beneficial as well, such as the ability to remove bits of it you know you won’t be using.

This could also benefit apps that are transitioning from other CSS libraries where some sections of the app might still be Bootstrap, while others are Tailwind CSS, for example.

[adamwathan]

Definitely something we could consider, especially now that :where has good enough browser support to start using in the framework (we'd need that to avoid specificity issues).

It's totally doable to use Tailwind without Preflight though, you don't have to throw the whole framework away just because you aren't using Preflight. Every utility class still works and does exactly the same thing as it normally does, you'd just be missing some of the default styles included in Preflight.

The only notable difference in workflow is that you can't just use border to add a border, you'd need border border-solid since the browser doesn't set a default border style and Preflight does.

[jshimkoski]

I hear you. I was just thinking of a way to make this as brainless as possible without any gotchas.

Without preflight, buttons need some real love, fonts need to be reset, and all of that other beautiful stuff you guys (and modern-normalize) do goes away.

I'd love to just wrap my components in a .preflight class and be on my merry way.

Basically, Tailwind CSS makes life so much easier because you guys dish out the cross browser best practices and a single config that allows developers to not worry about whether or not something will look the same across browsers and devices.

This would also allow developers to add custom styles to preflight (well, base... is this currently possible with preflight disabled?) in the way we do today, it just scopes itself down to the .preflight class, or whatever it's called (would be cool if it could be prefixed as well, just like the other utility classes).

[elilabes]

+1 for this. We are currently getting around this by turning pre-flight off then using less to scope the preflight styles for us.

// Unique id generated when building
@import "./build-id.less";

.@{buildId} {
    // We manually import tailwinds `preflight` styles here so that they are scoped
    // to the design system. Tailwinds built in important property does not apply to preflight,
    // hence using this method. See `tailwind.config.js` for more details.
    @import (less) "../node_modules/tailwindcss/src/css/preflight.css";
}

/**
 * Import the usual Tailwind CSS utilities. These are scoped
 * via the `tailwind.config.js` file.
 *
 * @see `tailwind.config.js` -> `important`
 */
@tailwind base;
@tailwind components;
@tailwind utilities;

We use Micro Front-ends so we have multiple applications all stitched together that can use different versions of our component library. In order to make sure they don't clash with each other we generate a random key for important in tailwind.config.js that matches a custom provider. We then have to sync back to build-id.less so that preflight matches.

[rapitkan]

@elilabes Hi. Would you show some more of the solution you presented above? Bootstrap styles and Tailwind CSS styles are crashing and Tailwind CSS doesn't support scoping of basic styles easily. Thanks.

[architchandra]

Hi

Any update on this? I need to gradually integrate Tailwind-based components into a legacy website. I'm worried that Preflight will conflict with the existing styles but I would still like it to be present for the components that I create.

Is there any workaround for this? Should I try to manually add Preflight's logic after namespacing the Tailwind-based components?

Thanks.

[ravinsharma7]

I had to rewrite preflight css a bit to work with web components and extend tailwindcss configuration file to work with an extra parent class (can use the buildId technique done by elilabes too). Because preflight has definition for html, and body, which doesn't work for web components.

PS: I managed to used tailwindcss web components in a legacy bootstrap web application. No conflicts using this methods. At least for me.

[hburrichter]

Could you briefly explain how you solved this or maybe share your custom preflight css? Thanks!

[elilabes]

@rapitkan @architchandra sorry just seen this now with the new activity.

The solution we used above is a bit dated now, instead we make use of a postcss plugin called postcss-prefix-selector.

Here is our complete config (as mentioned, we use MFEs so we have multiple applications that stitch together at runtime in the browser).

1. In each application entry point we import tailwind

// This is the same as having our own file that imports @base @components @utilities etc but is built in
import "tailwindcss/tailwind.css";

2. We use this postcss config that scopes all styles with a prefix. For example sake I have hard coded it, but we have a key defined per application that we import from package.json. This applies to all classes (preflight, custom, etc. See options for customisation). We don't use tailwind.config.js's important modifier anymore.

const APPLICATION_CHUNK_KEY = "mfe-application"

module.exports = {
    plugins: [
        "tailwindcss",
        [
            "postcss-prefix-selector",
            {
                // We increase the specificity twice (we have some yuck legacy styles) and need the specificity. 
                // @example mfe-application.mfe-application mt-1
                // @example mfe-application.mfe-application shadown-md
                prefix: `.${APPLICATION_CHUNK_KEY}.${APPLICATION_CHUNK_KEY}`,
                
                // Here you can include other options like `includeFiles` which will only scope specific
                // files. In our case we only use tailwind and so we scope everything.
                // @see https://www.npmjs.com/package/postcss-prefix-selector#options
                // @example includeFiles: ["tailwind.css"] - this relates to the file we import in step 1
            },
        ],
        "autoprefixer",
    ],
};

3. In every application, we then have a div that has the corresponding class that wraps the entire application. In our case we do this in a provider that is exported from our component library (our component library also uses tailwind).

import {ApplicationContainer} from "@scope/our-library"

const App = () => {
  return (
    // Under the hood this renders a div with the class "mfe-application" and make the key accessable to child
    // components via `useApplicationContainer`. 
    <ApplicationContainer key="mfe-application" theme="xyz">
      {children}
    </ApplicationContainer>
  )
}

We do this in a provider so our component library provides and has access to the key. It is important to note that with this system, any element attached to the body will likely live outside of your scoped class. This means that the styles will not apply. We fix this by having our root Popper / Dialog / anything that appends to the body implement our useApplicationContainer hook and add the corresponding class so that styles continue to work.

Hope that provides some context for how we are doing things. It allows us to have multiple applications working at the same time with no style pollution.

Specifically for this discussion, it can also be used to scope the preflight classes.

[elilabes]

As @ravinsharma7 mentions, preflight does have some styles that target html and body, which if you add your root class somewhere inside the body, will cause those specific styles to never apply.

You can use the transform option of postcss-prefix-selector to check for html or body and rewrite it to use your target element instead. In our case we added those specific html and body styles to our application shell (the application that composes and loads all the other MFEs), so we didn't need to worry about it.

[jshimkoski]

I did a write up about scoping preflight forever ago.

This might be helpful as it is mostly a drop in replacement for preflight (keep in mind this is from awhile ago).

https://dev.to/ajscommunications/scoping-normalized-preflight-css-c29

[architchandra]

Thank you, @elilabes, @ravinsharma7 and @jshimkoski. I was finally able to get this done thanks to postcss-prefix-selector. I also referred to this helpful answer by @davidwebca.

Here's what my postcss.config.js looks like (only the postcss-prefix-selector is important):

let prefixOverrideList = ['html', 'body'];

module.exports = {
    plugins: {
        'postcss-import': {},
        'tailwindcss/nesting': {},
        tailwindcss: { config: 'src/assets/css/tailwind.config.js' },
        'postcss-prefix-selector': {
            prefix: '.prefix',
            transform: function (prefix, selector, prefixedSelector, filePath, rule) {
                if (prefixOverrideList.includes(selector)) {
                    return prefix;
                } else {
                    return prefixedSelector;
                }
            }
        },
        autoprefixer: {},
    },
}

[s0ber]

I'm not sure if it's a good way to do it, but I was able to do it with following config:

let prefixOverrideList = ['html', 'body']

module.exports = {
  plugins: {
    'tailwindcss': {},
    'postcss-prefix-selector': {
      prefix: '.use-tailwind',
      transform: function (prefix, selector, prefixedSelector, filePath, rule) {
        if (!rule.raws.tailwind) return selector

        if (prefixOverrideList.includes(selector)) {
          return `:where(${prefix})`
        } else {
          return prefixedSelector
        }
      }
    },
    'autoprefixer': {}
  }
}