フロントエンド開発における「画面」と「ページ」の定義 - なぜビューポートという言葉を使うべきか

前回、reactの記事の中で、解決したかに思えたDOM問題。 DOMは分かりましたが、画面とページという新たな疑念が湧きました。

第二の違和感 - 「画面」と「ページ」の混同

ある日のレビューミーティング。

「この画面のデザインについて…」
「画面の構成を見直して…」
「画面のレイアウトが…」

この言葉を聞くたびに、私の中のイライラは増していきました。 なぜなら、「画面」は設計の対象にはならないからです。

画面とは、今このときにデバイスに表示されている可視部分のみを指します。 スクロールすれば変わってしまう、その時々の表示領域です。 Windowsでいえば、アプリケーションの表示領域のようなものです。

一方、設計やデザインの対象となるのは「ページ」です。 スクロールで見えない部分も含めた文書全体を指します。 私たちが作るべきなのは「ページのデザイン」であり、「ページの構成」なのです。

それ以上に我慢したのは…

「Excelで仕様書を作るな!!!」

平成か？お前らは平成か？どう見ても平成生まれのくせに、なぜExcelで仕様書を作るのか？ 令和ならMarkdownだ!!!!

と2年前までMS-Wordで仕様書を書いていた自分を棚に上げて、心の中で叫んでいました。

ちなみに、昭和はワープロで仕様書を書いていましたねえ…

Windowsアプリケーションで考えてみる

私はWin16の頃からVisual C++でアプリを開発してきたことがあって、どうしてもWindowsで話を考えたくなります。 ジジイなので勘弁してください。 え、X-Window？もちろん、嫌いじゃないデスよ。 ダイヤモンドトロンのX端末を30万円で購入したのは、いつの頃だったか…

この「画面」と「ページ」の違いを、より身近な例で考えてみましょう。 WindowsなどのデスクトップアプリケーションとWebブラウザを比較してみると、 とても分かりやすくなります。

例えば、Windowsアプリケーションで「表示の更新」と「アプリケーションの再起動」は、 まったく異なる操作ですよね。

Webブラウザでも同じことが言えます。

画面の更新（≒ Windowsの表示領域の更新）

• ウィンドウの中身だけを更新
• アプリケーションは起動したまま
• データや状態は保持される

// 特定の要素だけを更新する例
document.getElementById('status').textContent = '処理完了'

ページの再読み込み（≒ アプリケーションの再起動）

• すべてを最初から読み込み直す
• アプリケーションの状態がリセットされる
• メモリ上の変数なども初期化される

// ブラウザのページを完全に再読み込み
location.reload()

それぞれの用語が指すもの

この考え方をさらに発展させると、それぞれの用語が指す範囲がより明確になります。

「画面」が指すもの：

• 現在デバイスに表示されている可視部分のみ
• ビューポートとも呼ばれる
• スクロールすると変わる

// 現在の画面（ビューポート）の高さを取得
const viewportHeight = window.innerHeight

「ページ」が指すもの：

• 文書全体
• スクロールで見えない部分も含む
• レイアウトやコンテンツの全体構造

// ページ全体の高さを取得
const pageHeight = document.documentElement.scrollHeight

CSSでの指定:

.full-viewport {
	/* ビューポート（画面）の高さいっぱいに */
	height: 100vh; /* viewport height */
}

.half-viewport {
	/* ビューポートの半分の高さ */
	height: 50vh;
}

.full-viewport-width {
	/* ビューポートの幅いっぱいに */
	width: 100vw; /* viewport width */
}

画面という用語の歴史的遷移的考察

ちょっとまて、昔から論理座標系と物理座標系があったろうが！というツッコミはごもっともです。

画面(=SCREEN)ってなに？

実際の業務アプリケーションでは、

• ほとんどの場合、物理座標系だけが使用される
• ユーザーが見る「画面」と操作対象が1:1で対応

結果として「画面」が操作や設計の基本単位として定着しました。 これは技術的な制約というよりも、当時の一般的なユースケースを反映したものでした。

• 帳票出力のような定型的な業務
• フォーム入力中心の画面遷移型アプリケーション
• スクロールやウィンドウ分割があまり必要とされない使用状況

このような背景から、「画面」という用語は、

• 物理的な表示領域
• ユーザーの操作単位
• 設計の基本単位

という複数の意味を包含する言葉として使われるようになりました。

graph TB
    subgraph Physical[物理デバイス]
        SCREEN[SCREEN
        物理的な表示領域]
    end

    subgraph Logical[論理的な表示系]
        VIEW[VIEW
        論理的なビューポート]
        WINDOW[WINDOW
        論理座標系]
    end

    SCREEN -->|物理座標系| Physical_Coords[物理座標での描画]
    VIEW -->|論理座標系| Logical_Coords[論理座標での描画]
    WINDOW -->|座標変換| VIEW

    style Physical fill:#f5f5f5,stroke:#333,stroke-width:2px
    style Logical fill:#e1f5fe,stroke:#0277bd,stroke-width:2px

次回は、これらの概念が実際の設計ドキュメントやチーム開発にどのような影響を与えているのか、 そしてそれに対する具体的な解決策について考察します。 [続く]