Generic First CSS：モバイルファーストの新しい考え方

EthanMarcotteのレスポンシブWebデザインは、世界中のWeb開発者にとって歓迎すべき啓示であったと言っても過言ではありません。 それは、デザイン思考のまったく新しい波と素晴らしい新しいフロントエンド技術を引き起こしました。 しばしば軽蔑されていたmドットのウェブサイトの治世も終わりました。 同じ時代に、ほぼ同じくらい影響力のあったのは、ルーク・ウロブレフスキーのモバイルファーストの方法論でした。これは、マルコットの印象的な基盤の上に構築された確かな改善です。

これらの手法は、ほとんどのWeb開発者の生活の基盤であり、私たちに役立ってきましたが、残念ながら、時代は変わり、開発者は絶えず繰り返します。 メソッドの効率が向上し、プロジェクト要件がより複雑になるにつれて、新たなフラストレーションが発生します。

ジェネリックファーストへの旅

ほぼ無意識のうちに起こったのは本当に自然な進歩だったので、CSSの書き方を変えた理由を正確に特定することはできません。 振り返ってみると、それは私が働いていた開発環境の副産物であったと思います。私が働いたチームは、CSS宣言内にブレークポイントを簡単に追加するための気の利いた小さなミックスインで進行中の素晴らしいSCSSワークフローを持っていました。 おそらく同様の手法を使用します。

この素晴らしい小さなSCSSミックスインにより、突然、非常にきめ細かいメディアクエリを簡単に作成できるようになりました。 次のような架空の伝記ブロックを考えてみましょう。

 .bio { display: block; width: 100%; background-color: #ece9e9; padding: 20px; margin: 20px 0; @include media('>=small') { max-width: 400px; background-color: white; margin: 20px auto; } @include media('>=medium') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

図1。 カスケードメディアクエリを使用した一般的なモバイルファースト

これはうまく機能します—私は過去にこのようなCSSをたくさん書いてきました。 しかし、ある日、デバイスの幅が広がるにつれてCSS宣言を上書きしても意味がないことに気づきました。 次の宣言でのみ上書きされるようにCSSプロパティを宣言するのはなぜですか？

これが、図1の例のように上向き（または下向き）にカスケードするメディアクエリのより一般的なアプローチとは対照的に、コンパートメント化されたメディアクエリの作成を開始する理由です。

画面サイズの増加に伴って上向きにカスケードするメディアクエリを作成する代わりに、目的の画面幅でスタイルをカプセル化するターゲットメディアクエリの作成を開始しました。 メディアクエリミックスインは、ここで実際に独自のものになります。 これで、SCSSメディアクエリは次のようになり始めました。

 .bio { display: block; width: 100%; padding: 20px; margin: 20px 0; @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

図2。 区分化されたメディアクエリの例

この新しいアプローチは、私にとってより直感的に感じられ、以前のブレークポイントからスタイルをリセットする必要がなくなり、CSSが読みやすくなりました。 さらに重要なことは、メディアクエリをより重要な方法で自己文書化することでした。

私はまだ上記に100％満足していませんでしたが、克服すべき大きな問題がまだあるように見えました。

モバイルファーストの問題

モバイルファーストの問題は、定義上、後続のメディアクエリでモバイルファーストスタイルをオーバーライドする必要がある可能性が高いことです。 これは少しアンチパターンのように感じます。

つまり、私にとっては、答えは明白でした。メディアクエリの区分化のアイデアを論理的な結論に導きましょう。また、モバイル固有のスタイルを独自のメディアクエリに区分します。 私は知っています、私は知っています、これは私たちが長年にわたって学んだ一般的な慣習に反します。 「モバイルファースト」は非常に普及しているため、通常、採用担当マネージャーが尋ねる「スキル」の質問の1つです。 だから確かにどんな選択肢も間違っているに違いないね？ これは通常、人々が最初に何度も携帯電話を発声しているときに私に頭を振る部分です。

さて、モバイルファーストの教義を打ち破り、すべてのスタイルを関連するメディアクエリに区分します。 現在残っているのは、CSSセレクターで宣言された純粋な汎用スタイルであり、他のすべてのデバイス固有のスタイルは、関連する画面サイズにのみ適用されるメディアクエリにカプセル化されています。 これで、 Generic FirstCSSができました。

 .bio { display: block; width: 100%; @include media('>=0', ' < small') { padding: 20px; margin: 20px 0; } @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

図3。 Generic FirstCSSの例

はい、メディアクエリは少し増えますが、これはメリットだと思います。開発者なら誰でもこのCSSを見て、メディアをバラバラにするという認知的オーバーヘッドなしに、すべての画面サイズでどのスタイルが適用されているかを正確に確認できます。クエリの特異性。

これは、コードベースに慣れていない人や将来のあなたにとっても素晴らしいことです。

区画化しない場合

メディアクエリの区分化が負担になる場合もあります。場合によっては、古き良き> =メディアクエリで問題ありません。 私たちがやろうとしているのは、プロパティの上書きを避けることだけです。

開発ツールブリス

コンパートメント化されたGenericFirst CSSを作成することの意図しない主な結果の1つは、開発者ツールのスタイルパネルから得られるエクスペリエンスです。 メディアクエリカスケードがないと、適用されるスタイルの概要がより明確になります—上書きされたメディアクエリルールからの削除された宣言でいっぱいのスタイルパネルはありません—ノイズはなくなりました！ これは、私にとっては、Generic FirstCSS手法の最大の利点の1つです。 それはCSSデバッグ体験に少し余分な正気をもたらします、そしてこれは金でその重みの価値があります。 後でありがとう。

パフォーマンスへの影響

したがって、これらのGeneric First CSSの利点はすべてかなり良いように聞こえ始めていますが、対処する必要があると思う最後の重要な質問が1つあると思います。 これは、パフォーマンスの最適化をテーマにしています。 今はまだはっきりとはわかりませんが、完全にコンパートメント化されたメディアクエリを使用すると、パフォーマンスがわずかに向上する可能性があります。

ブラウザは、計算スタイル計算と呼ばれるレンダリングタスクを実行します。 これは、任意の時点で要素に適用する必要があるスタイルを計算するブラウザーの方法です。 このタスクは常に最初のページの読み込み時に実行されますが、ページのコンテンツが変更された場合や他のブラウザのアクションが発生した場合にも実行できます。 プロセスの速度を上げることができれば、最初のページの読み込みに最適であり、Webサイトページのライフサイクルに複合的な影響を与える可能性があります。

では、一般的な最初のCSSに戻ります。ブラウザが多数のカスケードメディアクエリのCSS特異性を解決する必要があることに関連するパフォーマンスの問題はありますか？

これに答えるために、速度のメリットや実際のデメリットを測定するために使用できるテストケースを考案しました。

テストケース

テストケースは、「bio」ブロックを5000回出力する基本的なHTMLページで構成され、マークアップは各ブロックで同じですが、クラスがわずかに異なり（数値微分器）、このブロックのCSSも5000回出力されます。 、異なるのはクラス名だけです。 出力されたCSSは、CSS MQPackerと呼ばれるツールを介してパイプ処理されます。これにより、特定のメディアクエリのすべての個別のインスタンスを1つに結合することで、多くのインラインメディアクエリを使用するCSSのファイルサイズを大幅に削減できます。最新のCSSコードベース—テストプロジェクトpackage.jsonのnpmタスクを介してスタンドアロンのcliツールとして使用しました。また、postcssプラグインとしても使用できます。これは便利です。

最初のテストケースはモバイルファーストのカスケードメディアクエリの例であり、2番目のテストケースはCSSの一般的な最初のコンパートメント化されたバリアントです。 これらの場合のCSSは少し冗長で、おそらくもっと簡潔な言葉で書くことができますが、それは実際には議論をテストするための大まかな例として役立ちます。

テストは、デスクトップGoogle Chrome v70のCSSバリエーションごとに20回実行されました。これは、大量のデータセットではありませんが、パフォーマンスの向上/低下の大まかなアイデアを得るのに十分です。

私が使用することを選択したテストメトリックは次のとおりです。

• 全体的なページの読み込み時間
  <head>の先頭と<body>の最後にあるパフォーマンスAPIマーカーを使用してページの読み込み時間を確認するための基本的な指標
• 再計算スタイル
  開発ツールのパフォーマンスペイン内からの時間。
• 全体的なページレンダリング
  開発ツールのパフォーマンスペイン内からの時間。

結果テーブル（常にミリ秒単位）

図6。 モバイルファーストとジェネリックファーストCSSの主要な負荷/レンダリングメトリックを測定する20回のテスト実行。

私の確かに小さなデータセットから、私の最初の疑いは正しいかもしれないようです。 平均すると、スタイルの再計算タスクにかかる時間は42ミリ秒短縮され、速度が7.6％向上するため、全体的なレンダリング時間も短縮されます。 違いは驚くべきことではありませんが、それは改善です。 データセットが100％決定的なものになるほど大きくはなく、テストケースは少し非現実的だと思いますが、パフォーマンスの低下が見られないことを非常に嬉しく思います。

私は、モバイルファーストの方法で記述された実際の既存のコードベースに適用される一般的な最初の方法論を見ることに非常に興味があります。

そして、より広範な反復のセットでこのテストを自動化する方法について誰かが提案を持っている場合は、コメントで知らせてください！ これができるツールが必要だと思います。

結論

この新しい開発方法論の利点を要約すると...

• 意図したとおりに機能するCSSで、二度と推測する必要はありません。
• 自己文書化メディアクエリ;
• より優れた開発ツールエクスペリエンス。
• より速くレンダリングするページ。

このスタイルでCSSを書くことを支持しているのは私だけではないと思います。 すでに一般的な最初の考え方を採用している場合は、万歳！ しかし、そうでない場合は、それがもたらすメリットを本当に気に入っていただけると思います。 私は個人的に、整頓された開発ツールの経験から大きな恩恵を受けました。それ自体が多くの開発者にとって大きなプラスになるでしょう。 メディアクエリを作成するこの方法の自己文書化の性質は、自分自身とより広いチーム（ある場合）にもメリットがあります。 そして最後に、これらの利点はパフォーマンスの観点からは何の費用もかかりません。実際、速度がわずかに向上することが示されています。

最後の言葉

すべての開発方法論と同様に、それはすべての人に当てはまるわけではありませんが、私はGeneric First CSSに非常に自然に陥りました。今では、モバイルファーストのすべての利点といくつかの前向きな新しい追加を提供する貴重な作業方法と見なしています。フロントエンド開発の困難な仕事は、ほとんど簡単ではありません。

資力

テストケースリポジトリ

テストケースを起動して自分で試してみたい場合は、GitHubで見つけることができます。他の人からのレポートをいくつか見てみたいと思います。

ツール

• CSS MQPacker
• メディアを含める