Skip to content
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

Tailwind CSS v1.0 To-Dos #692

Open
adamwathan opened this Issue Feb 27, 2019 · 17 comments

Comments

Projects
None yet
8 participants
@adamwathan
Copy link
Member

adamwathan commented Feb 27, 2019

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

  • Re-evaluate flex-grow/flex-no-grow, etc.
  • Re-assess using postcss-selector-parser for escaping
  • Update plugins to source their config from theme/variants
  • 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
  • Add new shadows
  • Rename config function to theme?
  • Fix letterSpacing classes not being escaped
  • Add 56 as a width?
  • Add extended widths (48, 56, 64) to entire spacing scale?
  • Make flex-* customizable
  • Remove .clearfix? Nah still useful enough to not make people add it themselves.
  • Add new maxWidth scale
  • Revisit which variants to enable by default for split up text style plugins
  • Make preflight more hardcore, reset headings, etc.
  • 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.
  • Inherit font-related properties on form controls by default (line-height, font-family, color, maybe others, see sanitize.css for ideas)
  • Use line-height: 1.5 on body or html by default (why not? I never want 1.15 and we set that 🤷‍♂️)
  • Use system font stack by default instead of "sans-serif", I literally never want that either
  • Use fontFamily.mono for pre/code if possible, fall back to monospaced (beware double monospace thing)
  • Add text-6xl? 64px?
  • Add new default color palette
  • Bump sm breakpoint up to 640px?
  • Inherit color and text-decoration on links
  • 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
  • Consider making break-normal handle both properties to provide a nicer experience
  • Get rid of pin utilities in favor of top/right/bottom/left/inset? Unsure if worth break.
  • Consider if container should become a true core plugin instead of an included third-party plugin
  • Split whitespace plugin into whitespace and wordBreak/wordWrap?
  • Rework CLI for new config structure
  • 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
  • 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
  • Maybe pass theme function to config callbacks?

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)

  • Consider trying to make form elements more consistent by default across browsers? BuzzFeed Solid framework pretty good reference for super vanilla looking forms.

Next (straightforward)

  • Fix theme('negativeMargin.5') sort of stuff, maybe by negating all values in the default config in the callback
  • Make sure shadow-inset doesn't suck
  • Update the docs
  • Write upgrade guide
  • Write function/tool to upgrade 0.x config files

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?

@adamwathan adamwathan pinned this issue Feb 27, 2019

@o-t-w

This comment has been minimized.

Copy link

o-t-w commented Mar 6, 2019

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

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 6, 2019

March 20th or 21st 👍

@hacknug

This comment has been minimized.

Copy link
Contributor

hacknug commented Mar 6, 2019

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

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 6, 2019

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

@chessydk

This comment has been minimized.

Copy link

chessydk commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 7, 2019

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

This comment has been minimized.

Copy link

chessydk commented Mar 8, 2019

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

@tlgreg

This comment has been minimized.

Copy link

tlgreg commented Mar 8, 2019

@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

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 8, 2019

@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

This comment has been minimized.

Copy link

florianbouvot commented Mar 13, 2019

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

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 13, 2019

@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

This comment has been minimized.

Copy link

florianbouvot commented Mar 13, 2019

@adamwathan I understand, thank you for your feedback

@dbilovd

This comment has been minimized.

Copy link

dbilovd commented Mar 14, 2019

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

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 14, 2019

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

This comment has been minimized.

Copy link

trivago-vgarcia commented Mar 14, 2019

@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

This comment has been minimized.

Copy link

o-t-w commented Mar 20, 2019

Is it out yet? 😄

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.