ウェブ標準モデル

ウェブの略歴

1960 年代後半、米軍は ARPANET という通信網を開発しました。これは、パケット交換で動作し、 TCP/IP プロトコルスイートの最初の実装を特徴としているため、インターネットの前身と考えることができます。この2つの技術は、インターネットを構築するインフラの基礎を形成しています。

1980 年、ティム・バーナーズ=リー（以下、TimBL）は、異なるノード間のリンクという概念を取り入れた ENQUIRE というノートブックプログラムを書きました。聞き覚えはありませんか？

1989 年になると、 TimBL は Information Management: A Proposal とハイパーテキストを CERN で書きました。この 2 つの出版物は一緒になって、ウェブがどのように動作するかの背景を提供したのです。この 2 つの出版物は、ウェブがどのように機能するかの背景を示したもので、かなりの関心を呼び、 TimBL の上司はグローバルなハイパーテキストシステムを構築することを許可しました。

1990 年から 91 年にかけて、 TimBL は World Wide Web（通常はウェブと呼ばれる）の最初のバージョンを実行するために必要なすべてのものを作成しました。 HTTP、HTML、WorldWideWebと呼ばれる最初のウェブブラウザー、ウェブサーバー、そして見るためのいくつかのウェブページです。

1994 年、TimBL は、さまざまな企業の代表者が集まり、ウェブ技術の構築に共同で作業する組織である World Wide Web Consortium (W3C) を設立しました。W3C は、HTML や HTTP といった既存のウェブ技術の標準化と改良に取り組むとともに、CSS や JavaScript といった新しい技術の開発にも力を注ぎました。特に CSS と JavaScript は、ウェブにスタイル設定やインタラクティブ性を与える上で不可欠であり、今日の私たちが知るようなウェブの姿を作り上げる上で重要な役割を果たしました。

それからの数年間で、ウェブは爆発的に普及し、複数のブラウザーがリリースされ、何千ものウェブサーバーが設定され、何百万ものウェブページが作成されるようになったのです。他の標準化団体も現れ、ウェブ技術のさまざまな側面の標準化を支援するようになりました。

ウェブ標準

ウェブ標準は、私たちがウェブサイトを構築するために使用する技術です。これらの標準は、仕様書と呼ばれる長い技術文書として存在し、この技術がどのように動作すべきかを詳細に記述しています。これらの文書は、記述されている技術の使い方を学ぶにはとても役に立ちません（MDN Web Docs のようなサイトがあるのはこのためです）。その代わりに、ソフトウェア技術者がこれらの技術を（通常はウェブブラウザーで）実装するために使用するよう意図されています。

標準化団体とプロセス

ウェブ標準は、標準化団体によって作成されます。標準化団体とは、さまざまな技術企業の代表者を招集し、あらゆる場合に対応できるよう、技術がどのように機能すべきかについて合意を形成する機関のことです。

W3C は最もよく知られたウェブ標準化団体ですが、それ以外にもいくつかあります。

• WHATWG が保守している HTML Living Standard では、 HTML （すべての HTML 要素とそれに関連する API、およびその他の周辺技術）を実装するためにどうすればよいかは正確に記述されています。
• TC39 および ECMA は、現行の JavaScript の基盤となっている ECMAScript の標準を指定し、公開しています。
• Khronos は、WebGL などの三次元グラフィック関連の技術を公開しています。

標準が作成される一連のプロセスは、深く複雑なものになることがあります。しかし、独自のウェブ技術機能を作成したいのでない限り、その大部分を理解する必要はありません。新しい技術に関するディスカッションに参加したり、フィードバックを提供したりしたい場合は、通常、関連するメーリングリストやその他の議論の場に参加すれば十分です。標準に関する議論は公開の場で行われるため、「オープン」標準と呼ばれるのです。

ここでは、まず標準を策定するプロセスがどのように機能するかについて、概要を説明します。

1. 誰かが、開発者の作業を楽にする新しいウェブ標準機能の必要性に気づきます。例えば、ウェブのユーザーインターフェイスでよく使われる共通のパターンがあるものの、その実装が面倒な場合などです。専用の CSS 機能があれば、はるかに簡単になります。その「誰か」は、個人の開発者でも、大手テクノロジー企業に勤めるエンジニアでも、誰でもあり得ます。

2. その人物は、他の開発者やブラウザーエンジニアらとこの機能について議論し、その実装に向けた関心を集め始めます。通常、その機能の必要性や動作原理を説明する解説文書を作成し、実際にその機能がどのように動作するかを示すコードデモを作成します。

3. その機能に対する関心が十分に高まった場合、関連する標準化団体のワーキンググループ内で正式にディスカッションが行われます。例えば、CSS の機能については通常、CSS ワーキンググループ (WG) によって議論されます（詳細や沿革については、CSS Working Group の Wikipedia ページ^(英語)も参照してください）。新しいウェブ技術が受け入れられる前には、それがウェブにとって有益であることを確認するために厳格な評価が行われます。例えば、セキュリティ上の問題を引き起こさないこと、他のウェブ技術とのアクセシビリティと相互運用性が確保されていること、そして特許に頼っていないことなどが確認されます。

4. この機能を検証するために、いくつかのことが現れます。これらの点はすべて、ポイント 3 とほぼ同時に、あるいはそれ以前に現れる可能性があります（ブラウザーベンダーは、独占的仕様や非標準の機能を実装し、その後で標準化を図ろうとする場合があるためです）。

   1. 1 社以上のブラウザーベンダーが、この新しい機能の実験版を実装します。この機能は多くの場合、デフォルトで無効になっていますが、テストを行ってフィードバックを提供したいユーザーは有効にすることができます。
   2. 同時に、ワーキンググループのメンバーがこれを技術仕様に追加することで、ブラウザベンダーが一貫して実装できるようになります。
   3. 同時に、他のブラウザーベンダーからもフィードバックを求め、この提案に対してどのような課題があるか、また実装される可能性がどの程度あるかを確認する予定です。これらは Standards positions と呼ばれます。例えば、Mozilla の標準化に関する立場を参照してください。
   4. 同時に、関係者は、その機能が仕様通りに動作することを実証するために、一連の包括的なテストを作成します。

5. 最終的に、問題がなければ、この機能はすべてのブラウザーに実装され、ウェブサイトを作成する際に使用できるようになります。

特定の標準化団体の手続きに関する詳細情報は、以下を参照してください。例えば、次のようなものがあります。

• W3C Process Document
• WHATWG — Working Mode
• The TC39 Process

ウェブ標準の主要原則

ウェブを、関わる価値のある固有で期待感のある業界たらしめている基本原則は、以下の通りです。

• 貢献するにも利用するにもオープンであり、したがって特許で保護されておらず、単一の民間企業によって支配されていません。
• アクセシビリティと相互運用性を備えています。
• ウェブを壊しません。

これらについて、それぞれのことをもう少し詳しく見ていきましょう。

「オープン」標準

TimBL と W3C が当初から合意していたウェブ標準の重要な側面の一つは、ウェブ（とウェブ技術）は投稿も使用もオープンであるべきだということです。つまり、これらは無料で貢献・利用できるものであり、特許やライセンスによる制約を受けないということです。これは重要な点です。もしウェブ技術が機能するために特許やライセンスの対象となる技術に依存している場合、特許権者やライセンス所有者は、その技術を実装するブラウザーベンダーに対して多額の費用を請求する可能性があり、そのコストは最終的にブラウザーユーザーに転嫁されてしまうからです。

また、ウェブ技術は、さまざまな企業が協力してオープンに作成されるため、一企業が独占的に制御することができないことを意味しており、これは実に良いことです。一企業が突然、ウェブ全体を有料にすると決めたり、新しいバージョンの HTML をリリースして、誰もがウェブサイトを作り続けるために購入しなければならないようにしたり、さらに悪いことに、もう興味がないと判断してウェブサービスを停止してしまうようなことは避けなければなりません。

オープン標準により、ウェブは自由に利用できる公共のリソースであり続け、誰でも無料でウェブサイトを作成するためのコードを記述でき、また誰でも標準作成に関わることができます。

アクセシビリティと相互運用性

ウェブおよびブラウザーは本質的に、障害のある人々もウェブコンテンツにアクセス可能となるよう設計されています。当初、これはあらゆる状況を問わず、誰もが情報にアクセスすることができる「偉大な平等化者」として構想されていました。例えば次のようなことが挙げられます。

• マウスやポインティングデバイスを使用できない人は、キーボードを使ってウェブサイトを操作することができます。
• 視覚障害のある人は、コンテンツを拡大表示したり、スクリーンリーダーと呼ばれるプログラムを使って、コンテンツを読み上げてもらったり、操作方法を分かりやすく説明してもらったりすることができます。

さらに、ウェブ技術は相互運用性を備えるよう意図されています。ウェブ技術は公開された標準に基づいて実装されているため、ブラウザーは指定された入力（例えば、HTML、CSS、またはJSコード）に対して同じレンダリング結果を返す必要があります。言い換えれば、ウェブサイトは複数のブラウザー間で一貫して動作するはずです。

ウェブを壊さない

オープンウェブ標準の分野でよく耳にするもう一つのフレーズに、「ウェブを壊すな (don't break the web)」というものがあります。この考え方の背景には、新しいウェブ技術はそれ以前の技術と下位互換性を保つべきであり、そうすることで既存のウェブサイトが以前と同じように動作し続けるという理念があります。

ウェブブラウザーのベンダーは、新しいウェブ技術を実装する際、レンダリングや機能に違いが発生しないよう配慮すべきです。そうしなければ、ユーザーがウェブサイトが壊れたと誤解し、結果として別のブラウザーを試してしまう恐れがあるからです。

最近のウェブ技術の概要

ウェブ開発者になりたいのであれば、習得すべき技術は数多くあります。この章では、それらを簡単に説明します。

HTML、CSS、JavaScript

HTML、CSS、JavaScript はウェブサイトを構築するために使用する三大技術です。これらは前回のモジュールでも取り上げましたが、改めておさらいすると、

• ハイパーテキストマークアップ言語、すなわち HTML は、内容に意味（セマンティクス）と構造を与えるために、内容を包む（マークアップする）さまざまな要素からなるマークアップ言語です。
• Cascading Style Sheets (CSS) は、 HTML にスタイルを適用するために使用されるルールベースの言語で、例えば、テキストや背景色を設定したり、境界線を加えたり、物をアニメーション化したり、ページを特定の方法でレイアウトしたりすることができます。
• JavaScript は、動的なスタイルの切り替えから、サーバーからの更新の取得、複雑な三次元グラフィックに至るまで、ウェブサイトに対話性を追加するために使用されるプログラミング言語です。
  • 同時に、JavaScript と併せて API という用語も耳にするでしょう。これはアプリケーションプログラミングインターフェイスの略です。JavaScript API とは、JavaScript の上に構築された機能のことで、これにより、より複雑なコードや、コンピューター上のその他の機能（ウェブカメラやマイクなどのハードウェア機器など）を、扱いやすい方法で制御することができるのです。
  • 家に例えると、 JavaScript は炊飯器、テレビ、電子レンジ、ドライヤーなどです。家に便利な機能を与えるものです。

let pElem = document.querySelector("p");
pElem.textContent = "テキストを変更しました。";

その他のウェブ技術

ウェブ上ではそれ以外にもさまざまな技術が使用されています。

• HTTPは、前述の通り、クライアントとサーバー間の通信に用いられます。
• SVG は、ベクターグラフィックスを生成したり編集したりするためのものです。
• MathML は、数式を記述するものです。

とはいえ、HTML、CSS、JavaScript は学ぶべき技術の中で群を抜いて重要であるため、この学習経路では主にこれらに焦点を当てていきます。

ツール

ウェブページの作成で使用される標準的な基礎技術（HTML、CSS、JavaScript など）について学んだら、今度は作業を簡単にしたり効率化したりするための様々なツールに出会うようになります。例えば、以下のようなものが挙げられます。

• 開発者ツールは、最近のブラウザー内にあり、コードのデバッグに使用することができます。
• テストツールは、コードが意図したとおりに動作しているかどうかをテストすることができます。
• ライブラリーやフレームワークは、JavaScript 上に構築されており、ある種のウェブサイトをすばやく効果的に構築することができます。
• いわゆるリンターやフォーマッターは、コーディングスタイルに関する一連のルールに基づき、コードを見ていき、そのルールに従うようにコードを修正します。このコースの前の章で紹介した Prettier は、フォーマッターの一例です。

サーバーサイドの言語とフレームワーク

HTML、CSS、JavaScriptは、フロントエンド（またはクライアントサイド）言語です。これは、ユーザーが使用できるウェブサイトのフロントエンドを生成するために、ブラウザーで使用されることを意味しています。

一方、バックエンド（サーバーサイド）言語と呼ばれるものもあります。これは、サーバー上で実行され、その結果をブラウザーに送って表示させる言語です。サーバーサイド言語の代表的な使用方法は、データベースからデータを取り出して、そのデータを含む HTML を生成し、その HTML をブラウザーに送信してユーザーに表示させることです。

サーバーサイドフレームワークと言語の例としては、ASP.NET (C#)、Django (Python)、Laravel (PHP)、Next.js (JavaScript) などが挙げられます。

これらの技術は「ウェブ標準」とは見なされていません。これらは、W3C や WHATWG といった組織のウェブ標準策定プロセスとは別の組織によって開発されていますが、その中には、同様のオープンなプロセスを持っているものもあります。

静的と動的

クライアントサイド言語とサーバーサイド言語は、多くの場合静的と動的という方法でも説明されます。

• プレーンな HTML ファイルがサーバー上に格納されています。リクエストされた場合、そのファイルは変更されることなくクライアントに配信され、ブラウザーによってレンダリングされます。内容が変化しないため、「静的」と呼ばれます。
• サーバーサイドのコード（例えば、Python スクリプトや ASP.NET ページなど）がデータを含む HTML を生成し、その HTML をクライアントに返す場合、HTML の内容はサーバーサイドのコードの動作に応じて変化します。そのため、これは「動的」と呼ばれます。

静的コードと動的コードという概念の間には、多くの場合多少の重複が見られます。サーバーサイド言語では通常、テンプレートファイル内にHTML構造を定義しますが、これらは主に静的な HTML であり、挿入する必要があるデータに応じて変化する特別な動的な部分がいくつか含まれているのが一般的です。

ウェブのベストプラクティス

これまで、ウェブサイトを構築するために使用する技術について簡単に説明してきました。それでは、ウェブ開発者が、できるだけ多くの人々が自分のウェブサイトを利用できるようにするために一般的に採用しているベストプラクティスについて議論しましょう。

ウェブ開発をするとき、不確実性の主な原因は、それぞれのユーザーがウェブサイトを見るためにどのような技術の組み合わせを使用するかわからないということから発生します。

• ユーザー 1 は、画面の内側が狭い iPhone で見ているかもしれません。
• ユーザー 2 は、ワイド画面のモニターを取り付けた Windows のノートパソコンで見ているかもしれません。
• ユーザー 3 は視覚障碍があり、スクリーンリーダーを使ってウェブページを読み、操作して対話している可能性があります。
• ユーザー 4 は、最新のブラウザーが動作しない、非常に古いデスクトップ機を使用している可能性があります。

ユーザーが何を使用するか正確には分からないので、防御的にデザインする必要があります。つまり、上記のユーザー全員が同じ経験を得られるとは限りませんが、上記のユーザー全員が使用できるように、可能な限り柔軟なウェブサイトを作成する必要があります。

学習を進める中で、いずれ下記のような概念に出くわすことになるでしょう。これらは、ウェブサイトが理想的に遵守すべきベストプラクティスを表しています。現時点では、これらについてあまり深く気にする必要はありません。このコースの大部分では、こうした概念を暗黙的に教えるよう心がけています。つまり、HTML、CSS、JavaScript を解説する際、例では可能な限り最善の手法に沿ったものにするということです。学習が進むにつれて、これらの分野についてより具体的な指導を受けることになるでしょう。

プログレッシブエンハンスメント

すべてのユーザーに必須の機能を提供する最小限のユーザー体験を実現し、対応可能ないくつかのブラウザーでは、より優れたユーザー体験やその他の機能強化をその上に乗せていく。近年、ブラウザーは新しい機能をより一貫して対応するようになり、ユーザーのインターネット接続速度も向上し、データ通信量の制限も高くなっているため、多くの場合、プログレッシブエンハンスメントは重要ではないと見なされがちです。しかし、モバイルでの操作をスムーズにし、データ通信量を節約するために装飾を最小限に抑えたり、データ通信量をメガバイト単位で課金されるユーザーや、通信量制限のある接続環境のユーザーに対して、より軽量で低帯域幅の使い勝手を提供したりといった例を考えてみてください。

ブラウザー間の互換性

ウェブページが可能な限り多くの端末で動作するように努めることです。これには、すべてのブラウザーが対応している技術を使用すること、対応しているブラウザーでは、より良い使い勝手を提供すること（プログレッシブエンハンスメント）、古いブラウザーではより単純だが利用できる操作形態に戻るようコードを書くこと（いわゆるグレイスフルデグラデーション）などが含まれます。また、特定のブラウザーで何かがうまくいかないかどうかを確認するために多くのテストを行い、その失敗を修正するためにさらに多くの作業を行うことも必要です。

レイヤーの分離

コンテンツ (HTML)、スタイル (CSS)、動作 (JavaScript) を、一斉に同じ場所にまとめてしまうのではなく、それぞれ別のコードファイルに配置すること。これは、コードの管理や理解のしやすさ、チームワークや役割分担など、多くの理由からよい考えです。実際には、この分離が常に明確であるとは限りません。これは絶対的なルールというよりは、可能な限り目指すべき理想的な在り方です。

レスポンシブウェブデザイン

機能やレイアウトを柔軟にして、さまざまなブラウザーでの表示に自動的に対応できるようにすることです。例えば、デスクトップの広い画面のブラウザーではある方法でレイアウトされたウェブサイトが、携帯電話のブラウザーではよりコンパクトな単一列のレイアウトで表示されるような方法です。ブラウザーウィンドウの幅を調整して、サイトのレイアウトがどう変わるか確認してみてください。

パフォーマンス

ウェブサイトを可能な限りすばやく読み込むだけでなく、ユーザーがイライラして別の場所に行ってしまわないように、直感的で簡単に利用できるようにすることです。

国際化

自身の言語とは異なる文化を持つ人々が、ウェブサイトを利用できるようにすることです。ここには、技術的な配慮（右書き、あるいは縦書きの言語でも問題なく動作するようにレイアウトを変更するなど）と、人間的な配慮（文化の違いがあってもテキストを理解しやすいように、平易で俗語を避ける言葉遣いを使用するなど）があります。

プライバシーとセキュリティ

この 2 つの概念は関連のあるものですが、異なるものです。プライバシーとは、人々が個人的にビジネスを行うことを許可することであり、スパイ行為や必要以上のデータ収集を行わないことを指します。セキュリティとは、悪意のあるユーザーがあなたやあなたのユーザーから情報を盗むことができないように、安全な方法であなたのウェブサイトを構築することを指します。

• 前のページ
• Overview: ウェブ標準
• 次のページ