Tailwindcss: Tailwind CSS v1.0 To-Dos

[adamwathan]

Have been keeping track of this stuff in my personal to-do tracker but publishing them here in case anyone is interested.

Naturally a ton of stuff has already been done for v1.0 and deleted from my to-do list, so this is only the stuff remaining as of today.

Expect this list to grow and change over the next few weeks as I work towards finishing v1.0, but generally these are the things I've got lined up. They aren't in any sort of priority order or anything.

Done/Merged

• [x] Re-evaluate flex-grow/flex-no-grow, etc.
• [x] Re-assess using postcss-selector-parser for escaping
• [x] Update plugins to source their config from theme/variants
• [x] Think about if there's a smarter way to make sure the separator is escaped
• [ ] Pass theme and variants to plugins explicitly? No measurable benefit, easy to add later
• [x] Add new shadows
• [x] Rename config function to theme?
• [x] Fix letterSpacing classes not being escaped
• [x] Add 56 as a width?
• [x] Add extended widths (48, 56, 64) to entire spacing scale?
• [x] Make flex-* customizable
• [ ] Remove .clearfix? Nah still useful enough to not make people add it themselves.
• [x] Add new maxWidth scale
• [x] Revisit which variants to enable by default for split up text style plugins
• [x] Make preflight more hardcore, reset headings, etc.
• [x] Autodetect presence of tailwind.config.js?
• [ ] Headings should inherit line-height like they inherit font-size and font-weight. Not necessary, browser inherits line-height already for headings.
• [x] Inherit font-related properties on form controls by default (line-height, font-family, color, maybe others, see sanitize.css for ideas)
• [x] Use line-height: 1.5 on body or html by default (why not? I never want 1.15 and we set that 🤷‍♂️)
• [x] Use system font stack by default instead of "sans-serif", I literally never want that either
• [x] Use fontFamily.mono for pre/code if possible, fall back to monospaced (beware double monospace thing)
• [x] Add text-6xl? 64px?
• [x] Add new default color palette
• [x] Bump sm breakpoint up to 640px?
• [x] Inherit color and text-decoration on links
• [x] Reconsider lists core plugin, maybe handle list style only and not padding
• [ ] Re-evaluate truncate, possibly replace with ellipsis-only utility Class is convenient and useful, could still add ellipsis utility separately though
• [x] Consider making break-normal handle both properties to provide a nicer experience
• [x] Get rid of pin utilities in favor of top/right/bottom/left/inset? Unsure if worth break.
• [x] Consider if container should become a true core plugin instead of an included third-party plugin
• [x] Split whitespace plugin into whitespace and wordBreak/wordWrap?
• [x] Rework CLI for new config structure
• [x] Make sure shadow-outline matches new blue
• [ ] Error if we find @tailwind preflight in your CSS or keys in the wrong place in your config file to help guide people during the upgrade process? Whatever, can do this if it actually bites people.
• [ ] Consider if defaultConfig/defaultTheme need to be separate files or even importable? Maybe make it possible to export a function from your config, and we just pass you the defaults? Will keep these exports for now, we could add function syntax later if it feels like a slicker solution since it is non-breaking
• [x] Make img, canvas, video, etc. block by default, and constrain max width?
• [ ] Make utilities important by default? I always do this on my own projects Easy to tweak yourself and it's nice that inline-styles override utilities if they aren't important
• [x] Maybe pass theme _function_ to config callbacks?
• [ ] Consider trying to make form elements more consistent by default across browsers? BuzzFeed Solid framework pretty good reference for super vanilla looking forms.
• [x] Fix theme('negativeMargin.5') sort of stuff, maybe by negating all values in the default config in the callback
• [x] Write upgrade guide
• [x] Write function/tool to upgrade 0.x config files

PR Opened

• [ ] Consider removing border radius on inputs because of the iOS crap, and fixing radio buttons with just a [type="radio"] selector to keep specificity down

Next (painful)

Next (straightforward)

• [ ] Make sure shadow-inset doesn't suck
• [ ] Update the docs

Next (could wait until after 1.0)

• [ ] Add sanity test for a heavily customized config
• [ ] Allow specifying a base config to extend (extends root level key)
• [ ] Add disabled variant?
• [ ] Pass parseSelector to plugins?

[o-t-w]

When is the likely release date? Would love to use it on a project I'm about to start :)

[adamwathan]

March 20th or 21st 👍

[hacknug]

What about adding links in the docs that take you to each of core plugins source code?

[adamwathan]

Yeah that's a good idea 👍 Will try and fit that in before release, if not can add it shortly after.

[chessydk]

Hello - and thx. for tailwind - we're happy users.

There's a spefic preflight styling we're not happy about though:

input::placeholder,
textarea::placeholder {
color: inherit;
opacity: 0.5;
}

The color: inherit makes the placeholder color follow the color of the input (of course), but that is a bit too opiniated for us and rather difficult to override without using classes or !important

[adamwathan]

Hey @chessydk! If we removed that, what would you do to style your placeholders instead? Would you just use the browser default, or would you still write your own classes to do it?

[chessydk]

@adamwathan Regarding placeholder: We would set a default color our selves and if needed, set classes.

[tlgreg]

@chessydk I do not think that you would need !important to override that rule. Your own global css should come after tailwind's preflight, so it can override the same specificity rules.

That's true that tailwind doesn't have placeholder utilities out of the box. I would imagine it could be done maybe with a variant plugin. Or just declare the utilities with plain css.

quick example

[adamwathan]

@chessydk Got it! What I'm wondering is how removing that style would make your life any easier? You would still need to add your own placeholder color, and adding your own placeholder color will still override the one Tailwind sets by default already.

Here's a quick demo showing how you can override those styles by just adding your own CSS in between preflight and the rest of Tailwind's styles:

https://jsfiddle.net/1zcgr0f5/

[florianbouvot]

@adamwathan did you consider following a modular scale for font-size?

[adamwathan]

@florianbouvot I don't really like the super mathematical modular scales because you end up with fractional values that different browsers round differently. Our system is loosely based in the ideas of modular scales, but normalized to sane whole values that work well with our base-4 spacing system.

[florianbouvot]

@adamwathan I understand, thank you for your feedback

[dbilovd]

@adamwathan Before the 21st of March, any "dev" build of 1.0 one can begin trying out?

[adamwathan]

Yeah hoping to get one out today but I've been saying that every day this week 😩 Trying to get all of the breaking changes out of the way if I can, but there are probably still going to be a few even after the first dev build.

[trivago-vgarcia]

@adamwathan What do you think about allow define in the config file variables for classes names and sides?

.{className}{side?}-{size}

The reason is that we use a different naming convention in our utilities library that was written without any generator. We think there is a lot potential using Tailwind to generate the library.

.u-color--black

Prefix: u-*
Property: color
Separator: --
Value: black

We have a fork that has 100% tests passed.

[o-t-w]

Is it out yet? 😄

[adamwathan]

Beta is!

https://github.com/tailwindcss/tailwindcss/releases/tag/v1.0.0-beta.1

[KaniRobinson]

@adamwathan there is a bit of an issue with :not-italic it throws the following error on beta.3

ERROR in ./assets/styles/app.css (./node_modules/css-loader/dist/cjs.js??ref--5-oneOf-1-1!./node_modules/postcss-loader/src??ref--5-oneOf-1-2!./assets/styles/app.css)
Module build failed (from ./node_modules/postcss-loader/src/index.js):
TypeError: Cannot read property 'body' of undefined
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/@thedigies/hexy/dist/hexy.css:11188:3
    at explodeSelector (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss-selector-not/dist/index.js:26:33)
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss-selector-not/dist/index.js:41:27
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:239:18
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:135:18
    at AtRule.each (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:101:16)
    at AtRule.walk (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:131:17)
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:148:24
    at Root.each (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:101:16)
    at Root.walk (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:131:17)
    at Root.walkRules (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss/lib/container.js:237:19)
    at Object.plugin (/Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss-selector-not/dist/index.js:39:11)
    at /Users/kanirobinson/DigitalProfile/core-pwa/node_modules/postcss-preset-env/index.cjs.js:186:20

Following Line in question:

  .md\:not-italic {
    font-style: normal;
  }

[adamwathan]

Make sure you are on the latest version of postcss-selector-not, that's a bug in their library. It looks like you are using postcss-preset-env, so you probably just need to update your version of that.

[KaniRobinson]

@adamwathan Thank you for that very prompt response, I'll do this now!

[azurinspire]

https://github.com/tailwindcss/tailwindcss/releases/v1.0.0-beta.1
Just tested this documentation to one project of mine and I think there is little error, this:

borderColor: theme => ({
+       default: theme('colors.grey-light'),
+       ...colors,
+     }),

should be:

borderColor: theme => ({
+       default: theme('colors.grey-light'),
+       ...theme('colors'),
+     }),

[adamwathan]

Fixed, thanks @azurinspire!

[tance77]

Did the syntax change for applying certain classes onto different screen sizes?

.custom-input{
    @apply .appearance-none .block .w-full .bg-grey-lighter .text-grey-darker .border .border-grey-lighter .p-1 .rounded .leading-tight;
    font-size: 12px;
    @screen sm{
        @apply .py-2 .px-4 .text-sm;
    }
    @screen md{
        @apply .py-3 .text-base;
    }
}

It seems to complain about the sm in @screen sm. Say's No `sm` screen found.

UPDATE

Oh never mind I just realized this was fixed in an update you release.

Oh by the way https://tailwindcss.com/docs/what-is-tailwind/ as of this moment points to 1.0.0-beta.1 and not the current beta.

[tance77]

Grey has become Gray

[AndreasHeintze]

Can you please replace the rem's with px instead?
https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/
Or at least make it an option when creating tailwind.js.

[benface]

@AndreasHeintze I think the point of rem is that you can (not saying you should) scale everything proportionally by changing the root font size. With px you can't. Everything else is exactly the same, so why not give that benefit?

Also, this should probably be its own issue.

[AndreasHeintze]

@benface Read the article I linked to and you will see that px makes much more sense now.
I'll put it into a new issue.

[trivago-vgarcia]

@adamwathan I have created a PR related with my previous comment. As you can see, there is no change of the default naming convention. Is an extra config option.

References:
https://github.com/tailwindcss/tailwindcss/pull/807
https://github.com/tailwindcss/tailwindcss/issues/692#issuecomment-473092490

[avvertix]

I just gave a spin on the next version (1.0.0-beta.4). The installation went smooth. I just noted that executing

npx tailwind init --full

like documented in https://next.tailwindcss.com/docs/configuration/, generates the following output, which I believe is related to argument validation

Path must be a string. Received undefined
.\node_modules\tailwindcss\lib\cli.js

In any case the file is generated in the root of the project and the basic configuration seems to work

[findorf]

I have been trying to upgrade an existing solution to the new beta. But I'm kind of stuck. Is there any examples where using vue, you have an @apply from within a vue component file, using next version (1.0.0-beta.4)?

<style lang="less" scoped> .navigation-item { @apply text-blue; &.active { @apply text-blue; } } </style>

[d8vjork]

@findorf I think that's more related to your VueJS setup instead of a Tailwind problem.

The @apply is consider when you do a tailwind build because of PostCSS and the styles that are there

[mikoelsuperbeasto]

@findorf I got the same problem with my VueJS setup. I noticed that if i use the @tailwind preflight, @tailwind components and @tailwind utilities in my main stylesheet, i can use @apply from my vue component file without any special configuration.

But if I use @tailwind method, i can't do css importation @import("/.button.css").

[adamwathan]

@mikoelsuperbeasto are you using postcss-import? If so you should use our imports instead of the Tailwind directives:

[mikoelsuperbeasto]

@adamwathan Yes you are right.. work perfectly and i just understand my mistake. I was making my custom @import('whatever.scss') between @import "tailwindcss/components" and @import "tailwindcss/utilities" has said in https://tailwindcss.com/docs/installation#3-use-tailwind-in-your-css

Good job with v1 btw :)

[marcfilleul]

Hi,
I'm customizing my tailwind.config.js and was wondering if it would be possible to use a variable for spacing.

For example, in order to have all the widths available, I'd like to be able to use a p-X that would generate a padding: X*Nrem.

In my particular case, I use a base font-size of 10px to have an easier way to mentally associate px to rem, so that 1rem ~ 10px.

And I'd like to be able to have a Spacing config which would look like: "Npx": "N/10rem" instead of having a fixed spacing scale.

Is it possible ?

[adamwathan]

Hey @willdante sorry I don't fully understand what you mean. You actually want a class like p-Npx with a literal "N" character, or is that a placeholder for something? Can you explain with some more examples what you want?

[marcfilleul]

@adamwathan,

N would be a variable that should get any number input used with spacing prefixes in html.

The idea would be to have a unique line in the configuration like this:

extend: { spacing: { "(VARIABLE)": "(VARIABLE*N)rem", },

Then in the html, I could use any number for width, padding, margin and have a proportional result in rem unit.

In my case, I would have in the config file:

"Npx": "N*0.1rem"

And in the html, if I use w-10, it would give width: 1rem.

I'm relatively new to dev and don't know if it's possible but it would be ideal to have an unlimited spacing scale set.

[adamwathan]

Ah got it, yeah it's not possible to make it unlimited because all of the classes would need to exist in the CSS file, so it would be a CSS file of unlimited size, haha. Have to define some sort of fixed set.

[marcfilleul]

Indeed ^^

I was not thinking of a real unlimited scale but maybe a quicker way to generate many more widths without writing all of them.

But I guess it's not this useful.

[hacknug]

@willdante not sure it's what you're looking for but here's a small helper function I have on my config files to help me generate a scale:

const pxToRem = (px, base = 16) => `${px / base}rem`
const getScaleValues = (step = 4, limit = 64) => {
  let scale = {}

  Array(limit / step).fill()
    .map((value, key) => pxToRem(key + 1))
    .forEach((value, key) => {
      scale[(key + 1) * step] = value
    })

  return scale
}

By default it'll create a scale with values ranging from 0 to 64 every 4px.

[marcfilleul]

@hacknug,

Looks like it could be what I need, thank you.
I have to figure out how to use it exactly though.

If I understand, I can add it directly to my tailwind.config.js ?

But how do I use the scale result then ?

[hacknug]

@willdante sorry I forgot to also add the other helper used inside getScaleValues (that's fixed now).

Basically, the way it works is you call the function passing a step (the difference in pixels between values of your scale) and a limit (the biggest value you want on your scale). In this example you can see two equivalent ways of defining the same scale:

let scale = getScaleValues(4, 64)
let scale = {
    4: "0.0625rem",
    8: "0.125rem",
    12: "0.1875rem",
    16: "0.25rem",
    20: "0.3125rem",
    24: "0.375rem",
    28: "0.4375rem",
    32: "0.5rem",
    36: "0.5625rem",
    40: "0.625rem",
    44: "0.6875rem",
    48: "0.75rem",
    52: "0.8125rem",
    56: "0.875rem",
    ​60: "0.9375rem",
    64: "1rem",
}

[hacknug]

Agree BUT when I use it it’s because I’m not implementing my own designs 😉

El 26 abr 2019, a las 10:05, Daan Haitsma [e-mail] escribió:

That's a neat helper function, but as some wise folks once said:

A linear scale won’t work
Creating a spacing and sizing system isn’t quite as simple as something like “make sure everything is a multiple of 4px” — a naive approach like that doesn’t make it any easier to choose between 120px and 125px.

😉

[mikeerickson]

@adamwathan I have watched this thread and seems the release has been a moving target?

I am about to embark on a brand new project (using vue-cli) and would like to start with Vue 1.0 as opposed to "wasting" time with 0.7.x (dont want to have to refactor a bunch of code when 1.0 is final).

Do you have installation and configuration instructions for new installations (with vue-cli)

[MichaelDeBoey]

@mikeerickson You can just start with the latest beta release, since the config is not going to change a lot anymore

[adamwathan]

I don't have specific instructions for vue-cli but all you need to do is create a postcss.config.js file and add Tailwind there as a plugin, so just following the generic PostCSS installation instructions here:

https://next.tailwindcss.com/docs/installation#using-tailwind-with-postcss

[mikeerickson]

@michaeldeboey thanks for feedback, that is in fact what I have done and now on my way. Got some doc links from @adamwathan yesterday which got me going

[mikeerickson]

@adamwathan I used the beta documentation link you sent over yesterday and that was all I needed. I am good to go now.

[kevinruscoe]

I'm not sure if this is the best place for this comment, and I'm pretty sure you've got this on your mind (or it may even be mentioned somewhere else), but I think think the 'grouped' pages need footer links to their related properties.

For example, if you're on the border-style docs page - https://next.tailwindcss.com/docs/border-style/ I think it'll be beneficial to link to the other properties, such as width, radius, colour.

Same with text and their properties, font, background, etc.

[vinayakkulkarni]

Yes! The disabled variant would be ultimately useful.

Something which applies .opacity-50 to elements when the element is disabled.

[pxwee5]

Can we not load css if the variant property isn't set? For e.g.
If zIndex: ['responsive'] is not available in variants, don't load the utility classes concerning z-index.

This is to prevent the case where after upgrading Tailwind, the new feature classes gets added automatically without notifying the user.

[tlgreg]

Disabling utilities are controlled under corePlugins now, there is also the option to use a whitelist. docs
The new plugin(s) could be mentioned in the upgrade guide though.

[pxwee5]

@tlgreg Is there a reason why we can't just output the classes for properties that are only available in variants ? E.g.

variants: {
  backgroundColors: ['responsive', 'hover', 'focus'],
  // Comment or delete everything else
}

TW only generates background-color classes and ignores the rest. Wouldn't that make more sense? Rather than have to maintain another set of object in the corePlugins property.

---

Getting into perspective:

variants: {
  // backgroundAttachment: ['responsive'],
  backgroundColors: ['responsive', 'hover', 'focus'],
  // backgroundPosition: ['responsive'],
  // backgroundRepeat: ['responsive'],
  // backgroundSize: ['responsive'],
}

Is easier to manage than

variants: {
  backgroundAttachment: ['responsive'],
  backgroundColors: ['responsive', 'hover', 'focus'],
  backgroundPosition: ['responsive'],
  backgroundRepeat: ['responsive'],
  backgroundSize: ['responsive'],
},
corePlugins: {
  backgroundAttachment: false,
  backgroundPosition: false,
  backgroundRepeat: false,
  backgroundSize: false
} 

[tlgreg]

@pxwee5 Can't base something on omission. The new way of building a configuration is by normally only including the necessary keys and it's merged with defaults.
Could have been

{
  variants: {
    // backgroundColors: ['responsive', 'hover', 'focus'],
    backgroundColors: false,
  },
}

But then it feels better to have it under corePlugins. Also, this makes more sense for plugins that do not support variants, like the preflight.

[pxwee5]

@tlgreg Noted. However that could be something to take into consideration, seeing there's a couple thumbs up on variants overwriting the default rather than merging.

I know we're supposed to use TW with PurgeCSS, but many times we don't, especially if classes are added to template on runtime by a CMS. And it's hard to detect increase in css bundle size when new updates introduces new classes. I'd also much rather to add the new feature myself than automatically added (merged) after an update.

Two cents :)

[adamwathan]

1.0 is out now :)

[wadesdead]

504

[apt-exploit]

Hi, Adam

I would like to know if there is the possibility of changing the name of all the tags with some plug-in in such a way that they are not the generic ones, this to protect the site when copying components, I would also like to know of some other plug-in to eliminate the unused CSS. My project is created with Gatsby and React is a job for a chain of golf companies.