約 15 年前、私は旅行代理店、空港職員、航空会社向けのアプリを開発する会社で働いていました。また、UI コンポーネントとシングルページ アプリ機能のための独自の社内フレームワークも構築しました。 フィールド、ボタン、タブ、範囲、データテーブル、メニュー、日付ピッカー、選択、複数選択など、あらゆるものに対応するコンポーネントがありました。 div コンポーネントもありました。ちなみに、私たちの div コンポーネントは素晴らしく、すべてのブラウザで角を丸めることができました。信じられないかもしれませんが、当時はこれを行うのは簡単なことではありませんでした。
私たちの取り組みは、JS、Ajax、動的 HTML が私たちを未来に導く革命とみなされていた歴史のある時点で行われました。突然、ページを動的に更新し、サーバーからデータを取得できるようになり、他のページに移動する必要がなくなります。他のページに移動すると、速度が遅いと見なされ、2 つのページの間の画面上に大きな白い四角形が点滅します。 Jeff Atwood (StackOverflow の創設者) によって有名になった次のようなフレーズがありました。 「JavaScript で作成できるアプリケーションはすべて、最終的には JavaScript で作成されることになります。」— Jeff Atwood
当時の私たちにとって、これは実際にアプリを作成する勇気のように感じられました。 JS ですべてを行うことが全面的に承認されているように感じました。 そのため、私たちはすべてを JS で行い、他の方法を研究することにあまり時間を割きませんでした。私たちは、HTML と CSS で何ができるのかを正しく学ぶ動機をあまり感じませんでした。私たちは、Web を全体として進化するアプリ プラットフォームとして認識していませんでした。特にブラウザのサポートに関しては、私たちはこれを回避する必要があると考えていました。作業を完了するには、さらに JS を投げるだけで済みます。 時間をかけて、Web がどのように機能するのか、またプラットフォームで何が利用できるのかについて詳しく学ぶことができたでしょうか?確かに、本当に必要のない大量のコードを削除することもできたかもしれません。でも、当時はそこまでではなかったのかもしれません。 ご存知のとおり、当時はブラウザーの違いが非常に重要でした。この時代は、Internet Explorer が依然として有力なブラウザであり、Firefox が僅差で 2 位でしたが、Chrome の人気が急速に高まったため、市場シェアを失い始めていました。 Chrome と Firefox は Web 標準に関する合意に非常に優れていましたが、アプリが実行されている環境では、長い間 IE6 をサポートする必要がありました。 IE8 のサポートが許可されたときでも、ブラウザ間の多くの違いに対処する必要がありました。それだけでなく、当時の Web にはプラットフォームにそれほど多くの機能が組み込まれていませんでした。
今日まで早送りしてみましょう。状況は大きく変わりました。これらの機能がこれまでよりも多くなっただけでなく、それらが利用可能になる速度も速くなりました。 もう一度質問させてください。Web がどのように機能するのか、そしてプラットフォームで何が利用できるのかについて、時間をかけて学んでみてはいかがでしょうか。まったくその通りです。今日の Web プラットフォームを理解して使用する方法を学ぶと、他の開発者よりも大きな利点が得られます。 パフォーマンス、アクセシビリティ、応答性、それらすべてを一緒に取り組んでいる場合でも、単に UI 機能の出荷に取り組んでいる場合でも、責任あるエンジニアとしてそれを行いたい場合は、利用可能なツールを知っておくと、より早く、より適切に目標を達成することができます。 もうライブラリが必要ないかもしれないもの 現在ブラウザが何をサポートしているかを知った上で、問題は、何を捨てられるかということです。 2025 年に角を丸くするには div コンポーネントが必要ですか?もちろん、そんなことはありません。 border-radius プロパティは、現在使用されているすべてのブラウザーで、現時点で 15 年以上サポートされています。さらに凝ったコーナーを実現するコーナー形状も近々登場します。 すべての主要なブラウザで利用可能になり、コードベース内の既存の依存関係を置き換えるために使用できる比較的最近の機能を見てみましょう。 重要なのは、お気に入りのライブラリをすべてすぐに捨ててコードベースを書き直すことではありません。他のすべてについては、まずブラウザーのサポートを考慮し、プロジェクト固有の他の要素に基づいて決定する必要があります。次の機能は 3 つの主要なブラウザ エンジン (Chromium、WebKit、Gecko) に実装されていますが、ブラウザのサポート要件が異なるため、すぐには使用できない場合があります。ただし、これらの機能について学び、いつか使用する計画を立てるには今が良い時期です。 ポップオーバーとダイアログ Popover API、
確かに、インターネット接続速度も向上したと思われますが、すべての人に当てはまるわけではありません。また、誰もが同じデバイス機能を持っているわけでもありません。 代わりに、プラットフォームで実行できることのためにサードパーティのコードを利用することは、おそらく、より多くのコードを出荷することになり、通常よりもリーチできる顧客が少なくなる可能性があります。ウェブでは、読み込みパフォーマンスが悪いと大きな離脱率が発生し、ブランドの評判が傷つきます。 デバイス上で実行するコードの削減 さらに、顧客のデバイスに出荷するコードは、プラットフォーム上で使用する JavaScript 抽象化の数が少ないほど、より高速に実行される可能性があります。また、デフォルトではおそらく応答性が向上し、アクセスしやすくなります。これらすべてが、より多くの顧客の幸せにつながります。 私の同僚の Alex Russell が毎年書いているパフォーマンス格差ギャップ ブログをチェックしてください。このブログでは、富の不平等により、数十億人のユーザーがいる市場にはプレミアム デバイスがほとんど存在していないことがわかります。そして、この差は時間の経過とともに広がるばかりです。
組み込みの石積みレイアウト もうすぐ登場する Web プラットフォーム機能の 1 つで、私がとても楽しみにしているのは CSS Masonry です。
まずメイソンリーとは何かについて説明します。 石積みとは何ですか メーソンリーは、数年前に Pinterest によって人気を博したレイアウトの一種です。コンテンツの独立したトラックが作成され、その中にアイテムがトラックの開始近くにできる限り詰め込まれます。
多くの人はメイソンリーをポートフォリオやフォトギャラリーに最適な選択肢だと考えていますが、確かにそれは可能です。しかし、Masonry は Pinterest で見られるものよりも柔軟で、滝のようなレイアウトだけに限定されません。 石積みレイアウトの場合:
トラックは列または行にすることができます。
コンテンツのトラックはすべて同じサイズである必要はありません。
アイテムは複数のトラックにまたがることができます。
アイテムは特定のトラックに配置できます。常に自動配置アルゴリズムに従う必要はありません。
デモ ここでは、Chromium での CSS Masonry の今後の実装を使用して作成したいくつかの簡単なデモを示します。 アイテム (この場合はタイトル) が複数のトラックにまたがる様子を示すフォト ギャラリーのデモ:
さまざまなサイズのトラックを示す別のフォト ギャラリー:
一部のトラックが他のトラックよりも幅が広く、一部の項目がレイアウトの幅全体に及ぶニュース サイトのレイアウト:
アイテムを特定のトラックに配置できることを示すカンバン ボード:
注:以前のデモは、CSS Masonry がブラウザーに実装され始めたばかりであるため、ほとんどの Web ユーザーがまだ利用できないバージョンの Chromium を使用して作成されました。 しかし、Web 開発者はすでに何年も前からライブラリを喜んで使用してメイソンリー レイアウトを作成してきました。 現在石材を使用している現場 実際、メイソンリーは今日のウェブ上でかなり一般的です。 Pinterest 以外に私が見つけた例をいくつか紹介します。
さらに、それほど明白ではない例をいくつか挙げます。
では、これらのレイアウトはどのように作成されたのでしょうか? 回避策 私が使用したことのあるトリックの 1 つは、代わりに Flexbox レイアウトを使用し、その方向を列に変更し、折り返すように設定することです。 このようにして、高さの異なるアイテムを複数の独立した列に配置して、石積みのレイアウトのような印象を与えることができます。
ただし、この回避策には 2 つの制限があります。
アイテムの順序は、実際の石積みのレイアウトとは異なります。 Flexbox では、アイテムは最初に最初の列に入力され、いっぱいになると次の列に移動します。メーソンリーでは、アイテムは利用可能なスペースがより多いトラック (この場合は列) にスタックされます。 しかし、おそらくもっと重要なことですが、この回避策では、Flexbox コンテナに固定の高さを設定する必要があります。そうしないと、ラッピングは行われません。
サードパーティのメーソンリー ライブラリ より高度なケースでは、開発者はライブラリを使用してきました。 このための最もよく知られ人気のあるライブラリは単純に Masonry と呼ばれ、NPM によると、週に約 200,000 回ダウンロードされます。 Squarespace は、ノーコードの代替手段として、Masonry レイアウトをレンダリングするレイアウト コンポーネントも提供しており、多くのサイトがそれを使用しています。 これらのオプションは両方とも、JavaScript コードを使用してレイアウトに項目を配置します。 組み込み石積み Masonry が組み込みの CSS 機能としてブラウザーに表示され始めたことに本当に興奮しています。時間が経つと、Masonry を Grid や Flexbox と同じように使用できるようになります。つまり、回避策やサードパーティのコードを必要とせずに使用できるようになります。 Microsoft の私のチームは、Edge、Chrome、その他多くのブラウザーのベースとなっている Chromium オープン ソース プロジェクトに組み込みの Masonry サポートを実装してきました。実際、Mozilla は 2020 年に Masonry の実験的実装を提案した最初のブラウザ ベンダーでした。そして Apple も、この新しい Web レイアウトの原始的な実現に非常に興味を持っていました。 この機能を標準化する作業も進んでおり、CSS ワーキング グループ内では一般的な方向性と、新しい表示タイプであるグリッド レーンについての合意が得られています。 メイソンリーについてさらに詳しく知り、進捗状況を追跡したい場合は、私の CSS メイソンリーのリソース ページをチェックしてください。 やがて、Masonry が Grid や Flexbox と同様に Baseline 機能になると、私たちはそれを簡単に使用できるようになり、次のようなメリットが得られるようになります。
より良いパフォーマンス、 応答性が向上し、 使いやすさとコードの簡素化。
これらを詳しく見てみましょう。 パフォーマンスの向上 独自のメイソンリーのようなレイアウト システムを作成するか、代わりにサードパーティのライブラリを使用すると、画面上に項目を配置するために JavaScript コードを実行する必要があります。これは、このコードがレンダリング ブロックになることも意味します。実際、JavaScript コードが実行されるまでは、何も表示されないか、適切な場所または適切なサイズに表示されません。 メーソンリー レイアウトは Web ページのメイン部分によく使用されます。つまり、コードによってメイン コンテンツが通常よりも遅く表示され、知覚されるパフォーマンスと検索エンジンの最適化に大きな役割を果たす LCP (最大コンテンツフル ペイント メトリクス) が低下します。 シンプルなレイアウトを使用し、DevTools で低速 4G 接続をシミュレートすることによって、Masonry JS ライブラリをテストしました。ライブラリはそれほど大きくありません (24 KB、gzip 圧縮された場合は 7.8 KB) が、私のテスト条件ではロードに 600 ミリ秒かかりました。 以下は、Masonry ライブラリの 600 ミリ秒という長い読み込み時間と、その間に他のレンダリング アクティビティが発生しなかったことを示すパフォーマンス記録です。
さらに、初期ロード時間の後、ダウンロードしたスクリプトを解析し、コンパイルして実行する必要がありました。前述したように、これらすべてがページのレンダリングをブロックしていました。 ブラウザーに組み込みの Masonry 実装を使用すると、スクリプトをロードして実行する必要がなくなります。ブラウザ エンジンは、最初のページ レンダリング ステップ中にその処理を実行します。 応答性の向上 ページが最初に読み込まれるときと同様に、ブラウザ ウィンドウのサイズを変更すると、そのページのレイアウトが再度レンダリングされます。ただし、この時点で、ページが Masonry JS ライブラリを使用している場合、スクリプトはすでにロードされているため、スクリプトを再度ロードする必要はありません。ここ。ただし、項目を適切な場所に移動するコードを実行する必要があります。 この特定のライブラリは、ページの読み込み時にこれをかなり高速に実行しているようです。ただし、ウィンドウのサイズ変更時にアイテムを別の場所に移動する必要がある場合はアニメーション化され、大きな違いが生じます。 もちろん、ユーザーは私たち開発者ほどブラウザ ウィンドウのサイズ変更に時間を費やしません。ただし、このアニメーションによるサイズ変更エクスペリエンスはかなり不快になる可能性があり、ページが新しいサイズに適応するまでにかかる時間が長くなる可能性があります。 使いやすさとコードの簡素化 Web 機能の使いやすさとコードの見た目は、チームに大きな違いをもたらす重要な要素です。もちろん、最終的なユーザー エクスペリエンスほど重要になることはありませんが、開発者のエクスペリエンスは保守性に影響を与えます。組み込みの Web 機能を使用すると、次のような重要な利点が得られます。
HTML、CSS、JS をすでに知っている開発者は、この機能を簡単に使用できる可能性が高くなります。これは、この機能が Web プラットフォームの他の部分と適切に統合され、一貫性を保つように設計されているためです。 機能の使用方法に重大な変更が導入されるリスクはありません。 その機能が非推奨になったり、メンテナンスされなくなったりするリスクはほぼゼロです。
組み込みの Masonry の場合、レイアウト プリミティブであるため、Grid や Flexbox と同じように CSS から使用し、JS は関係しません。また、ギャップなどの他のレイアウト関連の CSS プロパティも期待どおりに機能します。知っておくべきトリックや回避策はなく、学んだことは MDN に文書化されています。 Masonry JS ライブラリの場合、初期化は少し複雑です。特定の構文を持つデータ属性と、列とギャップのサイズを設定するための非表示の HTML 要素が必要です。 さらに、列をまたがる場合は、問題を避けるためにギャップ サイズを自分で含める必要があります。
<スタイル> .トラックサイザー、 .item { 幅: 20%; } .gutter-sizer { 幅: 1レム; } .item { 高さ: 100ピクセル; マージンブロックエンド: 1rem; } .item:nth-child(奇数) { 高さ: 200ピクセル; } .item--width2 { 幅: calc(40% + 1rem); }
これを組み込みの Masonry 実装がどのようになるか比較してみましょう。 <スタイル> .container { 表示: グリッドレーン; グリッドレーン:repeat(4, 20%); ギャップ: 1レム; } .item { 高さ: 100ピクセル; } .item:nth-child(奇数) { 高さ: 200ピクセル; } .item--width2 { グリッド列: スパン 2; }
よりシンプルでコンパクトなコード。ギャップなどを使用するだけでよく、グリッドと同様にスパン 2 でトラックのスパニングが行われ、ギャップ サイズを含む適切な幅を計算する必要がありません。 何が利用可能か、いつ利用可能になるかを知る方法は? 全体として、問題は実際に JS ライブラリではなく組み込み Masonry を使用するべきかどうかではなく、いつ使用するかということです。 Masonry JS ライブラリは素晴らしく、長年にわたって Web プラットフォームのギャップを埋め、多くの開発者やユーザーを幸せにしてきました。もちろん、組み込みのメイソンリー実装と比較するといくつかの欠点がありますが、その実装の準備が整っていない場合、それらは重要ではありません。 私はブラウザ ベンダーで働いているため、今後何が登場するかを知っている傾向があるため、これらの新しい Web プラットフォーム機能をリストするのは簡単です。しかし、開発者たちは、調査を重ねるごとに、新しいものを追跡するのは難しいということをよく共有します。常に情報を得るのは難しく、企業は常に学習を優先しているわけではありません。 これを支援するために、必要な情報をすぐに入手できるように、シンプルかつコンパクトな方法で更新を提供するリソースをいくつか紹介します。
Web プラットフォームにはエクスプローラー サイトが備わっています。 リリース ノート ページに興味があるかもしれません。 RSS が好きなら、リリース ノート フィードや、新しく利用可能なベースライン フィードと広く利用可能なベースライン フィードをチェックしてください。
ウェブプラットフォームステータスダッシュボード: さまざまな基準年のページが気に入るかもしれません。
Chrome プラットフォーム ステータスのロードマップ ページ。
もう少し時間があれば、ブラウザ ベンダーのリリース ノートにも興味があるかもしれません。
クロム エッジ Firefox サファリ
さらに詳しいリソースについては、Web プラットフォームのナビゲート チートシートを参照してください。 私のことはまだ実装されていません それが問題の裏側です。たとえ時間、エネルギー、追跡する方法を見つけたとしても、自分の意見を聞いてもらい、お気に入りの機能を実装することには依然としてフラストレーションが伴います。 もしかしたら、特定のバグが解決されるのを何年も待ったり、ブラウザに特定の機能がまだ搭載されていないのにリリースされたりするのを何年も待っているかもしれません。 私が言いたいのは、ブラウザベンダーは耳を傾けるということです。私は組織横断的な複数のチームの一員であり、開発者のシグナルやフィードバックについて常に議論しています。私たちは、各ブラウザー ベンダーの内部と、フォーラム、オープン ソース プロジェクト、ブログ、アンケートなどの外部/公開の両方で、さまざまなフィードバック ソースを調べています。また、私たちは開発者が特定のニーズやユースケースを共有するためのより良い方法を作成するよう常に努めています。 したがって、可能であれば、ブラウザ ベンダーにさらに多くの要求をして、必要な機能を実装するよう当社に圧力をかけてください。時間がかかり、（参入障壁が高いことは言うまでもありませんが）怖ろしく感じることもあると思いますが、効果もあります。 あなた (またはあなたの会社) の声を聞いてもらうためのいくつかの方法を次に示します。毎年行われる「JS の現状」、「CSS の現状」、および「HTML の現状」調査に参加してください。これらは、ブラウザー ベンダーが自社の作業に優先順位を付ける際に大きな役割を果たします。 特定の標準ベースの API をブラウザ間で一貫して実装する必要がある場合は、次の Interop プロジェクト イテレーションで提案を提出することを検討してください。もっと時間がかかりますが、Shopify と RUMvision が Interop 2026 のウィッシュ リストをどのように共有したかを考えてみましょう。このような詳細な情報は、ブラウザ ベンダーが優先順位を付けるのに非常に役立ちます。 ブラウザ ベンダーに影響を与えるためのさらに便利なリンクについては、Web プラットフォームのナビゲート チートシートを参照してください。 結論 最後に、この記事があなたにいくつかの考えを残していただければ幸いです。
メイソンリーやその他の今後の Web 機能に興奮しています。 使い始めてみるとよい Web 機能をいくつか紹介します。 組み込み機能を優先して、いくつかのカスタム コードまたはサードパーティ コードを削除できる場合があります。 これから何が起こるかを追跡し、ブラウザー ベンダーに影響を与えるためのいくつかの方法。
さらに重要なのは、Web プラットフォームを最大限に活用するメリットをご理解いただけたでしょうか。
