1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

重力とレスポンシブ

1
Posted at

Webサイト上にはこの宇宙に浮かぶ惑星と同じく、重力があります。

ここでいう「重力」とはざっくりというとものは下方向にぶら下がる力のことと思ってもらうのがよく、つまりHTMLの内部で上に置かれているものはそのまま上に、下に置かれているものはそのままであれば下に配置されるという法則としての力です。

これはHTMLに限った話ではなく、今書いているマークダウン形式の文書などもそうでしょう。
シンプルなまま、何の断りもなく改行していけば自然と次のものは下へ下へと向かっていきます。

ここで挙げる例として適切かは分かりませんが、いわゆる横向き(インライン)に並んだ文字やアイテムの「折り返し」も重力の影響と言えるかもしれません。あらかじめ幅が決められた中でいっぱいになれば、次の行へと折り返すことで内容を収めようとする下向きの力があります。

# h1
p
## h2
p
### h3
- ul /* 重力に従えば縦にどんどん伸びていく */
  - li
  - li
  - li

ただし、それぞれの表示領域より縦に長いものを限られた画面の中で読み取るためにはスクロールが必然的に発生します。そのスクロール量は少なければ少ないほど1画面中に(その良し悪しはさておき)多くの情報が詰め込めるため、デザイン提案ではよくこれを横並びにすることで過剰な画面の「伸び」を解決します。

# h1
p
## h2
p
### h3
- ul
  - li + li + li /* 横並びにすることで収まりがよくなる */

この操作は本来は縦に縦に……と並んでいるものをただ「横並び」にしただけに見えますが、実体としては大原則である重力に逆らって配置しているということになります。

ここで言いたいのはあくまで(外側の)見た目では横向きに並んでいてもHTMLなど(裏側の)データ構造上では縦向きに積まれたままということなのですが……この絶対的な重力から逃れるためにはCSSなど外部からスタイルを調整するための力を使う必要があり、主に以下の2つの方法が使われます。
(ここでは float や、テキストのようなインラインによる横並びはいったん考慮しないものとします)

  • 絶対配置 position: absolute; などを使い、自由に位置指定することで横並びに「見せる」
  • 新たに重力を無視・変更できる空間 display: flex; display: grid; で囲み、横並びを「強制する」

どちらの方法でも同じ「見た目」自体は作成できますが、その実体や扱うべき場面は異なります。特に「レスポンシブ」(≒様々な端末で見ること)を意識したものを作るのであれば、前者の絶対配置についてはそれこそ 「絶対に」 避けるべきでしょう。
重力の流れからフワフワ浮いたものは自由な反面、いかなる法にも縛られていないに等しいので、それらを制御するにはそれこそより厳密な座標の指定( top: ... bottom: ... left:... right: ... )が必要になります。

ただし、絶対配置やその他の方法を使わなければなり立たない場合があります。そもそも 「レスポンシブ先のデザインが同じ重力に従っていない」 場合だとそうせざるを得ません。

たとえば、アイテム数が3つのリストがあります。これをSPでは縦に、PCでは横に並んでいるようにするには、先ほども言った通りPCでのみ重力の変更を「強制する」仕組みを作ればよいです。

/* SPのリスト(縦並び) */
ul
  li
  li
  li
/* PCのリスト(横並び) */
ul  /* 横並びを強制 */
  li + li + li

SP環境は比較的画面が狭いので横並びにすることがむしろデザイン上はリスクとなることが多いのですが、スマホファーストと叫ばれて久しいなか、むしろ自然的な重力に沿ったレイアウトになりやすい端末環境だといえるでしょう。
それに比べて画面の広いPCでは縦に並び続けるというのは横並びで画面を埋めることが求められがちです。

これだけであればとても簡単なレスポンシブ対応の例なので、何も困ることはありません。
ただし、加えてこのリストが 「ニュースの最新3件を抜粋して表示する」 パーツであり、3件の表示が完了したあとに「一覧を見る」リンク a を追加するとします。

/* SPのニュースリスト(縦並び)+「一覧を見る」リンク */

ul
  li | ニュース1
  li | ニュース2
  li | ニュース3
a | 一覧を見る

重ね重ね、SPに関しては何も問題ありません。最後に「一覧を見る」リンクが増えるだけです。

しかしレスポンシブ対応を考えてPC用のデザインに組み替えた際にも「一覧を見る」ボタンはリストの末尾にいるでしょうか?

例えばニュースリストの右上が余っているならそこに置きたくなったりしませんでしょうか?

/* PCのニュースリスト(横並び)+「一覧を見る」リンク */

                                  a | 一覧を見る
ul /* 横並びを強制 */
  li | ニュース1 + li | ニュース2 + li | ニュース3

(ふとした出来心によって)さきほどSPではリストの下にあった「一覧を見る」が逆にリストの上に移動してしまいました。

この場合、SPに対してPC用のレイアウトが 「作成しようとしているレイアウトが同じ重力に従っていない」 ため両者の順序や構造が成立していないことがわかりますでしょうか。
PC向けの「一覧を見る」はSP用の構造(リストの後ろ)から一つだけ浮いた状態になってしまっています。

こういった場合に先ほどの絶対配置を使えば、 a を意図的に浮かせることができるため、SPで作成した構造は変えずに位置を調整することは可能です。ただし実際に作成するパーツはこの例よりももっと複雑になることがほとんどで……レスポンシブ化というパズルを考える際にこういった 「構造上そこにあったものがなくなる」ことが増えるとパズルの難易度は格段に上昇 してしまいます。

SPもPCもすべて同じ重力に沿ってくれていればわかりやすいのにと考えれば……見た目を分けるための別解としてPC用とSP用の「一覧を見る」リンクをそれぞれの位置に分割することがあります。

/* SPニュースリスト+「一覧を見る」 */

// /* SPでは非表示 */ a | 一覧を見る 
ul
  li
  li
  li
a | 一覧を見る / *SPなので表示 */
/* PCニュースリスト+「一覧を見る」 */

/* PCなので表示 */  a | 一覧を見る 
                 
ul  /* 横並びを強制 */
  li + li + li
  
// a | 一覧を見る /* SPは非表示 */

これで構造と重力の問題は完全に解決するのですが、できるだけ裏側もキレイに作ろうとしている側からするとこれは冗長というか、あえて感情的な言い方をすると 「悔しい」構造 になってしまいます。

こうなるとレスポンシブ化がしたかったはずなのにPCサイト用とSPサイト用の2つ画面を作っていた古のコーディングと変わらなくなってしまいますし、きちんと適切な対応をしなければスクリーンリーダーなどにも2つ全く同じ要素が存在すると扱われてしまったりするでしょう。

それにWebというのは更新のしやすさがウリなので、もし今後「一覧を見る」のリンク先が変更されるとなった場合、そもそもボタンが分かれていることを認識できなければ 「PCだけ変えてSPは変え忘れた」 なんてことのリスクにもつながります。こう考えると同じ役割を持つものはできるだけ統合すべきですし、なによりSPやPCといった端末間で情報構造の提示順序が変わらないことも、遍く環境を意識したアクセシビリティ対応としてはごく基本的なことではないでしょうか。

つまり重力を意識していないレスポンシブデザインを作成する場合、HTMLやCSSの工夫でこういった「無理」を通さないといけなくなってしまいます。それがとても「悔しい」ということ……。

……なぜこういった「重力に基づかない」レスポンシブデザインが生まれてしまうのかについては議論の余地がありますが、一つはIllustratorやPhotoshopといった、Webに特化していない既存のデザインツールが絶対配置( position: absolute; )を容易に行えてしまうツールであったことが一因としてあるかと思います。

制御するにはそれこそより厳密な座標の指定( top: ... bottom: ... left:... right: ... )が必要になります。

CSSでは厳密に指定しないといけないものを、デザイン上ではただドラッグ&ドロップでオブジェクトの座標を触り放題・順序も入れ替え放題ですし、印刷物のような紙面であればあらかじめ描画できる領域が決まっているので成立するものも、表示領域が決まっていないWebコーディングでは同じように全ての要素を宙に浮かせてしまうと、デザインで想定されているアートボードの一画面と全く同じ比率でしか成立しないページになってしまいます。

そこを「よしなに」するのがコーディング側の腕の見せ所でもあるのですが……デザイン時点でそれが意識されていなければ、上記のような無理がたたって結果としてほとんどの環境で想定通りに表示されない(そもそも想定しようがない……?)「ダサい」デザインになってしまうでしょう。

Figmaに存在する「オートレイアウト」機能は、これを解決する一つのアプローチだと思います。そもそもFigma自体がブラウザ上で機能するツールなので、実際のWebに近い挙動が比較的容易にシミュレーションできるメリットもありますが、これまでのデザイン修正上も「横向きに収まらない文字やオブジェクトは次の行に落とす」「落ちた場合も余白は等間隔に設ける」といった処理は、Web向けの画面レイアウトを組む以上はごく自然に行っていた操作なのではないでしょうか。

少なくともFigmaのようなWebに最適化されたツールであれば、領域内に収めるためだけに文字サイズの一部を小さくしたり字間を縮めたりこっそり文字が長体や平体にされているような愚行は行いづらくなるでしょう。意図の伝わらないデザインは伝わらないまま実装されてしまいます……。

改めて、Webサイトを作る上では構造上抗うことのできない重力が存在します。

ただ、重力に抗うレイアウトを考えること自体がevilなのではなく、重力に抗う形になっていることに説得力を持たせたり、なぜ重力に反してまで情報の提示順序を変えたいのかなど、明確な意図をもったデザインによるコミュニケーションが取れると、それこそ成果物のクオリティは担保されやすくなると感じます。

重力に反して要素を持ち上げたいときは、デザイン・コーディング側がお互いに気合いを入れて、思わぬケガに繋がらないよう油断せず持ち上げましょう🏋️


J.B.Goode Inc.に所属しています。良ければフォローお願いします!

J.B.Goode Inc.のウェブサイトでは、技術記事の他にも技術ナレッジや日々の気づき等を配信しています。
https://www.jbgoode.jp/

カジュアル面談も実施中です。お気軽にお問い合わせください。
https://www.jbgoode.jp/recruit/

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?