FC2ブログでメイソンリーレイアウトは厳しい

2024/07/24

vanillaice (Akira)

厳しいといっても可能です。可能ですし技術的に難しいわけでもない。なので『難しい』ではなく『厳しい』という表現。

はじめにお願い事

本記事で私が何を伝えたいか最初に言うと賛同できる方はリクエストに賛成票をお願いします。。

テンプレート制作で利用できる FC2独自変数に、個々の画像のオリジナルサイズ(width, height)を抽出できるものを新規で提供して欲しい、というリクエストです。何故それを必要と感じているのか説明したいと思います。

全文表示タイプを好んで利用している方や、記事に画像を掲載することがほとんどない方は関連がありませんのでスルーして頂くか、内容にご納得頂けるならぜひご協力をお願いします。

本件は FC2ブログでもメイソンリーレイアウトをもっと簡単に(そして正攻法で) を目的としたものです。もちろんメイソンリーのためだけではありません。デザインの幅がもっと広がるはずです。

目次へ戻る↑

メイソンリーレイアウトとは

メイソンリー (masonry) というのはレンガを積み立てて作る建造物のことで、フリーメイソンの語源です。その形状に似ているところからメイソンリーレイアウトと呼ばれます。

* ウォーターフォールレイアウト(Waterfall layout) とも呼ばれます。

グリッドの仲間みたいな感じですが、グリッドが各アイテムの高さを揃えて形状を整えるのと違い、異なる高さのアイテムを詰めるようにして敷いていくレイアウトがメイソンリーです。メイソンリーで重要なのは高さです。

目次へ戻る↑

メイソンリーと画像の関係

この高さがねぇー、FC2ブログだとねぇー (∵`)

前章でサンプルにした3つのデザインはいずれも弊ブログの共有テンプレートですが、実はどれもあまり良くない。良くないと言っても構造的に問題があるだとか構文ルールに反しているといった意味ではありません。

① 最初の茶背景はjQueryでメイソンリーを形成しています。画像の縦横比はオリジナルを踏襲しています。
画像出力独自変数は <%topentry_image_url>

② 2つ目はpure JavaScriptで形成し、その画像はオリジナル縦横比ではなくランダム割当てです。
画像出力独自変数は <%topentry_image_url_760x420>

③ 3つ目もpure JSで、2つ目と同様オリジナル縦横比ではなくランダム割当てです。
画像出力独自変数は <%topentry_image_url_760x420>

オリジナル縦横比、というのはまぁ説明不要ですよね。原画と同じ形状のまま表示されるという意味です。縦長画像は縦長のまま、横長ならそのまま、という形。

縦横比ランダム割当の意味は、ローディングのたびに1アイテム目は 3:2、2アイテム目は 16:9、3アイテム目は 4:3、5アイテム目は… という感じで、予めいくつかの縦横比を用意しておき、ローディングの都度各画像に振り分け指定されます。なので例えばオリジナル縦横比が 3:2 だとしても 16:9 とか 1:1 とかに変更される可能性がある、つまりオリジナル縦横比を守らないということ。

ここでFC2ブログ上でメイソンリーがいかにしてメイソンリーになり得るか、なんですけども、画像の高さが各々異なることが絶対条件です。確実にメイソンリーにするには画像高さが重要。もちろんテキスト量で差を出すことも不可能とは言えませんが、テキスト量は大抵の場合行数制限をつけたり文字数制限をつけたり、根本的なことを言えば FC2独自変数でもって内容を抽出するので最大200文字という規定があります。となると記事『本文』に常にめいっぱい内容を書き記している方はどの記事でもほぼ制限の200文字に相当するのでアイテム間でテキスト量に差が生まれませんよね。なので差を出すには『画像の高さがバラバラであること』がより現実的な条件で結果的にそれが『アイテムの高さの格差』になります。

ということは常に記事『本文』に200文字以上記しており、かつ、画像のサイズを一定にしている場合はメイソンリーを実現できなくなります。web上の画像は 4:3 3:2 16:9 あたりが定石で黄金比でもありますので毎回同じサイズで揃えているという方も少なくありません。そういう方でも①を選択肢から外して② ③の仕組みを採用すればメイソンリーデザインを楽しむことが可能です。ただこれは正攻法と言えない、とも考えられますね。メイソンリーを採用したいのは

なんかおしゃれ
オリジナル画像と同じ形状(縦横比)で表示できる

というのが主な理由として挙げられるでしょうから後者が実現できません。

というかそれ以前にですね、本記事タイトルにある通り FC2ブログでのメイソンリーが厳しいという件を次章で説明します。

目次へ戻る↑

画像の縦横比はレイアウトシフトと深く関係する

Cumulative Layout Shift（CLS） | Articles | web.dev

この投稿では、Cumulative Layout Shift（CLS）指標を紹介し、その測定方法について説明します。

レイアウトシフト )Cumulative Layout Shift きゅーみゅらてぃゔれいあうとしふと) というのは、簡単に言えば『画面がガックンってなるやつ』のことです。目視している要素が何らかの要因でガクッと下方向へ位置移動してウザい、という誰しも一度は経験があるであろうアレです。上記リンク先記事ではCLSが発生している場合にどのような計算でスコア減点を受けるかが説明されています。

レイアウトシフト発生源は主に以下のようなものです。

素のHTML(row HTML)に記載されておらず、JSで動的に描画構築されるもの(広告など)
width, height属性が記されていない画像

画像というのはそれ自身がサイズを有していますよね。そしてそのサイズ情報というのは明示が無ければダウンロードが完了するまで不明という状態です。不明つまり高さゼロのまま次々と後続の要素が描画(レンダリング)されていきます。HTMLの描画は途中に点在する画像データのダウンロード完了を待ちません。次々描画されると同時に画像ダウンロードの作業も平行して行われます。

高さゼロとして処理されていた画像が、ダウンロードが完了した時点で本来の高さを発生させるので、画面ガクリ現象が起こります。これは簡単に回避可能で、画像のwidth, height属性をしっかりと記しておくことが対処法。ダウンロード完了前の領域確保・場所取りの役割を果たします。

ここでメイソンリーを考えてみましょう。メイソンリーは個々に高さの異なるアイテムの隙間を詰めるレイアウトだよ、という説明がありました。そしてテキスト(記事概要文)に文字数制限のあるFC2ブログに於いてアイテムの高さを決定する決め手は主に画像だよ、という説明もしました。ということはアイテム内の画像にwidth, height属性が記されていないとレイアウトシフトがめっちゃ発生するということになります。

メイソンリーの場合はレイアウトシフトだけではなく、『アイテム間を詰める作業』にも大きな影響が出ます。ちょっと専門的な説明になりますが、現状FC2ブログではメイソンリーレイアウトの実現にJavaScriptの利用が不可欠です(この点については後述します)
そしてJSの実行タイミングなんですが、ページの表示(閲覧者の目に見える状態になる・する)はDOM(HTML)読み込み直後がベストです。つまり画像のダウンロードを待たずに目に見える状態になるのが最善策。例えば画像がページ内に30点あり、その30の画像のダウンロードが完了してからページ描画、となれば『遅い』『重たい』と感じさせるページになってしまいます。

ところがもし画像にwidth, height属性が記されていないと、レンダリング時点で領域確保ができないわけですから、画像の高さがゼロと認知されたままJSが実行されてしまいます。実行とは各アイテムをどのように敷いて、距離をどう詰めるかの計算です。でもその計算はレンダリング初期段階では狂ってしまうわけです。だって画像のダウンロードが完了したら高さが変わるわけですからね。

昔よく目にしたのは『メイソンリーのJSは DomContentLoaded ではなく Load でなきゃダメ』みたいな。DOMツリー読み込み直後である『DomContentLoadedイベント』だと計算が狂うので、ページ内の某全てのダウンロードが完了してから実行する、それが『Loadイベント』です。遅いタイミングでの実行、ということですね。そしてその『遅いタイミング』での実行は、ユーザーに『まだ整形されていない状態を一瞬見せてしまう』ことにもなるため、イベント完了までページそのものを表示させない、という処理もよく行われていました。もうこれデザイナーあるあるです。絶対みんな心当たりある(笑)
今それやっちゃうとGoogle先生に「表示が遅せーよ」って怒られちゃう (∵`)

レイアウトが狂ってしまった例をサンプルとして ↓

上下のアイテム同士が重なっています。実行タイミングを正しく設定しなかったため、計算が狂ってしまった場合の例です。メイソンリーはリサイズの度に再計算を要するデザインなので、この状態からブラウザの幅をほんの少し、1pxでも変えると再計算されて正しい位置関係になります。いやそれ毎回せんといかんのかい (;`ｰ´)o ってなる。なのでこのままであれば構造欠陥デザインになってしまいますね。

* Mochaテンプレートをサンプルにしましたが、実際のMochaはこういったことは起こりませんのでご安心ください。

①のMochaはオリジナル縦横比適用で、そのJS内容は非常に複雑です。②のBehaviorと③のLiltingはそれと比較してJSはかなり軽量になっています。つまり動作環境はMochaよりも遥かに良い。『オリジナル縦横比を切り捨てる・度外視する』ことでそれを実現しています。

いずれにしろ FC2ブログには個々の画像の『横幅』『高さ』を取得する変数が無いので、ここが改善されればもっと上手くできるはず。オリジナル縦横比を尊重し、かつページ全体の表示スピードに極力影響を与えないJSを構築できるようになります。

現時点でどうしているかというと、②③については width="760" height="420" を記載しています。何故ならオリジナル画像ではなくサムネイル画像を用いており、そのサイズが一律これで確定しているからです。それをCSSの aspect-ratio (あすぺくとれいしょぉ) でランダムに縦横比変更している、という形。レイアウトシフトはほとんど起こりません。

①についてはオリジナル画像を表示させており、個々のサイズは不明なので width="200" height="200" とでたらめな数値を記載してあります。width, height属性無しだとシフトが顕著になるので苦肉の策としてのデタラメ数値。グリッドレイアウトの場合は必ずしもオリジナル縦横比を指定する必要は無いんです。結局CSSで再調整するわけなので。でもメイソンリーの場合②③のような振り切った仕様以外はオリジナルサイズがとっても重要なんですよね。それができないから困ってる。

目次へ戻る↑

メイソンリーとLazyload

Lazyload あるいは Lazyloading、現在では『ファーストビュー外(below the fold)画像はすぐにダウンロードしない、画面に入る直前でダウンロードすれば良い』という考え方が主流になってきました。そうすれば初期ローディングの負荷を大幅に軽減できるためです。

がしかし、Lazyloadを導入し、かつ、メイソンリーにしようと思えば width, height属性が必須というのは何度も言わずともおわかりかと思います。蛇足で一応説明すると、loading="lazy" を指定された画像、あるいはブラウザネイティブではなくJSでもってlazyloadingを指定された画像は、ファーストビュー内のもの以外はダウンロードされないのですから、画像を含めた各アイテムの『高さ』が計算時の最重要要素になるメイソンリーとは非常に相性が悪い、と。くどいようですが『width, height属性が記されていなければ』です。

新変数として例えば <topentry_image_width> <topentry_image_height> みたいなものが可能ならば、lazyloadingも問題なく利用できますし、メイソンリー構成のイベントタイミングも早い段階に設定できますから良いことしかない。

目次へ戻る↑

今後のメイソンリー

えーとごく最近ですが、メイソンリーレイアウトについて Webkitブログで発表がありました。発表というか「フィードバックください」的なやつだけれども。Appleが中心になっているのがWebkitです。ちなみにメイソンリーを初めて世に出したのは Mozilla です。みなさんご存知 Firefoxブラウザの開発元ですね。

Help us invent CSS Grid Level 3, aka “Masonry” layout

メイソンリーはいずれCSSだけで実現できるようになるはず、というのは多くのデザイナーがずっとそう考えていたところかと思います。実際それが近づいています。今議論されているのは分類をどうするのかです。

CSSボックスモデルに display というプロパティがあります。これはみなさんよく目に耳にするかと。例えば display: block とか display: flex とか display: grid とか。

メイソンリーを displayプロパティの一値として分類するのか、例えば display: masonry みたいな感じでしょうか。それとも全く別のプロパティとして独立させるのかが議題。独立とは例えば multi-columnレイアウトがそうですね。これは display: multi-column ではではありません。

上記リンク先記事でmulti-columnレイアウトを扱っています。「メイソンリー出来てるじゃん (∵`)」と思うなかれ。multi-columnは縦に配列していくレイアウトですから、時系列を横に配列していく『ブログ』とは相容れません。みなさんアイテムが縦横に並んでいれば時系列は左から右へ、下へ行ってまた左から右… と直感的に解釈しますよね。multi-columnは左上から左下へ、右に行ってまた上から下へ… というレイアウトです。でも形状・見た目では最も純CSSメイソンリー実現に近いと言えます。さてdisplayに含めるか、独立プロパティ化するのか。それが悩ましいところですよねぇ (∵`)

まぁでもいずれ決まるんで。いつになるかは知らないが(笑)
草案が通ればブラウザ実装も始まりますので楽しみですね。JS不要でメイソンリー、素晴らしいね。でも「そもそもメイソンリーレイアウトなんて要らんやろ」という方も居ますけどね。でももうみんな見て知っちゃってるし根強い人気があるので今更「要らん」とはならない。

目次へ戻る↑

ブログとメイソンリー

果たして『ブログ』というジャンルにメイソンリーは向いているのか？
向いていないと思います。これが正直なところ。なんかすみません ^^;

前章で時系列について少し触れましたが、メイソンリーはそもそも時系列を尊重しません。multi-columnの縦並び規則のような極端なことにはなかなかなりませんが、それでも都合の良い配列で見た目を整えるのがメイソンリー。例えば以下のように。

さらにスマートフォンで縦一列になった際、メイソンリーを解除(destroy)、あるいは調整(adjust)しないと、①③②④⑥⑤… みたいなめちゃくちゃな並びになります。横並びならまだしも縦一列でそれではさすがによろしくないですよね。

* Mochaテンプレートはシングルカラムの際に時系列を戻す処理をしてあります。

ブログ自体、時系列を重要とするサービスではあるんですが、その中でも『漫画や小説や解説など連載的なもの』は絶対的に向きません。逆に『画像など素材提供』だとそんなに時系列を気にしなくても良いのかな、と。大手画像共有サイトのほとんどがメイソンリーですしね。

なのでメイソンリーを検討する際は自身のブログの時系列について熟考する必要があります。ただなんとなくかっこいいな、で選ぶと後々大変です。『現状では』ですよ。JSのメイソンリーでは、です。CSSで実装されれば恐らく時系列遵守ができるようになると思います。最初のうちは無理かもしれんが。そして帳尻合わせが難しいのでJSより若干不格好になる可能性はあるけれども。

目次へ戻る↑

まとめ

現存変数の <topentry_image_url> が便利だけれどなかなか使える場面が限られているな、と。グリッドレイアウトで個々のアイテム領域(つまり画像の専有面積)が大きいときぐらいしか使い道が無いんですよね。画像に強いこだわりを持つユーザーさん、例えば一眼レフで撮った美麗な写真を掲載している方とか全文タイプを選びがち。全文タイプは画像表示に変数を必要とせず、オリジナルがそっくりそのまま表示されるので。

全文タイプは『追記』を利用してこそ活きる表示方法なのでできれば検討して欲しいな、と思います。

全文・要約を問わず、オリジナル表示が行われる場合は2MBとか容量の大きな画像をそのまま利用するのをちょっと考えて(控えて)もらえると良いかな、と思います。ロスレス圧縮したものをアイキャッチにして、原画はポップアップで見て貰うなどの工夫ですね。もちろんこだわりどころかもしれませんので強制するわけではありませんよ。

オリジナル表示のメイソンリーの場合で、各画像がMB級の容量を有しており、1ページあたりの記事表示件数が30件とか多め設定だとかなり無理が生じます。原画を縦横比そのままでサムネイル化(サイズ削減, 容量削減化)する変数というのはFC2ブログには現時点ではありませんので、やはり圧縮が効果的ですね。メイソンリーの場合はある程度の記事件数があった方が見栄えが良いですしね。せっかく綺麗な画像を綺麗に表示しても「なにこのクッソ重たいページ」とブラウザバックされたら本末転倒です。

というわけで、内容に賛同できる、と感じてもらえましたら清き一票お願いします (o'ω')ﾉ