-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
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. |
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 get the old behaviour back, you can manually re-enable the experimental "optimize universal defaults" option in your // 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 👍 |
Thank you @reinink for your explanations. 👍 I will try an upgrade to v3.0.12 within the next few days. |
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 |
@richyrb00 Do you have Preflight disabled as well? This is a necessary step in addition to enabling the experimental |
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. |
@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:
These default button styles come from Preflight, our CSS reset. You can see that here: So are you saying that you want Preflight, but you don't want the button styles specifically? |
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 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. |
@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 |
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 attributeborder="0"
is found in the html, tailwind will incorrectly apply some preflight styling again. The following css markup is generated by tailwind: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
.The text was updated successfully, but these errors were encountered: