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

Base styling is applied for border despite disabling preflight #6923

Closed
tpetry opened this issue Jan 6, 2022 · 9 comments
Closed

Base styling is applied for border despite disabling preflight #6923

tpetry opened this issue Jan 6, 2022 · 9 comments

Comments

@tpetry
Copy link

tpetry commented Jan 6, 2022

What version of Tailwind CSS are you using?

3.0.11

What build tool (or framework if it abstracts the build tool) are you using?

tailwindcss --input tailwind-input.css --output tailwind-output.css

Reproduction URL

https://play.tailwindcss.com/otBaLPEx8j

Describe your issue

When developing markup for an email (which is a lot more verbose than for desktops) I disabled the core preflight styling (preflight: false) as it is more desktop orientated. But as soon as an attribute border="0" is found in the html, tailwind will incorrectly apply some preflight styling again. The following css markup is generated by tailwind:

*, ::before, ::after {
  --tw-border-opacity: 1;
  border-color: rgb(229 231 235 / var(--tw-border-opacity))
}

So basically it's applying a default styling to everything.

As css markup needs to be inlined for emails to work correctly in all cases for all clients the two css rules are repeated hundreds of times. Which is no problem in theory, but gmail has a clipping limit: Any html markup after a magic ~100KB mark will be hidden first, so the more complex the mail will get the nearer this limit is reached because every new element will have these two rules. Despite setting preflight: false.

@gehrisandro
Copy link

I ran into the same issue today.

Version 3.0.0 and 3.0.1 are not affected. The issue is caused by the changed made in version 3.0.2: #6461

As I am not familiar with the tailwindcss code base I wasn't able to understand what effect the changes made in the PR mentioned above has. Simply reverting this PR would fix this issue here but will probably reintroduce another issue.
Maybe @RobinMalfait could help us to understand what his PR does and / or how to fix this issue.

@reinink
Copy link
Member

reinink commented Jan 7, 2022

Hey @tpetry and @gehrisandro,

So Tailwind CSS v3.0 initially shipped with the experimental "optimize universal defaults" option enabled. This was an optional feature introduced in v2.0 to help with an edge case performance issue in Safari. You can read about all the details of that in #4850.

However, it created unexpected issues for folks using Tailwind CSS in isolated environments, like Vue and Svelte components as well as CSS modules. So we had to disabled it, and revert back to the previous behaviour (#6461). This is what caused the universal selectors (*) to be added to your outputted CSS in version 3.0.2.

To get the old behaviour back, you can manually re-enable the experimental "optimize universal defaults" option in your tailwind.config.js file like this:

// tailwind.config.js
module.exports = {
  experimental: {
    optimizeUniversalDefaults: true,
  },
  content: [
    // ..
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

That said, in v3.0.12 (released a few hours ago), we actually moved the default border color out of the defaults and back into preflight, so that change alone might be enough to solve your issues. See #6926 for more information.

I should probably also mention that the experimental "optimize universal defaults" option was very much not intended for your email use-case. It's designed to help with performance issues with large pages in Safari. So, the fact that enabling this fixes your email template issues is very much just coincidence, and future changes to this feature could break things for you. You've been warned. 😅

Finally, if you're building email templates with Tailwind CSS, I'd recommend checking out Maizzle (https://maizzle.com). It's a tool designed just for this purpose. They actually disable some of Tailwind's default plugins and replace them with more email compatible versions. So, definitely check that out 👍

@reinink reinink closed this as completed Jan 7, 2022
@gehrisandro
Copy link

Thank you @reinink for your explanations. 👍

I will try an upgrade to v3.0.12 within the next few days.

@richyrb00
Copy link

Hey @tpetry and @gehrisandro,

So Tailwind CSS v3.0 initially shipped with the experimental "optimize universal defaults" option enabled. This was an optional feature introduced in v2.0 to help with an edge case performance issue in Safari. You can read about all the details of that in #4850.

However, it created unexpected issues for folks using Tailwind CSS in isolated environments, like Vue and Svelte components as well as CSS modules. So we had to disabled it, and revert back to the previous behaviour (#6461). This is what caused the universal selectors (*) to be added to your outputted CSS in version 3.0.2.

To get the old behaviour back, you can manually re-enable the experimental "optimize universal defaults" option in your tailwind.config.js file like this:

// tailwind.config.js
module.exports = {
  experimental: {
    optimizeUniversalDefaults: true,
  },
  content: [
    // ..
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

That said, in v3.0.12 (released a few hours ago), we actually moved the default border color out of the defaults and back into preflight, so that change alone might be enough to solve your issues. See #6926 for more information.

I should probably also mention that the experimental "optimize universal defaults" option was very much not intended for your email use-case. It's designed to help with performance issues with large pages in Safari. So, the fact that enabling this fixes your email template issues is very much just coincidence, and future changes to this feature could break things for you. You've been warned. 😅

Finally, if you're building email templates with Tailwind CSS, I'd recommend checking out Maizzle (https://maizzle.com). It's a tool designed just for this purpose. They actually disable some of Tailwind's default plugins and replace them with more email compatible versions. So, definitely check that out 👍

unfortunatly for me adding the experimental flag didn't work for me on [email protected]. we are trying to upgrade from v2 and it seems the only version 3 we can get to work correctly where it doesn't add user agent styling to buttons for example is version 3.0.2

@reinink
Copy link
Member

reinink commented Jan 25, 2022

@richyrb00 Do you have Preflight disabled as well? This is a necessary step in addition to enabling the experimental optimizeUniversalDefaults option. You can read more about that here:

https://tailwindcss.com/docs/preflight#disabling-preflight

@richyrb00
Copy link

@richyrb00 Do you have Preflight disabled as well? This is a necessary step in addition to enabling the experimental optimizeUniversalDefaults option. You can read more about that here:

https://tailwindcss.com/docs/preflight#disabling-preflight

yes i tried a few things including what you suggested.

i don't actually want preflight to be disabled though as i want everything to be normalized and clean for then tailwind to style the elemens on the page.

i don't believe the feature of improving the accessibility by displaying the base boarder styling per browser user agent should have been implemented this way. and should have been flipped by allowing users to add the feature flag to turn it on rather than turn it off.. if that makes sense.. causes those that have existing large sites a headache to upgrade.

@reinink
Copy link
Member

reinink commented Jan 25, 2022

@richyrb00 Oh, I assumed that you were trying to do this in the context of building an email, since that's what this issue is primarily about. Forgive me, but now I'm confused:

we are trying to upgrade from v2 and it seems the only version 3 we can get to work correctly where it doesn't add user agent styling to buttons for example is version 3.0.2

These default button styles come from Preflight, our CSS reset. You can see that here:

https://github.com/tailwindlabs/tailwindcss/blob/master/src/css/preflight.css#L156-L190

So are you saying that you want Preflight, but you don't want the button styles specifically?

@richyrb00
Copy link

richyrb00 commented Jan 26, 2022

@richyrb00 Oh, I assumed that you were trying to do this in the context of building an email, since that's what this issue is primarily about. Forgive me, but now I'm confused:

we are trying to upgrade from v2 and it seems the only version 3 we can get to work correctly where it doesn't add user agent styling to buttons for example is version 3.0.2

These default button styles come from Preflight, our CSS reset. You can see that here:

https://github.com/tailwindlabs/tailwindcss/blob/master/src/css/preflight.css#L156-L190

So are you saying that you want Preflight, but you don't want the button styles specifically?

@reinink

the issue is i don't want to disable preflight. i want tailwind to start from scratch and we add in all the classes required to style the components. in a normal tailwind workflow

with us using 3.0.2 we have no issues. when we move up to latest which is now 3.0.16

before ( 3.0.2 )
Screenshot 2022-01-26 at 09 56 48
Screenshot 2022-01-26 at 09 56 53

After ( 3.0.16 )
Screenshot 2022-01-26 at 10 10 02
Screenshot 2022-01-26 at 10 10 07

this boarder is been added by the user agent and so it seems it isn't been normalized through tailwind as it previously was?

there are other issues around the use of the boarder missing on other elements when upgrading to 3.0.16

whatever has been added or removed between the 2 versions is going to cost us alot of time to update all the components and unsure if this was intended on tailwind's decision or if this is a bug as it currently stands?

Also to add that there is no no consistancy with local and production development.
on Local the issue isn't shown. when we deploy to vercel the issue raises it's head.
We are using a nextjs build using postcss config as shown in the tailwindcss documents.

@reinink
Copy link
Member

reinink commented Jan 26, 2022

@richyrb00 Okay, just to to confirm so I am clear on what's going wrong here, everything is working correctly locally, but in production (on Vercel), you're seeing these border issues? Is that correct?

There shouldn't be any breaking changes between v2.x and v3.016 when it comes to the borders. I suspect this is more of an issue with the Vercel deployment process. Maybe Vercel isn't recognizing your content paths properly?

Someone else has run into issue with Vercel as well: #6110

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

No branches or pull requests

4 participants