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

defaultLineHeights requires code repetition when used with responsive fontSize #2603

Closed
fedeci opened this issue Oct 17, 2020 · 1 comment · Fixed by tailwindlabs/tailwindcss.com#634

Comments

@fedeci
Copy link
Contributor

fedeci commented Oct 17, 2020

Describe the problem:

Non-responsive leading utilities don't work if used along with responsive variants of the fontSize utility and the defaultLineHeights future enabled.
This is more a problem of style and code repetition than a real bug, but it is quite annoying to deal with.

e.g.

<!-- Because sm:text-3xl and md:text-4xl have a higher priority, leading normal does not work -->
<div class="text-2xl sm:text-3xl md:text-4xl leading-normal"></div>

<!-- To make it work you have to specify responsive variants making the code repetitive -->
<div class="text-2xl sm:text-3xl md:text-4xl leading-normal sm:leading-normal md:leading-normal"></div>

A possible solution may be to mark the leading utility as !important, but it definitely should be discussed first.

Link to a minimal reproduction:

https://play.tailwindcss.com/Lw5MjdPa6J

@adamwathan
Copy link
Member

Yeah this is a deliberate trade-off I'm afraid — in our own work we basically never use the same line-height across changes in font size, we always change the line-height as well.

The best solution if you don't want the default line-height stuff is to override your fontSize configuration to use font-sizes with no built-in line-height:

module.exports = {
  theme: {
    extend: {
      fontSize: {
        xs: '0.75rem',
        sm: '0.875rem',
        base: '1rem',
        lg: '1.125rem',
        xl: '1.25rem',
        '2xl': '1.5rem',
        '3xl': '1.875rem',
        '4xl': '2.25rem',
        '5xl': '3rem',
        '6xl': '4rem',
      }
    }
  }
}

My personal opinion is that you probably don't actually want leading-normal at each size. It's definitely way too much line-height for text-3xl and text-4xl like in your example, and 1.5 almost always leads to your text being a weird height that is not part of the spacing scale.

happycollision added a commit to happycollision/tailwindcss.com that referenced this issue Nov 28, 2020
The change in behavior from 1.x to 2.x was mentioned in the docs, but this makes the information more explicit and also will bring this behavior to the attention of folks who are using tailwind for the first time.

Resolves tailwindlabs/tailwindcss#2603, resolves tailwindlabs/tailwindcss#2852, and resolves tailwindlabs/tailwindcss#2907
happycollision added a commit to happycollision/tailwindcss.com that referenced this issue Dec 31, 2020
The change in behavior from 1.x to 2.x was mentioned in the docs, but this makes the information more explicit and also will bring this behavior to the attention of folks who are using tailwind for the first time.

Resolves tailwindlabs/tailwindcss#2603, resolves tailwindlabs/tailwindcss#2852, and resolves tailwindlabs/tailwindcss#2907
adamwathan added a commit to tailwindlabs/tailwindcss.com that referenced this issue Jan 29, 2021
* Document leading and {screen}:text-{size} interactions

The change in behavior from 1.x to 2.x was mentioned in the docs, but this makes the information more explicit and also will bring this behavior to the attention of folks who are using tailwind for the first time.

Resolves tailwindlabs/tailwindcss#2603, resolves tailwindlabs/tailwindcss#2852, and resolves tailwindlabs/tailwindcss#2907

* Update font-size.mdx

* Update upgrading-to-v2.mdx

* Update line-height.mdx

Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
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 a pull request may close this issue.

2 participants