-
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
Add consistent base styles for buttons and form controls #15036
Conversation
d0e89d4
to
bfdaaaf
Compare
packages/@tailwindcss-upgrade/src/codemods/migrate-forms-reset.ts
Outdated
Show resolved
Hide resolved
packages/@tailwindcss-upgrade/src/codemods/migrate-forms-reset.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
33b32d6
to
3ea01c3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still testing, but let's add a changelog entry 👍
After upgrading to alpha.36, this change had some unexpected effects. |
@madmoizo Hey! Curious what the difference were for you/how did this affect your site? Do you use the |
Regarding the opt out: you can add this to your css: html {
color-scheme: light dark;
} Regarding the general form changes, you can opt-out by pasting this code snippet; /*
In Tailwind CSS v4, basic styles are applied to form elements by default. To
maintain compatibility with v3, the following resets have been added:
*/
@layer base {
input,
textarea,
select,
button {
border: 0px solid;
border-radius: 0;
padding: 0;
color: inherit;
background-color: transparent;
}
} However, still curious how you noticed the issue. |
@madmoizo Completely understand and hear your feedback here. The
But yeah this snippet is not getting you back the exact v3 defaults but is more or less a fix to reset the padding/spacing stuff for compatibility. |
:where(select:not([multiple], [size])) optgroup { | ||
color: FieldText; | ||
background-color: Field; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just meant it's parts of the changes introduced by the new tailwind base styles (which adds a not directly visible change)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this makes sense but the default would also be styled by the browsers and in order, you can think of our new preflight more like a consistent default browser style that works across all our browser targets.
Closes #15071 This PR reverts the changes in #15036 which add consistent base styles for buttons and form controls to Preflight. While this felt like a good idea (for the reasons explained in that PR), practically this is just too disruptive of a change for people upgrading from v3 to v4. While updating some of our projects to v4 we found ourselves adding classes to undo styles more often than we expected, and it also felt inconsistent to have to use a different set of classes to style a link or a button when we wanted them to look the same. We also decided it feels a little strange that you could change the border color of an element without ever specifying that it should have a border, for example this just feels a little wrong: ```html <button class="border-blue-500"> ``` We also needed to set a default `color-scheme` value for any of this stuff to work which breaks the ability to use the `color-scheme` meta tag. Since this change was a fairly major breaking change and we aren't feeling much benefit from it, it doesn't feel worth making this change for v4. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Closes #15071 This PR reverts the changes in #15036 which add consistent base styles for buttons and form controls to Preflight. While this felt like a good idea (for the reasons explained in that PR), practically this is just too disruptive of a change for people upgrading from v3 to v4. While updating some of our projects to v4 we found ourselves adding classes to undo styles more often than we expected, and it also felt inconsistent to have to use a different set of classes to style a link or a button when we wanted them to look the same. We also decided it feels a little strange that you could change the border color of an element without ever specifying that it should have a border, for example this just feels a little wrong: ```html <button class="border-blue-500"> ``` We also needed to set a default `color-scheme` value for any of this stuff to work which breaks the ability to use the `color-scheme` meta tag. Since this change was a fairly major breaking change and we aren't feeling much benefit from it, it doesn't feel worth making this change for v4. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
This PR introduces consistent base styles for buttons and form controls in Tailwind CSS v4.
Motivation
In v3, form elements lack default styles, which can be confusing—especially when certain elements, like a text input without a placeholder or value, are rendered completely invisible on the page.
The goal of this change is to provide reasonable default styles for buttons, inputs, selects, and textareas that are (mostly) consistent across all browsers while remaining easy to customize with your own styles.
This improvement should make Tailwind more accessible for developers new to the framework and more convenient in scenarios where you need to quickly create demos (e.g., using Tailwind Play).
Light and dark mode support
These styles support both light and dark mode, achieved using the
light-dark()
CSS function. While browser support for this function is still somewhat limited, Lightning CSS transpiles it to a CSS variable-based approach that works in older browsers.For this approach to function correctly, a default
color-scheme
must be set in your CSS (as explained in the Lightning CSS documentation). This PR addresses this requirement by setting thecolor-scheme
tolight
on thehtml
element in Preflight.Breaking changes
While we don’t expect these changes to significantly impact v3 users upgrading to v4, there may be minor differences for those relying on the simpler v3 styles.
For example, Preflight now applies a
border-radius
to buttons and form controls. If you weren’t explicitly setting the border radius to0
in your project, you’ll need to do so to restore the previous look.Thankfully, reverting to the v3 styles is straightforward—just add the following reset to your CSS:
It’s worth noting that this reset doesn't touch the
::file-selector-button
styles that were added in this PR. This is because it's not possible to reliably "undo" these styles and restore the original user-agent styles (which is what was used in v3), as these are different in each browser. However, these new styles actually match the defaults in most browsers pretty closely, so hopefully this just won't be an issue.Codemod
This PR includes a codemod that automatically inserts the above mentioned v3 reset to help avoid breaking changes during the upgrade. The codemod will insert the following CSS:
Testing
These changes have been tested across a wide range of browsers, including Chrome, Safari, Firefox, Edge, and Opera on macOS and Windows, as well as Safari, Chrome, Firefox, and several lesser-known browsers on iOS and Android.
However, some quirks still exist in certain mobile browsers, such as iOS Safari, which adds too much bottom padding below date and time inputs:
The only reliable way to address these issues is by applying
appearance: none
to these form controls. However, this felt too opinionated for Preflight, so we’ve opted to leave such adjustments to user-land implementations.