ブラウザの共通仕様と独自仕様はどう決まる？
昔のWebは、同じページを開いてもブラウザごとに表示や動作がずれることが珍しくありませんでした。いま比較的平和にHTML/CSS/JavaScriptを書けるのは、共通仕様を作って、複数ブラウザでそろえる努力が続いているからです。ここでは「なぜ共通仕様が必要なのか」と「独自仕様はどこで生まれるのか」を、調べた範囲でざっくり整理します。
なぜ共通仕様が必要なのか 🌍
共通仕様がないと、同じHTML/CSS/JavaScriptを書いてもブラウザごとに結果が変わり、作る側も使う側もかなり困ります。
困るポイント
- 同じマークアップでも、あるブラウザでは表示され、別のブラウザでは崩れる。
- サイト側がブラウザ判定だらけになり、分岐コードが増えて保守しづらくなる。
- 学ぶ側も「HTML/CSS/JSを覚える」だけでは足りず、ブラウザごとの癖を個別に覚える必要が出る。
- 拡張機能、スクリーンリーダー、自動テスト、クローラなど周辺ツールも挙動を合わせにくくなる。
共通仕様があると何がうれしい？
- ブラウザベンダーが違っても、基本の振る舞いを同じ前提で実装できる。
- サイト制作者は「この仕様に従えばおおむね同じ意味で動く」と期待しやすい。
- テストやドキュメントも共通化しやすく、相互運用性の改善が回しやすい。
誰が何を決めているのか 📚
「ブラウザ1社が全部決めている」わけではありません。領域ごとに中心となる団体やプロセスが分かれています。
主な担当の整理
| 領域 | 主な団体 | 何を決めるか | 補足 |
|---|---|---|---|
| HTML / DOM / Fetch などWeb基盤 | WHATWG | HTML Living Standard や DOM / Fetch など、ブラウザが共通で持つ基盤的な仕様。 | Living Standard 方式で継続更新。実装と仕様の歩調をそろえやすい。 |
| CSS | W3C / CSSWG | CSSの構文、レイアウト、色、アニメーションなどの仕様。 | CSSは1冊で完結せず、モジュール単位で策定される。 |
| JavaScript 言語仕様 | TC39 | ECMAScript の文法、標準組み込みオブジェクト、言語機能。 | ブラウザだけでなく Node.js なども関係する。 |
| HTTP / URI / TLS など通信系 | IETF | HTTPや関連ヘッダー、URLまわり、通信プロトコルの標準。 | RFCとして公開され、ブラウザ以外の実装者も広く参照する。 |
ブラウザベンダーの立ち位置
- Google, Apple, Mozilla, Microsoft などの実装者は、仕様策定の議論にも参加しつつ、自分たちで実装も進める。
- つまり「仕様を読む人」と「仕様を書く人」がかなり近い世界です。紙だけ立派で実装ゼロ、は嫌われやすいですね。
共通仕様はどう育っていくか 🔧
完成品の仕様が天から降ってくるというより、提案・議論・実装・テストを往復しながら固まっていくことが多いです。
ざっくりした流れ
- 課題や新機能の提案が出る。
- 草案化して、用語・構文・失敗時の扱い・互換性を詰める。
- ブラウザが実験実装やフラグ付き実装を行う。
- 複数実装で相互運用できるかを確認する。
- Web Platform Tests（WPT）などの共通テストを整備する。
- 複数ブラウザで安定し、事実上の共通仕様として定着する。
WHATWG の流れ
WHATWGは Living Standard を採るので、「HTML 6」みたいに区切って凍結するより、継続的に更新していく形です。実装と議論が近く、現実のブラウザ挙動を反映しやすいのが特徴です。
IETF の流れ
IETFは Internet-Draft を議論し、合意形成を経て RFC として公開します。HTTPのようにブラウザ以外のサーバー、CDN、プロキシも巻き込む領域では、この整理された文書文化がかなり効きます。
TC39 の流れ
TC39では ECMAScript の提案が stage を進みます。アイデア段階から、仕様テキスト・受け入れテスト・複数実装の確認を経て成熟していくので、「面白そう」だけで急に標準になるわけではありません。
WPT の役割
仕様文だけだと解釈が割れることがあります。WPTは WHATWG / W3C 系仕様などに対する共通テスト群で、「このケースは本当に同じ結果になるか」を実装レベルで確認する場として重要です。
独自仕様はどこに出やすいか 🧪
独自仕様というと少し身構えますが、必ずしも悪者ではありません。標準化前の実験、OS連携、実装最適化など、差が出る理由はいろいろあります。
独自になりやすいポイント
| 独自になりやすい領域 | 例 | なぜ差が出るか | 開発側の見方 |
|---|---|---|---|
| ベンダープレフィックス付きCSS | -webkit- など | 標準化前の実験機能や、互換性維持のため古い記法を残している。 | まず標準プロパティを確認し、プレフィックス付きは補助扱いにする。 |
| 独自CSS拡張 | ::-webkit-scrollbar など | UI部品の見た目調整が標準化されきっていない、または各エンジンの都合が強い。 | 効けば便利だが、他ブラウザで無視される前提で使う。 |
| 実験API・フラグ付き実装 | 新しいWeb APIの試験実装 | 仕様が固まる前に、実装してフィードバックを集めたい。 | 本番依存は避け、段階や複数実装の有無を確認する。 |
| OS統合や制約に絡む差分 | 省電力、メディア再生、通知、バックグラウンド制御など | OSの権限モデル、安全性、電池、ハードウェア事情が違う。 | 「仕様どおり動かない」ではなく、環境制約を先に疑う。 |
| Web標準の外側のUI | アドレスバー、設定画面、PDFビューア、開発者ツール | そもそもWebページ向け標準ではなく、ブラウザ製品としての差別化領域。 | 見た目やメニュー配置の差は仕様差ではなく製品差として切り分ける。 |
独自仕様が生まれる理由
- 新機能をいきなり全ブラウザ共通にするのは難しいので、まず試す場所が必要。
- セキュリティやプライバシーの方針は、ベンダーごとに慎重さが少しずつ違う。
- モバイルOSやデスクトップOSとの統合部分は、下の土台が同じではない。
調べるときの見方と実務メモ 🔍
「このAPI使える？」だけを見ると判断を誤りやすいです。仕様の持ち主と成熟度を先に見ると、だいぶ整理しやすくなります。
見る順番の目安
- まず、その仕様のオーナーが WHATWG / W3C / TC39 / IETF のどこかを確認する。
- 次に仕様本文を見て、前提条件や未定義部分がないかを押さえる。
- WPT があるなら、相互運用テストがどう整備されているかを見る。
- MDN で実装状況や注意点を補助的に確認する。
- 必要なら各ベンダーのブログ、Intent、実装メモを読む。
実務での注意
- UAスニッフィングより feature detection を優先する。
- 「使えるか」だけでなく、「標準化済みか」「複数エンジンで動くか」を見る。
- 独自拡張を使う場合は、効かなくても致命傷にならない設計にしておく。
- ブラウザ差分を見つけたら、バグなのか、仕様差なのか、OS制約なのかを切り分ける。
まとめ
共通仕様は、Webを「どのブラウザでもある程度同じ前提で使える」ようにするための土台です。一方で独自仕様は、実験、差別化、OS事情、安全性の判断から生まれます。大事なのは、独自か共通かを感覚で決めつけず、「誰の仕様で、どこまで固まっているか」を確認することです。