v0.xからv1.0へのアップグレード

既存のTailwindCSSプロジェクトをv1.0にアップグレードするためのガイド。


Tailwind v1.0は主に、今日の機能セットのあり方を事前に知っていれば、私が別の方法で行っていたであろう0.xからの変更に焦点を合わせています。

したがって、エキサイティングな新機能はそれほど多くありませんが、少なくとも、基盤を構築するための非常に安定した基盤があるという事実に興奮することができます。 0.xラベルで一時停止した場合は、本番環境でTailwindを快適に使用できます。

すべてのユーザーのアップグレード手順

これらの変更は、PostCSSでTailwindを使用しているか、独自のカスタム構成ファイルを使用しているか、 または、デフォルトの構成ファイルまたはCDNを使用するだけかに関係なく、すべてのユーザーに影響します。

  1. Update Tailwind
  2. Update your config file
  3. Rename tailwind.js to tailwind.config.js
  4. Replace @tailwind preflight with @tailwind base
  5. Replace config() with theme()
  6. Explicitly style any headings
  7. Explicitly style any lists that should have bullets/numbers
  8. Remove any usage of .list-reset
  9. Replace .pin-{side} with .{top|left|bottom|right|inset}-{value}
  10. Replace .roman with .not-italic
  11. Replace .flex-no-grow/shrink with .flex-grow/shrink-0
  12. Explicitly add color and underline styles to links
  13. Add inline to any replaced elements (img, video, etc.) that should not be display: block
  14. Adjust the line-height and padding on your form elements
  15. Adjust the text color on your form elements
  16. Double check your default font family
  17. Double check your default line-height

1. Update Tailwind

Tailwindの最新バージョンをインストールします。

npm install tailwindcss@^1.0 --save-dev

またはYarnを使用する。

yarn add -D tailwindcss@^1.0

2. Update your config file

Impact: All users, Effort: Moderate

これは本当にv1.0での大きな変更です。最初のプルリクエスト内で新しい設定ファイル形式とその背後にある動機についてすべて読むことができます

新しい一般的な構成構造は次のようになります。

module.exports = {
  prefix: '',
  important: false,
  separator: ':',
  theme: {
    colors: { ... },
    // ...
    zIndex: { ... },
  },
  variants: {
    appearance: ['responsive'],
    // ...
    zIndex: ['responsive'],
  },
  plugins: [
    // ...
  ],
}

完全な例については、新しいデフォルトの設定ファイルを参照してください。

ここには多くの変更がありますが、それらはすべてかなり見栄えがよく、この1つのファイルに完全にローカライズされています。恐ろしいように見えるかもしれませんが、実際には10〜15分の作業です。

2.1. Move all design-related top-level keys into a new section called theme

options,modules,pluginsを除くすべてのキーは、新しいthemeキーの下にネストする必要があります。

この時点で、構成ファイルは一般的に次のようになります。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
-   colors: colors,
-   screens: {
-     // ...
-   },
-   // ...
-   zIndex: {
-     // ...
-   },
+   theme: {
+     colors: colors,
+     screens: {
+       // ...
+     },
+     // ...
+     zIndex: {
+       // ...
+     },
+   },
    modules: {
      appearance: ['responsive'],
      // ...
      zIndex: ['responsive'],
    },
    plugins: [
      require('tailwindcss/plugins/container')({
        // ...
      }),
    ],
    options: {
      prefix: '',
      important: false,
      separator: ':',
    }
  }

2.2. Rename modules to variants

"Modules"は、適当な例としての言葉でした。構成のそのセクションを使用して、バリアントを指定し、必要に応じてmodulesを無効にしました。

Tailwindの内部"modules"はすべて実際には単なるコアプラグインであるため、この用語を完全に非推奨にし、構成のこのセクションを純粋にコアプラグインのバリアントの構成に関するものにすることにしました。

この変更を行うと、構成ファイルは次のようになります。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
    theme: {
      // ...
    },
-   modules: {
+   variants: {
      appearance: ['responsive'],
      backgroundAttachment: ['responsive'],
      backgroundColors: ['responsive', 'hover', 'focus'],
      // ...
      zIndex: ['responsive'],
    },
    plugins: [
      require('tailwindcss/plugins/container')({
        // ...
      }),
    ],
    options: {
      prefix: '',
      important: false,
      separator: ':',
    }
  }

2.3. Move your options settings to the top-level

詳細オプションは、冗長なoptionsキーの下にネストされるのではなく、構成ファイルの最上位に移動されました。

この変更を行うと、構成ファイルは次のようになります。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
+   prefix: '',
+   important: false,
+   separator: ':',
    theme: {
      // ...
    },
    variants: {
      appearance: ['responsive'],
      backgroundAttachment: ['responsive'],
      backgroundColors: ['responsive', 'hover', 'focus'],
      // ...
      zIndex: ['responsive'],
    },
    plugins: [
      require('tailwindcss/plugins/container')({
        // ...
      }),
    ],
-   options: {
-     prefix: '',
-     important: false,
-     separator: ':',
-   }
  }

2.4. Move your negativeMargin config to margin

負のマージンは、正のマージンを処理するのと同じコアプラグインによって処理されるようになりました。

negativeMarginで設定した値を取得し、それらをmarginに移動します。必ずキーに先頭のダッシュを追加し、実際の値を負にします。

  margin: {
    'auto': 'auto',
    'px': '1px',
    '0': '0',
    '1': '0.25rem',
    '2': '0.5rem',
    '3': '0.75rem',
    '4': '1rem',
    '5': '1.25rem',
    '6': '1.5rem',
    '8': '2rem',
    '10': '2.5rem',
    '12': '3rem',
    '16': '4rem',
    '20': '5rem',
    '24': '6rem',
    '32': '8rem',
+   '-px': '-1px',
+   '-1': '-0.25rem',
+   '-2': '-0.5rem',
+   '-3': '-0.75rem',
+   '-4': '-1rem',
+   '-5': '-1.25rem',
+   '-6': '-1.5rem',
+   '-8': '-2rem',
+   '-10': '-2.5rem',
+   '-12': '-3rem',
+   '-16': '-4rem',
+   '-20': '-5rem',
+   '-24': '-6rem',
+   '-32': '-8rem',
  },
- negativeMargin: {
-   'px': '1px',
-   '0': '0',
-   '1': '0.25rem',
-   '2': '0.5rem',
-   '3': '0.75rem',
-   '4': '1rem',
-   '5': '1.25rem',
-   '6': '1.5rem',
-   '8': '2rem',
-   '10': '2.5rem',
-   '12': '3rem',
-   '16': '4rem',
-   '20': '5rem',
-   '24': '6rem',
-   '32': '8rem',
- },

クラス名自体は変更されていないことに注意してください。-6のようなキーはmx--6のようなクラスを生成すると予想されるかもしれませんが、marginプラグインはそれらのキーを検出して、あなたはがかつて好きだったクラス名-mx-6を作成するのに十分賢いです。

2.5. Update the sections under theme to their new names

設定ファイルの名前の一貫性を高めるための取り組みの一環として、theme下のセクションの多くの名前が変更されました。 これらの名前はvariantsセクションでも変更する必要があるため、ファイル全体で自由に検索して置換してください。

更新が必要なセクションは次のとおりです。

OldNew
fontsfontFamily
textSizesfontSize
fontWeightsfontWeight
leadinglineHeight
trackingletterSpacing
textColorstextColor
backgroundColorsbackgroundColor
borderWidthsborderWidth
borderColorsborderColor
shadowsboxShadow
svgFillfill
svgStrokestroke

2.6. Update the sections under variants to their new names

前のステップでほのめかしたように、variants下のセクションの多くも名前が変更されています。

これらは名前を変更する必要があるセクションです。(上記のリストと同じです)

OldNew
fontsfontFamily
textSizesfontSize
fontWeightsfontWeight
leadinglineHeight
trackingletterSpacing
textColorstextColor
backgroundColorsbackgroundColor
borderWidthsborderWidth
borderColorsborderColor
shadowsboxShadow
svgFillfill
svgStrokestroke

variantsの下のいくつかのセクションも複数のセクションに分割されています。たとえば、listslistStylePositionと listStyleType`に分割されています。

  // ...

  module.exports = {
    // ...
    variants: {
      // ...
-     lists: ['responsive'],
+     listStylePosition: ['responsive'],
+     listStyleType: ['responsive'],
    }
  }

複数のセクションに分割されたセクションの完全なリストは次のとおりです。

OldNew
flexboxflexDirection
flexWrap
alignItems
alignSelf
justifyContent
alignContent
flex
flexGrow
flexShrink
listslistStylePosition
listStyleType
positionposition
inset
textStylefontStyle
fontSmoothing
textDecoration
textTransform
whitespacewhitespace
wordBreak

元のセクションがまだ存在する場合(position,whitespace)もあれば、元のセクションが完全に削除されている場合(flexbox,textStyle)もあることに注意してください。

正しい変更を行っているかどうかわからない場合、新しいデフォルトの設定ファイルを参照する必要があります

これらの変更を行う最も簡単な方法は、古いセクションに使用していた値(['responsive']など)を、そのセクションを置き換えるすべての新しいセクションにコピーすることです。 ただし、あなたが選択した場合は、これを実際には必要のない生成されたユーティリティを選び取る機会として使用することもできます。

たとえば、antialiasedまたはsubpixel-antialiasedのレスポンシブバリアントを使用したことがない場合は、['responsive']textDecoration,fontStyleおよびtextTransformに使用しながらfontSmoothingを[]に設定できます。

2.7. Add any disabled modules core plugins to corePlugins

v0.xでは、現在のvariantsセクションでfalseに設定することで、~~ module ~~コアプラグインを無効にできます。

v1.0では、プラグインを無効にするには、代わりにcorePluginsセクションでプラグインをfalseに設定する必要があります。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      // ...
    },
    variants: {
      // ...
-     float: false,
      // ...
    },
+   corePlugins: {
+     float: false,
+   },
    plugins: [
      require('tailwindcss/plugins/container')({
        // ...
      }),
    ],
  }

この変更は、preflight containerのように、variantsが無関係な他のコアプラグインを無効にできるようにするために行われました。(これについては後で詳しく説明します)

2.8. Remove the container plugin from plugins and move any configuration to theme

v1.0では、containerプラグインはpaddingmarginなどと同じコアプラグインであり、pluginsセクションにリストされるべきではありません。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      // ...
    },
    variants: {
      // ...
    },
    plugins: [
-     require('tailwindcss/plugins/container')({
-       center: true,
-       padding: '1rem',
-     }),
    ],
  }

プロジェクトにこれらのクラスを含めたくないためにコンテナプラグインをすでに削除している場合は、corePluginsオプションを使用して明示的に無効にしてください。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      // ...
    },
    variants: {
      // ...
    },
+   corePlugins: {
+     container: false
+   },
  }

containerプラグインによって公開されるcenterまたはpaddingオプションを利用している場合は、プラグインへの直接の引数としてではなく、theme.container下でそれらのオプションを指定する必要があります。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  let colors = {
    // ...
  }

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      // ...
+     container: {
+       center: true,
+       padding: '1rem',
+     }
    },
    variants: {
      // ...
    },
    plugins: [
-     require('tailwindcss/plugins/container')({
-       center: true,
-       padding: '1rem',
-     }),
    ],
  }

2.9. Inline your colors variable into theme.colors

v1.0では、テーマの一部をテーマの他の部分に依存するように指定できます。そのため、colorsを別の変数に保持する必要がなくなりました。

colors変数をtheme.colorsに直接インライン化することから始めます。

  let defaultConfig = require('tailwindcss/defaultConfig')()

- let colors = {
-   'transparent': 'transparent',
-   'black': '#22292f',
-   // ...
-   'pink-lightest': '#ffebef','
- }

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
-     colors: colors,
+     colors: {
+       'transparent': 'transparent',
+       'black': '#22292f',
+       // ...
+       'pink-lightest': '#ffebef','
+     },
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

次に、新しいクロージャ構文を使用して、colors変数を参照していたセクションを更新します。

  let defaultConfig = require('tailwindcss/defaultConfig')()

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      colors: {
        'transparent': 'transparent',
        'black': '#22292f',
        // ...
        'pink-lightest': '#ffebef','
      },
      // ...
-     backgroundColor: colors,
+     backgroundColor: theme => theme('colors'),
      // ...
-     textColor: colors,
+     textColor: theme => theme('colors'),
      // ...
-     borderColor: global.Object.assign({ default: colors['grey-light'] }, colors),
+     borderColor: theme => ({
+       default: theme('colors.grey-light'),
+       ...theme('colors'),
+     }),
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

2.10. Don't invoke the default config as a function

v0.xでは、require('tailwindcss/defaultConfig')は、呼び出されたときにデフォルトの構成を返す関数を返しました。

v1.0では、単にオブジェクトを返します。

- let defaultConfig = require('tailwindcss/defaultConfig')()
+ let defaultConfig = require('tailwindcss/defaultConfig')

  module.exports = {
    prefix: '',
    important: false,
    separator: ':',
    theme: {
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

2.11. Remove any configuration you haven't customized

v1.0での哲学的な変更の1つは、デフォルトの構成全体に変更を含めるのではなく、デフォルトの構成から変更点を指定するためだけに構成ファイルを使用することを推奨していることです。

構成ファイル内のすべてのキーはオプションです。(実際にはファイル自体もオプションです) したがって、カスタマイズしたことがないものがある場合は、それらを完全に削除することをお勧めします。

たとえば、カスタムセパレータまたはプレフィックスを指定していない場合、またはimportantオプションを有効にしていない場合は、それらを完全に削除できます。

  let defaultConfig = require('tailwindcss/defaultConfig')

  module.exports = {
-   prefix: '',
-   important: false,
-   separator: ':',
    theme: {
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

同様に、どこにもdefaultConfig変数を参照していない場合は、それも削除します。

- let defaultConfig = require('tailwindcss/defaultConfig')

  module.exports = {
    theme: {
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

不透明度の値をカスタマイズしていない場合は、次の値を削除します。

  module.exports = {
    theme: {
      // ...
-     opacity: {
-       '0': '0',
-       '25': '.25',
-       '50': '.5',
-       '75': '.75',
-       '100': '1',
-     },
      // ...
    },
    variants: {
      // ...
    },
    plugins: [],
  }

メジャーバージョンバンプ以外ではこの構成を変更しないため、デフォルト値の継承に依存しても完全に安全です。

構成をデフォルトとマージする方法は、非常に直感的でほとんど機能するように設計されていますが、好奇心旺盛な人はこちらを参照ください。

  • prefixは置き換えられます。
  • separatorは置き換えられます。
  • importantは置き換えられます。
  • themeは1レベル深くマージされるため、theme.opacityにオブジェクトを指定すると、デフォルトのtheme.opacityオブジェクトが置き換えられます。
  • variantsは1レベル深くマージされるため、Variants.opacityの配列を指定すると、デフォルトのvariants.opacityオブジェクトが置き換えられます。
  • pluginsはマージされますが、デフォルトは空の配列であるため、実際には置換と同じです。

冗長な構成を削除する必要はないことに注意してください。したがって、システム全体を所有し、すべてを1か所で確認できるようにしたい場合は、すべてを構成ファイルに保存しておくことをお勧めします。

テーマの値の多くがv0.7.4からv1.0に変更されたことを認識することが非常に重要です。したがって、v0.xでデフォルトで出荷された値をカスタマイズしたことがないという理由だけで、構成ファイルからその値を安全に削除できるとは限りません。

これの完璧な例は色です。デフォルトのカラーパレットはv1.0で完全に新しく、新しい命名スキームが採用されているため、v0.xでデフォルトのカラーパレットを使用していた場合でも、実際にはv1.0でカスタムカラーパレットを使用しています。

削除する前に、削除するものが新しいデフォルトの構成ファイルの値と同じであることを常に再確認してください。

3. Rename tailwind.js to tailwind.config.js

Impact: N/A, Effort: Trivial

これは完全にオプションですが、古いデフォルトの設定ファイル名(tailwind.js)を使用している場合は、名前をtailwind.config.jsに変更することをオススメします。

そのファイル名を使用し、ファイルをプロジェクトのルートに保持する場合、Tailwindは、ビルドスクリプト/コンフィギュレーションでパスを指定しなくても、デフォルトで構成ファイルを取得します。

LaravelMixを使用する例を次に示します。

  mix.postCss('resources/css/app.css', 'public/css/app.css', [
-   require('tailwindcss')('./tailwind.js'),
+   require('tailwindcss'),
  ])

コンフィグファイルを別のフォルダーに保存する場合でも、パスを指定する必要があります。

  mix.postCss('resources/css/app.css', 'public/css/app.css', [
-   require('tailwindcss')('./resources/tailwind.js'),
+   require('tailwindcss')('./resources/tailwind.config.js'),
  ])

4. Replace @tailwind preflight with @tailwind base

Impact: All users, Effort: Trivial

v1.0の新機能の1つは、プラグインが基本スタイルを登録する機能です。 その結果、私たちのpreflightスタイルは実際には単なる別のコアプラグインになり、ベーススタイルの一般的なbucketpreflightからbaseに名前が変更されました。

CSSファイル内の@tailwind preflightのインスタンスを@tailwind baseに置き換えます。

- @tailwind preflight;
+ @tailwind base;

  @tailwind components;

  @tailwind utilities;

postcss-importを使用していて、@tailwindディレクティブの代わりにインポートに依存している場合は、@import"tailwindcss/preflight"@import"tailwindcss/base"に置き換えます。

- @import "tailwindcss/preflight";
+ @import "tailwindcss/base";

  @import "tailwindcss/components";

  @import "tailwindcss/utilities";

5. Replace config() with theme()

Impact: Moderate, Effort: Low

TailwindがCSSファイルで利用できるようにするconfig()ヘルパー関数は、構成ファイルのthemeセクションに自動的にスコープされ、ドロップインリプレースメントとして機能する新しいtheme()関数に置き換えられました。

  .btn {
-   padding: config('padding.3');
+   padding: theme('padding.3');
    // ...
  }

config(theme(に切り替えるCSSファイル全体の簡単な検索と置換がそれを行うはずです。

6. Explicitly style any headings

Impact: Moderate, Effort: Moderate

preflightスタイルを使用している場合、v1.0ではすべてのh1-h6要素のスタイルがデフォルトで解除されます。

つまり、初期状態で、それらはすべて1emのフォントサイズ(親フォントサイズが何であれ)とinheritのフォントウェイトを持っていることを意味します。したがって、それらはpタグとまったく同じように見えます。

We do this because in web application development it's very common for some piece of text to be a heading semantically, but actually be styled in a much less "in your face" way because it's meant to look more like a subtle label on a section of UI.

これを行うのは、Webアプリケーション開発では、テキストの一部が意味的に見出しになることが非常に一般的だからです。 しかし実際には、はるかに少ない「面と向かった」方法でスタイリングされます。なぜならUIのセクションの微妙なラベルのように見えることを意図しているためです。

このため、適切に設計されたアプリケーションでは、とにかく見出しのユーザーエージェントスタイルを「元に戻す」必要があります。 Tailwindでは、減算ではなく加算を感じる方がスタイリングに適していると考えています。

見出しにユーザーエージェントスタイルを使用することで、独自のデザインシステムから誤って逸脱することも簡単になりました。 ブラウザがh12emにする必要があると言った場合、fontSizeスケールの一部ではないサイズに計算される可能性があります。

デフォルトで見出しのスタイルを解除することで、設定するサイズや重みが明示的かつ意図的になるようにすることで、この落とし穴をはるかに簡単に回避できます。

すべての見出しにフォントの太さとフォントサイズをすでに指定している場合、この変更はまったく影響しない可能性がありますが、指定していない場合は、欠落している場所に明示的なサイズと太さを割り当てる必要があります。

- <h1>Manage Account<h1>
+ <h1 class="text-xl font-semibold">Manage Account<h1>

行う必要のある正確な変更は、設計で達成したいことに非常に固有であるため、それぞれの状況を個別に評価する必要があります。

これは少し厄介な変更ですが、サイトが破損した場合は、マークアップのバグが実際に明らかになっていると主張することができます。

7. Explicitly style any lists that should have bullets/numbers

Impact: Moderate, Effort: Moderate

preflightスタイルを使用している場合、v1.0ではすべてのul要素とol要素のスタイルがデフォルトで解除されます。

つまり、デフォルトのブラウザスタイル(箇条書き/数字と少し左のパディング)に依存するリストがある場合は、新しい.list-disc/decimalユーティリティと既存のパディングユーティリティを使用してそれらのリストを明示的にスタイル設定する必要があります。

- <ul>
+ <ul class="list-disc pl-4">
    <!-- ... -->
  </ul>

これを手動で行う必要がなく、リストのスタイルをデフォルトで設定したい場合は、次のようなルールをいくつか追加して、基本スタイルを独自のカスタムCSSでオーバーライドできます。

@tailwind base;

ul {
  list-style-type: disc;
  padding-left: theme('padding.4');
}

ol {
  list-style-type: decimal;
  padding-left: theme('padding.4');
}

@tailwind components;

@tailwind utilities;

8. Remove any usage of .list-reset

Impact: Moderate, Effort: Low

リストはデフォルトでスタイルが解除されているため、.list-resetは削除されました。技術的には何も変更する必要はありませんが、デッドコードになっているため、削除することをお勧めします。

- <ul class="list-reset"><!-- ... --></ul>
+ <ul><!-- ... --></ul>

基本スタイルを上書きしてリストにデフォルトスタイルを与えることを選択した場合は、新しい.list-noneユーティリティと.p-0.list-resetの代わりに使用して、必要に応じてその基本スタイルを削除できます。

- <ul class="list-reset"><!-- ... --></ul>
+ <ul class="list-none p-0"><!-- ... --></ul>

繰り返しになりますが、変更されていないpreflightスタイルを使用している場合(おそらくそうです)、マークアップからlist-resetを削除するだけで、何も変更されません

この変更は、preflightスタイルを使用していない場合、またはグローバルリストのリセットをオーバーライドしている場合にのみ実際に影響します。

9. Replace .pin-{side} with .{top|left|bottom|right|inset}-{value}

Impact: High, Effort: Moderate

.pin,.pin-x,.pin-tなどのユーティリティは削除され、.top-0,.right-0などのより利口な名前のクラスが採用されました。

この変更の背後にある動機の詳細については、プルリクエストを参照してください。

変更点の完全なリストは次のとおりです。

OldNew
.pin-none.inset-auto
.pin.inset-0
.pin-y.inset-y-0
.pin-x.inset-x-0
.pin-t.top-0
.pin-r.right-0
.pin-b.bottom-0
.pin-l.left-0

6つの新しいクラスも追加されました。

Class
.inset-y-auto
.inset-x-auto
.top-auto
.right-auto
.bottom-auto
.left-auto

これらはすべてtheme.insetでもカスタマイズできるようになりましたが、pin-{side}ユーティリティはカスタマイズできませんでした。

これは迷惑な変更です、ごめんなさい。

10. Replace .roman with .not-italic

Impact: Low, Effort: Low

以前は、postcss-selector-notにバグがあり、.not-italicを使用できなかったため、font-style:normal.romanという名前を使用していました。そのバグは修正されたので、この名前は変更されました。

- <div class="roman">
+ <div class="not-italic">
    <!-- ... -->
  </div>

5人以上がこの影響を受けているとしたら驚きます。私は一度もこのクラスを使ったことがありません。

11. Replace .flex-no-grow/shrink with .flex-grow/shrink-0

Impact: High, Effort: Low

これらのユーティリティをより簡単にカスタマイズできるようにするために、既存の規則に一致するように名前が変更されました。

- <div class="flex-no-grow">
+ <div class="flex-grow-0">
    <!-- ... -->
  </div>

- <div class="flex-no-shrink">
+ <div class="flex-shrink-0">
    <!-- ... -->
  </div>

これらのユーティリティは、設定ファイルのtheme.flexGrowセクションとtheme.flexShrinkセクションでもカスタマイズできるようになりました。

Impact: High, Effort: Moderate

v1.0では、aタグは親のcolorスタイルとtext-decorationスタイルを自動的に継承します。つまり、デフォルトでは、リンクは青色ではなく、下線もありません。

デフォルトのブラウザの青色が必要なかったため、text-green-darkなどのテキストカラークラスをリンクに追加している可能性がありますが、そうでない場合は、明示的に色を追加する必要があります。

- <a href="#">
+ <a href="#" class="text-blue">
    <!-- ... -->
  </a

同様に、アンダースコアが必要なリンクがある場合は、手動で追加する必要があります。

- <a href="#">
+ <a href="#" class="underline">
    <!-- ... -->
  </a

反対に、リンクのスタイルを解除するためだけにプロジェクト全体の100万の場所でno-underlineクラスを使用している場合は、そのクラスを安全に削除できるようになりました。

- <a href="#" class="no-underline">
+ <a href="#">
    <!-- ... -->
  </a

これらの新しいデフォルトが本当に気に入らない場合は、@tailwind baseの後に独自のベースリンクスタイルを追加できます。

@tailwind base;

a {
  color: theme('colors.blue');
  text-decoration: underline;
}

@tailwind components;
@tailwind utilities;

13. Add inline to any replaced elements (img, video, etc.) that should not be display: block

Impact: Moderate, Effort: Moderate

v1.0では、置き換えられたすべての要素(img, svg, video, canvas, iframe, etc.)は、デフォルトでdisplay:blockに設定されています。 これは、ブラウザのデフォルトであるinline`とは逆です。

これらの要素を実際にinlineにしたいインスタンスがプロジェクトにある場合は、そのクラスを追加する必要があります。

  <span>
-   <img src="..." class="h-4 w-4">
+   <img src="..." class="h-4 w-4 inline">
    Manage
  </span>

ほとんどの場合、これらの要素をblockにするか、問題のないフレックスコンテナ内にネストするため、これが実際に多くの人やプロジェクトに影響を与えるとは思いません。

14. Adjust the line-height and padding on your form elements

Impact: High, Effort: Moderate

フォーム要素に明示的な行の高さをすでに設定している場合、この変更は影響しません。

v0.xでは、デフォルトでフォーム要素に1.15の行の高さを使用しましたが、これは、normalize.cssに応じて偶然に発生します。

これにより、要素を形成するためにleading-tightleading-normalなどの明示的な行の高さを追加するのを忘れがちになり、プロジェクトに新しい行の高さ(1.15)が導入されました。これはleading-{size}ユーティリティとはマッチしません。

v1.0では、すべてのフォーム要素が行の高さに inheritの値を使用するため、行の高さはデフォルトで親要素と一致します。

つまり、次のようなマークアップがあった場合:

<div class="leading-normal ...">
  <!-- ... -->
  <input type="text" class="px-4 py-3">
</div>

...行の高さが1.15から1.5に増加したため、v1.0ではinput要素の高さがわずかに高くなります。

これを修正するには、新しい行の高さを考慮して垂直方向のパディングを調整し、親の行の高さと一致させたくない場合は、オプションで明示的な leading- {size}クラスを追加します。

  <div class="leading-normal ...">
    <!-- ... -->
-   <input type="text" class="px-4 py-3">
+   <input type="text" class="px-4 py-2 leading-tight">
  </div>

以前とまったく同じ高さにはならないかもしれませんが、それはおそらく、古い高さが42.4px(行の高さ1.15 *フォントサイズ16px +パディング24px)のような奇妙な小数であったためです。 新しいシステムでは、選択した行の高さとパディングの値に応じて、44pxの40pxなどの妥当な整数に到達する可能性がはるかに高くなります。

フォーム要素のデフォルトの行の高さとして1.15を本当に使用したい場合は(これはお勧めしません)、次のようなルールを独自の基本スタイルに追加できます。

@tailwind base;

button,
input,
optgroup,
select,
textarea {
  line-height: 1.15;
}

@tailwind components;
@tailwind utilities;

15. Adjust the text color on your form elements

Impact: Low, Effort: Moderate

フォーム要素に明示的なテキストの色をすでに設定している場合、この変更は影響しません。

v0.xでは、黒がデフォルトのカラーパレットの一部ではなかったとしても、フォーム要素はデフォルトで黒のテキストを使用していました。

v1.0では、フォーム要素は親からテキストの色を継承します。つまり、次のようなマークアップがある場合です。

<div class="text-red">
  <input type="text">
</div>

...inputには、黒いテキストではなく赤いテキストが含まれます。

フォーム要素にテキストの色を明示的に設定することで、これを修正できます。

  <div class="text-red">
-   <input type="text">
+   <input type="text" class="text-grey-darkest">
  </div>

16. Double check your default font family

Impact: Low, Effort: Trivial

プロジェクトにデフォルトのフォントファミリーを既に設定している場合( html/bodyのクラスを使用するか、カスタムCSSを使用する)、この変更による影響はありません。

v1.0では、デフォルトのフォントファミリが sans-serifからシステムフォントスタックに変更されました。

自分のフォントでこれをオーバーライドしていない可能性はほとんどありませんが、そうでない場合は、サイトの外観が少し異なり、正直なところおそらくより良いことに気付くでしょう。

何らかの理由でデフォルトのフォントファミリとして sans-serifを使用したい場合を除いて、実際には何も変更する必要はありません。その場合、基本スタイルにルールを追加できます。

@tailwind base;

html {
  font-family: sans-serif;
}

@tailwind components;
@tailwind utilities;

17. Double check your default line-height

Impact: Moderate, Effort: Moderate

プロジェクトにデフォルトの行の高さをすでに設定している場合(html/bodyのクラスを使用するか、カスタムCSSを使用する)、この変更は影響しません。

v0.xでは、デフォルトの行の高さは1.15(normalize.cssから継承)でした。 その値はTailwindのデフォルトのテーマの一部ではないため、v1.0では1.5に変更して、デフォルトの行の高さが行の高さのスケールの値と一致するようにしました。

これは、htmlまたはbodyタグでleading-{size}クラスを使用するか、CSSにいくつかの基本スタイルを追加することによって行の高さを設定しない場合、サイトのほとんどのものが少し背が高く見えます。

最も簡単な解決策は、行の高さをデフォルトで1.15にリセットすることです。

@tailwind base;

html {
  line-height: 1.15;
}

@tailwind components;
@tailwind utilities;

ただし、より良い長期的な解決策は、行の高さのスケールの値に一致するデフォルトの行の高さを選択し、サイトを監査して、デザインの見栄えが悪くなる状況を見つけ、一度に1つずつ微調整することです。


CDNユーザー、または構成ファイルのない他のユーザー向けの追加手順

これらの手順は、0.x構成ファイルの値に依存しているユーザーにのみ影響します。 これには、CDNユーザー、または構成ファイルからセクションを省略している、構成ファイルを参照している、または構成ファイルをまったく使用していないユーザーが含まれます。

  1. text/bg/border-{color}クラスの使用法を更新する
  2. tracking-tight/widetracking-tighter/widerに置き換える
  3. 更新されたデフォルトのブレークポイントに対してデザインを確認する
  4. デフォルトのshadow-{size}ユーティリティの使用法を再確認する
  5. デフォルトのmax-w-{size}ユーティリティの使用法を更新する

1. text/bg/border-{color}クラスの使用法を更新する

Impact: Low, Effort: High

この変更は、構成ファイルにカラーパレットが定義されていない場合、またはCDNを介してTailwindを使用している場合にのみ影響します。

Tailwind v1.0には、7色ではなく9色の色合いを提供するまったく新しいカラーパレットが付属しています。 (#737).

命名スキームは、darkestlighterなどの単語の使用から、最も明るい色合いの100で始まり、最も暗い色合いの900で終わるマテリアルデザインに触発された数値スケールに変更されました。

新しいパレットにはより多くの色合いが含まれているため、古い色を新しい色に1:1でマッピングする方法はありません。 したがって、v0.xのデフォルトのカラーパレットを使用していて、新しいカラーパレットにアップグレードしたい場合は、あなたはそれを楽しむでしょう(実際にはあなたはそうではありませんが)。

次の置換から始めて、必要に応じてケースバイケースで色合いを上下に調整することをお勧めします。

灰色の場合(greygrayに変更されていることに注意してください)

OldNew
blackgray-900
grey-darkestgray-800
grey-darkergray-700
grey-darkgray-600
greygray-500
grey-lightgray-400
grey-lightergray-200
grey-lightestgray-100
whitewhite

他の色の場合:

OldNew
{color}-darkest{color}-900
{color}-darker{color}-800
{color}-dark{color}-600
{color}{color}-500
{color}-light{color}-400
{color}-lighter{color}-200
{color}-lightest{color}-100

繰り返しますが、この変更は、構成ファイルで独自のカラーパレットが指定されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合にのみ影響します。 プロジェクトでv0.xカラーパレットを使用している場合は、使用し続けることができます。 何らかの方法でデフォルトのカラーパレットに強く依存していない限り、これらの変更を行う必要はありません。

2. tracking-tight/widetracking-tighter/widerで置き換える

Impact: Low, Effort: Low

この変更は、構成ファイルでトラッキング、文字間隔のスケールが定義されていない場合、またはCDNを介してTailwindを使用している場合にのみ影響します。

v1.0では、デフォルトの文字間隔スケールが変更されました。

 letterSpacing: {
+  tighter: -.05em,
-  tight: -.05em,
+  tight: -.025em,
   normal: 0,
-  wide: .05em,
+  wide: .025em,
+  wider: .05em,
+  widest: .1em,
 }

つまり、プロジェクトを同じように見せたい場合は、既存のtracking-tighttracking-tighterに、tracking-widetracking-widerに置き換える必要があります。

繰り返しになりますが、これは、構成ファイルで文字間隔スケールが定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合にのみ適用されます。

完全な構成ファイルから始めた場合、古いスケールはv1.0でも同じように機能し続けるため、変更を加える必要はありません。

3. 更新されたデフォルトのブレークポイントに対してデザインを確認する

Impact: Low, Effort: Low

この変更は、構成ファイルに画面が定義されていない場合、またはCDNを介してTailwindを使用している場合にのみ影響します。

v1.0では、デフォルトのブレークポイントが少し変更されています。

ScreenOldNew
sm576px640px
md768px768px (unchanged)
lg992px1024px
xl1200px1280px

構成ファイルに画面が定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合は、デザインを監査し、これらの変更によって何も壊れていないことを確認する必要があります。 ブレークポイントが小さくなることはないため、問題が発生する可能性はほとんどありませんが、どちらの方法でも確認する価値があります。

繰り返しますが、これは、構成ファイルに画面が定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合にのみ適用されます。

完全な構成ファイルから始めた場合、古い画面の値はv1.0でも同じように機能し続けるため、変更を加える必要はありません。

4. shadow-{size} ユーティリティの使用法を再確認する

Impact: Low, Effort: Low

この変更は、構成ファイルにボックスシャドウスケールが定義されていない場合、またはCDNを介してTailwindを使用している場合にのみ影響します。

Tailwind v1.0では、2つの新しいボックスシャドウサイズ(xl2xl)が導入され、残りのシャドウも調整されています。(#691).

構成ファイルにボックスシャドウスケールが定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合は、シャドウの外観に満足していることを再確認する必要があります。 新しいlgシャドウは古いシャドウよりも少しタイトなので、lgの一部のインスタンスをxlまたは2xlに置き換えることをお勧めします。

繰り返しますが、これは、構成ファイルにボックスシャドウが定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合にのみ適用されます。

完全な構成ファイルから始めた場合、古いボックスシャドウ値はv1.0でも同じように機能し続けるため、変更を加える必要はありません。

5. デフォルトのmax-w-{size}ユーティリティの使用法を更新する

Impact: Low, Effort: Low

この変更は、構成ファイルで最大幅スケールが定義されていない場合、またはCDNを介してTailwindを使用している場合にのみ影響します。

Tailwind v1.0では、以前のデフォルトの最大幅スケールよりもはるかに使いやすい、まったく新しい最大幅スケールが導入されています。 (#701).

構成ファイルに最大幅スケールが定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合は、既存のmax-w-{size}ユーティリティの使用状況についてプロジェクトを監査し、必要に応じてサイズを変更してください。 一般に、新しい値は古い値よりも小さいため、たとえばmax-w-mdは新しいスケールではmax-w-xlまたはmax-w-2xlである必要があります。

繰り返しますが、これは、構成ファイルに最大幅が定義されていない場合、またはCDNを介してデフォルトのTailwindビルドを使用している場合にのみ適用されます。

完全な構成ファイルから始めた場合、古いmax-width値はv1.0でも同じように機能し続けるため、変更を加える必要はありません。


プラグイン作成者向けの追加手順

この手順は、独自のプラグインを作成したユーザーにのみ影響します。

作成したカスタムバリアントのクラス部分をエスケープします

Impact: Low, Effort: Low

v1.0では、プラグインを使用して新しいバリアントを追加するときに、作成するセレクターのクラス名部分を手動でエスケープする必要があります。

For example:

- function({ addVariant }) {
+ function({ addVariant, e }) {
    addVariant('first-child', ({ modifySelectors, separator }) => {
      modifySelectors(({ className }) => {
-       return `.first-child${separator}${className}:first-child`
+       return `.${e(`first-child${separator}${className}`)}:first-child`
      })
    })
  },

これは、ユーザー提供の文字列を含む可能性のあるユーティリティまたはコンポーネントを追加するときに行う必要があることとまったく同じです。

残念ながら、ユーザーがインストールしたTailwindのバージョンを確認し、条件付きでエスケープ機能を適用せずに、v0.xとv1.0の両方を同時にサポートする非常に簡単な方法はありません。


Translated by T.Arai @ Entap,Inc. / スマホアプリ開発会社

Tailwind UI is now in early access!