Rescale.com の再設計にタキオンを使用することについての考え

XNUMX か月ちょっと前に、ホームページの再設計されたバージョンを出荷しました。 https://rescale.com。 開発中に、CSS の記述方法を再評価する良い時期が来たと考えました。
当時、私たちのメインの CSS ファイルは 2000 行以上の長さで、古典的なセマンティッククラス名スタイルで書かれていました (たとえば、ニュースセクションは .news class) いくつかのユーティリティ クラスがあちこちにあります。
CSS コードをざっと読んだところ、この再設計に入るのに少し不安を感じました。1) 私たちが書いた CSS クラスの多くは、新しい設計ではおそらく再利用できないため、最終的にさらに多くの CSS を追加することになるでしょう。2) ) レスポンシブなコンポーネントがさらに多くなる予定であり、レスポンシブな CSS を記述する方法に従ったり、変更したりするのは困難でした。
古い CSS の大きな問題点の XNUMX つは、ソース コードを読むだけでは、特定の CSS クラスを持つ要素がさまざまな画面サイズでどのように動作するかを視覚化するのが非常に難しいことでした。 これは、メディア クエリ セクションが数百行の CSS で区切られていたために発生しました。 たとえば、次の CSS を使用します。

.footer { カラー: #999; 表示ブロック; フロート: 左; 行の高さ: 20px; パディング: 0 0 0 5px; テキスト整列: 左; 幅: 120ピクセル; } /* 数百行後 */ @media のみ screen and (min-width: 768px) { /* 数百行後 */ .footer {padding: 0 0 0 30px; 幅: 15%; } } /* 数百行後 */ @media のみ screen and (min-width: 1024px) { /* 数百行後 */ .footer {padding: 0 0 0 40px; } }

もし私たちが読んでいたら、 .footer クラスをメディア クエリの XNUMX つの下に置いた場合、基本クラスに何が含まれていたか、どの基本プロパティがオーバーライドされていたか、どのメディア クエリ ブロックにいたのかを思い出すのは非常に困難になります。クラスをさらに追加すると、問題がさらに悪化するだけです。
その頃、私たちは偶然見つけたのが、 タキオンCSS ライブラリとその作成者であるアダム・モースが書いた次のタイトルの記事 CSS とスケーラビリティ.
その中で Adam は、CSS のスケーラビリティと再利用性の問題の核心はセマンティック クラス名の使用であり、そのようなシステムがあれば、CSS の作成を決してやめることはできないと主張しています。
その記事で述べられた最も興味深い点のいくつかを以下に示します。

• 新しいコンポーネントを構築する場合、またはアプリ内の UI の一部を変更する場合、どうしますか? アプリ内で利用可能な CSS をすべて読んで、再利用できるものがないかどうかを確認する人を私は知りません。
• CSS が再利用できないという前提から始めている場合、最初の直感は新しい CSS を作成することです。 しかし、おそらく、視覚スタイルの新しい分類を作成しているわけではありません。 私の経験では、既存のビジュアル スタイルを複製している可能性が高くなります。
• このモデルでは、CSS の記述をやめることはありません。 CSS のリファクタリングは難しく、時間がかかります。 使用されていない CSS を削除するのは困難で時間がかかります。 そしてたいていの場合、それは人々がやりたいと思えるような仕事ではありません。 それで何が起こるでしょうか？ 人々はますます多くの CSS を書き続けています。

そのため、私たちは Tachyons ライブラリを採用し、再デザインを実装するために記述しなければならない CSS がいかに少ないかに驚き、レスポンシブ デザインの実装が再び楽しいことに気づきました。
Tachyon には多数の CSS クラスが付属しており、それぞれのクラスにはプロパティが XNUMX つだけ含まれています。 例えば、 .fl 定義 float: left。 さらに、各クラスには応答性修飾子を持つクラスがあります。 例えば。 .fl-ns 適用するだけを意味します float: left 画面サイズが「小さくない」場合、または 480px 以上の場合。
これらのクラスをコンポーネントの構成要素として使用します。 たとえば、レスポンシブな 4 列レイアウトの XNUMX 列を次に示します。
つまり、画面が「小さくない」より大きい場合は左にフロートして幅の 50% を占め、画面が「中」より大きい場合は幅の 25% を占めます。 「小さくない」より小さい場合は、幅の 100% を占める div のデフォルトの動作を使用します。
Tachyon が私たちに提供するもう XNUMX つのものは、事前定義された一連の フォントサイズ & パディング/マージンの間隔 フォントと間隔のスケールとも呼ばれます。 このシステムにはいくつかの長所と短所があります。
最大の利点の 16 つは、サイズを決定する時間が大幅に短縮されることです。 たとえば、Tachyon を採用する前は、特定のセクションで 18 ピクセルまたは 8 ピクセルのフォント サイズを使用する必要があるか、それともパディングを 10 ピクセルまたは XNUMX ピクセルにする必要があるかをよく自問していました。 タキオンは一貫性を高めながら意思決定の数を減らします。
もちろん、欠点は、これらのスケールではなくサイズを使用したい場合です。 これを処理する方法は、スタイルをインライン化することだけです。通常、スタイルはいずれにせよ再利用されないため、これらの XNUMX 回限りのスタイルを CSS に含める理由はありません。
もう 4 つの問題は、通常は兄弟要素間で同じクラスの要素が繰り返されることです。 上記の 4 列コンポーネントの場合、それを XNUMX 回繰り返すことになります。 これは、複数のカーソルを使用するコード エディターにとっては小さな問題です。 それが問題になる場合は、テンプレート システムを使用してコンポーネントを抽象化できます。
全体として、これはスケーラビリティのための CSS システムが向かっている正しい方向であると考えています。 言い換えれば、CSS を拡張する最善の方法は、CSS の作成をやめるということです。