Skip to content

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

Merged
merged 5 commits into from
Mar 14, 2019
Merged

Rework list utilities #761

merged 5 commits into from
Mar 14, 2019

Conversation

adamwathan
Copy link
Member

This PR removes the list-reset utility in favor of a new list-none utility that only sets the list-style-type, and makes it possible to add more list-style-type utilities by customizing your configuration file.

It also adds list-inside and list-outside utilities for setting list-style-position.

This is a potentially annoying breaking change, because previously list-reset also set padding: 0, and list-none doesn't do that.

That means that to upgrade you have two options:

  1. Replace any instances of list-reset with list-none p-0.

  2. Redefine list-reset in your own CSS:

    .list-reset {
      list-style: none;
      padding: 0;
    }

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 (except truncate, which I'm also thinking hard about) does that. It meant we had to be careful to always define list-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 write list-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 write list-reset but sometimes you'd have to write list-disc pl-4 or similar to get a normal looking list.

@adamwathan
Copy link
Member Author

adamwathan commented Mar 13, 2019

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 rich-text class or similar, that provides some opinionated base typography styles based on the default theme values. Would be tricky to get right but might be useful, could also feel like baggage for people who don't need the help though.

@adamwathan
Copy link
Member Author

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.

@adamwathan adamwathan merged commit 310b848 into next Mar 14, 2019
@adamwathan adamwathan deleted the list-utilities branch March 14, 2019 00:05
@leevigraham
Copy link

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.

@tlgreg
Copy link

tlgreg commented Mar 19, 2019

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.

@adamwathan
Copy link
Member Author

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.

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 .rich-text or something. Generally you don't want the browser default heading styles because they will be different than the values in your config file, although for lists that isn't really an issue.

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.

@sleicester
Copy link

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 .rich-text or something.

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 list-reset. Smooth moves.

@adamwathan adamwathan mentioned this pull request Aug 13, 2019
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

Successfully merging this pull request may close these issues.

4 participants