-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Rework list utilities #761
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
Conversation
Running a Twitter poll right now to help decide if we just unstyle lists in Preflight: https://twitter.com/adamwathan/status/1105905209073590272 Becoming more and more convinced we should, because if we already unstyle headings then we've already broken any expectation of typography to look "right" out of the box. What might be useful is to solve this same problem by creating some sort of |
9f529da
to
4be5af2
Compare
Decided to reset list styles by default based on the feedback on Twitter and discussions with trusted members of the community. This actually brings Preflight closer to SUIT CSS Base which it was initially derived from anyways. |
I know it's a slippery slope but maybe the list reset could be a configuration option. For a simple docs site I generally want some default styling on lists / headings. I guess the alternative is to not include tailwind/base. |
Yeah, you can always roll your own normalization/reset on those cases. Or still use tailwind's base and override the ul,ol rules after the base globally or with a component type class, if that's not an issue in the project. |
I think a better approach would be for us to provide some sort of optional default typography styles you can pull in with a class, like I make a class like that for every project already, so I will spend some time after 1.0 is out thinking through a decent way to make that reusable. |
Exactly what we do for CMS based regions of the page, and I prefer to be explicit in these instances, and work with default styling removed, preventing the need for a lot more |
This PR removes the
list-reset
utility in favor of a newlist-none
utility that only sets thelist-style-type
, and makes it possible to add more list-style-type utilities by customizing your configuration file.It also adds
list-inside
andlist-outside
utilities for settinglist-style-position
.This is a potentially annoying breaking change, because previously
list-reset
also setpadding: 0
, andlist-none
doesn't do that.That means that to upgrade you have two options:
Replace any instances of
list-reset
withlist-none p-0
.Redefine
list-reset
in your own CSS:The motivation for this is mostly about simplicity and consistency in the framework API.
list-reset
is sort of an odd class because it sets two unrelated properties, and nothing else in Tailwind (excepttruncate
, which I'm also thinking hard about) does that. It meant we had to be careful to always definelist-reset
before our padding utilities for them to be composable, which isn't a huge deal, but was always a weird rule to have to remember when working on Tailwind itself.I'm a bit conflicted on removing
list-reset
because I do think it's convenient, and I worry I am over-optimizing for keeping the framework itself simple. If people really, really want to keep it and don't want to have to writelist-none p-0
instead, I could probably be convinced the shoulder the complexity. Another alternative is just removing list styles by default in general, and making them opt-in instead, so you'd never have to writelist-reset
but sometimes you'd have to writelist-disc pl-4
or similar to get a normal looking list.