ブラウザの共通仕様と独自仕様はどう決まる？
昔のWebは、同じページを開いてもブラウザごとに表示や動作がずれることが珍しくありませんでした。いま比較的平和にHTML/CSS/JavaScriptを書けるのは、共通仕様を作って、複数ブラウザでそろえる努力が続いているからです。ここでは「なぜ共通仕様が必要なのか」と「独自仕様はどこで生まれるのか」を整理します。
なぜ共通仕様が必要なのか
共通仕様がないと、同じHTML/CSS/JavaScriptを書いてもブラウザごとに結果が変わり、作る側も使う側もかなり困ります。
困るポイント
- 同じマークアップでも、あるブラウザでは表示され、別のブラウザでは崩れる。
- サイト側がブラウザ判定だらけになり、分岐コードが増えて保守しづらくなる。
- 学ぶ側も「HTML/CSS/JSを覚える」だけでは足りず、ブラウザごとの癖を個別に覚える必要が出る。
- 拡張機能、スクリーンリーダー、自動テスト、クローラなど周辺ツールも挙動を合わせにくくなる。
共通仕様があると何がうれしい？
- ブラウザベンダーが違っても、基本の振る舞いを同じ前提で実装できる。
- サイト制作者は「この仕様に従えばおおむね同じ意味で動く」と期待しやすい。
- テストやドキュメントも共通化しやすく、相互運用性の改善が回しやすい。
誰が何を決めているのか
「ブラウザ1社が全部決めている」わけではありません。領域ごとに中心となる団体やプロセスが分かれています。
主な担当の整理
| 領域 | 主な団体 | 内容と注意点 |
|---|---|---|
| HTML / DOM / Fetch / URL | WHATWG | HTML Living Standard や DOM / Fetch など、ブラウザが共通で持つ基盤的な仕様。 Living Standard 方式で継続更新。実装と仕様の歩調をそろえやすい。 |
| CSS | W3C / CSSWG | CSSの構文、レイアウト、色、アニメーションなどの仕様。 CSSは1冊で完結せず、モジュール単位で策定される。 |
| JavaScript 言語仕様 | TC39 | ECMAScript の文法、標準組み込みオブジェクト、言語機能。 ブラウザだけでなく Node.js なども関係する。 |
| HTTP / URI / TLS など通信系 | IETF | HTTPやTLS、URIの一般構文など。ブラウザのURL解析はWHATWGのURL Standardが扱う。 RFCとして公開され、ブラウザ以外の実装者も広く参照する。 |
ブラウザベンダーの立ち位置
- Google, Apple, Mozilla, Microsoft などの実装者は、仕様策定の議論にも参加しつつ、自分たちで実装も進める。
- つまり「仕様を読む人」と「仕様を書く人」がかなり近い世界です。紙だけ立派で実装ゼロ、は嫌われやすいですね。
共通仕様はどう育っていくか
完成品の仕様が天から降ってくるというより、提案・議論・実装・テストを往復しながら固まっていくことが多いです。
ざっくりした流れ
- 課題や新機能の提案が出る。
- 草案化して、用語・構文・失敗時の扱い・互換性を詰める。
- ブラウザが実験実装やフラグ付き実装を行う。
- 複数実装で相互運用できるかを確認する。
- Web Platform Tests（WPT）などの共通テストを整備する。
- 仕様上の段階と、各ブラウザで実際に使えるかを分けて確認する。実験が撤回されたり、仕様化後も未実装だったりする場合がある。
WHATWG の流れ
WHATWGは Living Standard を採るので、「HTML 6」みたいに区切って凍結するより、継続的に更新していく形です。実装と議論が近く、現実のブラウザ挙動を反映しやすいのが特徴です。
IETF の流れ
IETFは Internet-Draft を議論し、合意形成を経て RFC として公開します。HTTPのようにブラウザ以外のサーバー、CDN、プロキシも巻き込む領域では、この整理された文書文化がかなり効きます。
TC39 の流れ
TC39の提案はStage 0、1、2、2.7、3、4の段階を進みます。Stage 2.7では仕様をテスト等で検証し、Stage 3で実装経験を集めます。Stage 4にはTest262を通る互換性のある2実装などが必要です。段階だけで、利用者のブラウザに機能があるとは判断できません。
WPT の役割
WPTはブラウザ間で共通に実行するテスト群です。wpt.fyiでは結果を比較できますが、通過したケースの証拠であり、全機能・全環境が完全互換という保証ではありません。ECMAScript言語自体にはTest262という別のテスト群もあります。
独自仕様はどこに出やすいか
独自仕様というと少し身構えますが、必ずしも悪者ではありません。標準化前の実験、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スニッフィングより機能検出を優先する。ただしAPIの存在だけで、権限付与や処理成功までは保証されない。
- 「使えるか」だけでなく、「標準化済みか」「複数エンジンで動くか」を見る。
- 独自拡張を使う場合は、効かなくても致命傷にならない設計にしておく。
- ブラウザ差分を見つけたら、バグなのか、仕様差なのか、OS制約なのかを切り分ける。
まとめ
共通仕様は、Webを「どのブラウザでもある程度同じ前提で使える」ようにするための土台です。一方で独自仕様は、実験、差別化、OS事情、安全性の判断から生まれます。大事なのは、独自か共通かを感覚で決めつけず、「誰の仕様で、どこまで固まっているか」を確認することです。
仕様・公式資料
HTML / URL / Compatibility Standard / CSSWG / TC39 process / WPT
Webを支える組織 / UA文字列と判定の限界