タグ: フロントエンド連載

PCでは完璧なのに、スマホで崩れる。そして直そうとすると分岐が増えていく。

順番を逆にすると、この2つが同時に減ります。狭い画面を初期状態にして、広い画面に足していく書き方です。

そもそもレスポンシブデザインとは

1つのHTMLで、スマホでもPCでも適切に表示する作り方です。

かつてはPC用サイトとスマホ用サイトを別々に作っていました。しかし端末の画面サイズは無数にあり、作り分けは現実的ではありません。そこで、画面幅に応じてCSSの当たり方を変えるという方法が標準になりました。

今のWebアクセスは半分以上がスマートフォンです。「まずスマホで成立させ、広い画面には余裕を足す」という順番で考えるのが現在の基本になっています。

あわせて出てくるSassは、CSSを書きやすくする拡張です。変数を使ったりファイルを分けたりでき、最終的には普通のCSSに変換されます。

よくある書き方（Before）

.title { font-size: 32px; }
@media (max-width: 768px) { .title { font-size: 24px; } }
@media (max-width: 375px) { .title { font-size: 20px; } }

端末が増えるたびに分岐が増えます。

直した書き方（After）

.title { font-size: clamp(1.25rem, 4vw, 2rem); }

最小1.25rem、最大2rem、その間は画面幅に応じて滑らかに変化します。分岐ゼロです。

なぜそうなるか

モバイルファースト

max-width で「大きい画面から削っていく」より、min-width で「小さい画面に足していく」ほうが記述が減ります。狭い画面は縦一列が基本形なので、そこを初期状態にするのが自然です。

.list { display: grid; gap: 16px; }
@media (min-width: 768px) { .list { grid-template-columns: repeat(3, 1fr); } }

命名で壊れなくする（BEM）

.card {}            /* Block  かたまり */
.card__title {}     /* Element  かたまりの部品 */
.card--featured {}  /* Modifier  状態違い */

クラス名を見ただけで所属が分かるので、他の場所に影響しません。SMACSSなど他の流儀もありますが、チームで1つに統一されていることが本質です。

アニメーション

.card { transition: transform .2s ease-out; }
.card:hover { transform: translateY(-4px); }

動かすプロパティは transform と opacity を優先します。width や top を動かすとレイアウト計算が毎フレーム走り、カクつきます。

Sass

変数・入れ子・ファイル分割ができます。ただし入れ子を深くしすぎると詳細度が上がって前回の問題が再発するので、3階層までを目安に。

手を動かす課題

一覧ページをスマホ幅（375px）で開き、横スクロールが出ないところまで直してください。仕上げに、カードのホバーで浮き上がる動きを transition で付けます。

次回はSEOです。実装者が責任を持つ範囲だけに絞って扱います。

今回の学び

まず、大きい画面から削るより、小さい画面に足すほうが記述が減るということ。狭い画面は縦一列が基本形なので、そこを初期状態にするのが自然でした。

次に、命名の目的は、影響範囲を閉じることだということ。クラス名の流儀はいくつもありますが、どれを選ぶかより、1つに統一されていることのほうが効いていました。

そして、動かすものを選ぶと、カクつきが消えること。幅や位置を動かすと毎フレーム計算が走ります。同じ見た目でも、何を動かすかで滑らかさが変わります。

「なぜか効かないCSS」と「なぜか幅が合わない」。CSSで詰まる場所は、ほぼこの2つに集約されます。

原因は文法ではありません。要素同士の影響関係です。今回はそこだけを扱います。

そもそもCSSとは

HTMLで書いた要素に、見た目を指定する言語です。

HTMLが「ここは見出し」と宣言するのに対し、CSSは「見出しは32pxの太字で青色」と決めます。同じHTMLでも、CSSを差し替えるだけで全く別のデザインになります。

セレクタ { プロパティ: 値; }
h1      { color: navy; }

書き方はこの1パターンだけ。覚えることが多いように見えるのは、プロパティの種類が多いからで、文法そのものは10秒で理解できます。難しいのは文法ではなく、要素同士の影響関係です。今回扱うのはそこです。

よくある書き方（Before）

.card { width: 300px; padding: 20px; border: 1px solid #ccc; }

3枚並べると横に収まらない。width: 300px と指定したのに、実際の幅は342pxだからです。

直した書き方（After）

*, *::before, *::after { box-sizing: border-box; }

.card { width: 300px; padding: 20px; border: 1px solid #ccc; }

border-box にすると、paddingとborderを含めて300pxになります。これはほぼ全ての現場で最初に書く1行です。

なぜそうなるか

ボックスモデル

要素は内側から content → padding → border → margin の4層です。初期値の content-box では width が最内側のcontentだけを指すため、余白と枠線が外側に足されます。

詳細度

CSSが効かないときは、後から書いたものが勝つとは限りません。強さの順は次の通りです。

インラインstyle  >  #id  >  .class / :hover / [属性]  >  要素名

!important で殴ると一時的に直りますが、次に上書きしたい人がさらに !important を書くことになります。詳細度は上げず、揃えるのが原則です。

並べる2つの道具

/* 横一列。中央寄せや折り返しが得意 */
.list { display: flex; gap: 16px; flex-wrap: wrap; }

/* 格子。列数を決めたいときはこちら */
.list { display: grid; gap: 16px; grid-template-columns: repeat(3, 1fr); }

使い分けは「1方向に並べるならFlex、行と列の両方を揃えたいならGrid」。迷ったらどちらで書いても動きます。

手を動かす課題

第1回で作った一覧に、カード型のCSSを当ててください。同じ見た目をFlexboxとGridの両方で組むのが課題です。書き終えたら、どちらが少ない記述で済んだかメモしてください。

次回はCSS応用です。画面幅が変わっても崩れない書き方に進みます。

今回の学び

まず、幅の指定は、どこまでを幅と呼ぶかの取り決めに依存しているということ。300pxと書いたのに342pxになるのは不具合ではなく、初期値がそう決まっているからでした。

次に、強さで殴ると、次の人はもっと強く殴ること。一度その手を使うと、以降その場所を触る全員が同じ手を使うことになります。上げるのではなく揃えるのが原則です。

そして、効かないときは推測せずに打ち消し線を見ること。ブラウザの開発者ツールは、どの指定がどれに負けたかを線で表示してくれます。読むだけで答えが出ます。

見た目は作れる。ただ、自分が書いたHTMLを読み返すと、タグの選び方が雑だと分かる。ここで止まっている人は多いと思います。

HTMLは見た目を作る言語ではなく、意味を伝える言語です。そこが入れ替わっていると、何度書き直しても同じところで雑になります。

そもそもHTMLとは

文書の構造を説明するための言語です。プログラミング言語ではありません。

Wordで文章を書くとき、見出しには見出しスタイル、本文には本文スタイルを当てますよね。あれと同じことを、タグという記号でやります。<h1>と書けば「ここは大見出しです」、<p>と書けば「ここは段落です」という意味になります。

重要なのは、HTMLが意味を伝える担当だという点です。見た目はCSS、動きはJavaScriptが担当します。HTMLで見た目を作ろうとすると、この分担が崩れます。

よくある書き方（Before）

<div class="title">旧車図鑑</div>
<div class="list">
  <div class="item">
    <div class="name">スカイライン GT-R</div>
    <div class="text">1969年発売。</div>
  </div>
</div>

見た目はCSSでいくらでも作れます。問題は、このHTMLが何も意味を持っていないことです。

直した書き方（After）

<h1>旧車図鑑</h1>
<ul class="list">
  <li>
    <article>
      <h2>スカイライン GT-R</h2>
      <p>1969年発売。</p>
    </article>
  </li>
</ul>

なぜそうなるか

HTMLは「見た目を作る言語」ではなく「文書の構造を説明する言語」です。構造が正しく書かれていると、次の3者が正しく読めます。

• 検索エンジン — 何が見出しで、何が本文かを判断できる
• スクリーンリーダー — 見出しだけを拾って読み上げ、目の見えない人がページを移動できる
• 未来の自分と同僚 — div.item の中身を読まなくても、記事の繰り返しだと分かる

覚えるタグはそう多くありません。まずはこれだけ。

特に事故が多いのが最後の button です。<div onclick="..."> はキーボードで操作できず、Tabキーで選べません。クリックできるものは button か a にする、と覚えてください。

手を動かす課題

好きな題材で、一覧ページのHTMLを書いてください。CSSはまだ書きません。条件は3つです。

1. h1 はページに1つだけ
2. 一覧は ul と li で組む
3. div は「意味はないがCSSのために囲みたい」場所だけに使う

書けたら、Chromeの拡張機能「HeadingsMap」でアウトラインを見てください。見出しがきれいな階層になっていれば成功です。

次回はCSSの基礎です。このHTMLに、崩れないレイアウトを与えます。

今回の学び

まず、見た目はCSSでいくらでも作れるということ。だからHTMLの良し悪しは見た目では判定できません。判定できるのは、CSSを全部外したときに文書として読めるかどうかでした。

次に、構造は3者に向けて書いていること。検索エンジン、読み上げソフト、そして未来の自分と同僚です。3者とも、書いた本人がその場で見ている画面とは違うものを見ています。

そして、クリックできるものはbuttonかaにすること。これだけは例外なしで覚えてよい規則です。見た目が同じでも、キーボードで操作できるかどうかが変わります。

技術を1つずつ順番に勉強しても、「で、これいつ使うの」が解けないまま終わることがあります。

この連載は逆から進みます。小さなアプリを1つ決めて、それを毎回作り直しながら必要な技術に出会っていくやり方です。

そもそもフロントエンドエンジニアとは

ひとことでいうと、ユーザーが目で見て指で触る部分を作る人です。

Webサービスは大きく2つに分かれます。画面を作る「フロントエンド」と、データを保管・計算する「バックエンド」。レストランに例えるなら、フロントエンドはホールと内装、バックエンドは厨房です。料理そのものは厨房が作りますが、お客さんの体験を決めるのはホールでもあります。

だから、技術力と同じくらい「見やすいか」「押しやすいか」が仕事の評価に直結します。この連載は、その両輪を扱います。

最終回に手元に残るもの

この連載を最後まで進めると、こういうものが自分のURLで動いています。

• 一覧ページ（検索・絞り込みつき）
• クリックすると開く詳細ページ
• データはAPIから取得。読み込み中・データなし・通信失敗の表示も用意
• スマホでもPCでも崩れない
• GitHubに履歴が残り、pushすると自動で本番に反映される

「チュートリアルを写経したもの」ではなく、仕様を自分で説明できるアプリです。面接でもレビューでも、これ1つあれば話が持ちます。

なぜ一覧と詳細なのか

地味に見えますが、実務のWebアプリはほとんどこの形の組み合わせです。商品一覧と商品ページ、記事一覧と記事ページ、管理画面の一覧と編集画面。

そして、この小さなアプリを作る過程で、フロントエンドエンジニアに求められる技術がひと通り登場します。逆に言えば、技術を1つずつバラバラに学んでも「で、これいつ使うの？」が解けません。同じアプリを毎回作り直しながら進むのが、この連載のやり方です。

積み上げの順番

[土台]       HTML → CSS
[動かす]     JavaScript → DOM → API通信
[道具]       CLI → Git → Node/npm → TypeScript → React
[守る]       テスト → ネットワーク → パフォーマンス
[広げる]     バックエンド → クラウド → Docker
[仕事にする] デザインツール・CMS

上から順に進みます。下の段は上の段がないと理解できないので、飛ばさないでください。逆に、下の段を知らないことは今の時点で何の問題もありません。

各パートのゴール

進め方

更新は週1回。各回はこの形で統一します。

1. この回で解ける困りごと
2. よくある書き方（Before）
3. 直した書き方（After）
4. なぜそうなるか
5. 手を動かす課題
6. 自己チェックリスト

読むだけだと必ず抜け落ちます。5の課題だけは必ずやってください。 逆に、解説が難しく感じたら読み飛ばして課題に進んで構いません。手が先、理解は後から追いつきます。

必要なもの

パソコン、Google Chrome、Visual Studio Code。これだけです。有料ツールは使いません。

次回はセマンティックHTMLです。divだらけで書いたページを、意味のあるタグに置き換えていきます。

本連載の構成は、セイト先生（AIプログラミングスクールSiiD）の動画「フロントエンドエンジニアに必要なスキル」を参考に、独自の学習順序で再構成しています。

今回の学び

まず、作るものを先に決めると、学ぶ順番が自動で決まるということ。技術の一覧から選ぼうとすると優先順位が付きませんが、1つのアプリを完成させると決めれば、次に必要なものはそのアプリが教えてくれます。

次に、一覧と詳細という形は、実務のほとんどを覆っていること。商品一覧と商品ページ、記事一覧と記事ページ、管理画面の一覧と編集画面。地味に見える題材ですが、ここに出てこない技術は当面要りません。

そして、下の段を知らないことは、いま何の問題でもないこと。順番に積む前提で書いているので、飛ばさないことだけを守ってもらえれば足ります。