[1] モンキーパッチ - Wikipedia ( ( 版)) http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%B3%E3%82%AD%E3%83%BC%E3%83%91%E3%83%83%E3%83%81
[2] Monkey patch — Anne’s Blog ( ( 版)) http://annevankesteren.nl/2014/02/monkey-patch
[3] Where is the spec? · Issue #481 · w3c/webcomponents ( 版) https://github.com/w3c/webcomponents/issues/481
[4] [css-ui-4][css-sizing] Moving box-sizing to the right spec · Issue #1906 · w3c/csswg-drafts () https://github.com/w3c/csswg-drafts/issues/1906
[5] The WHATWG Blog — Retro-specifying fetch/performance, March 17th, 2022, , https://blog.whatwg.org/retro-specifying-fetch-performance
[6] >>5 Web Performance は現代ウェブ標準 (HTML5 世代およびそれ以後のウェブ標準仕様群) の中で CSP と並ぶ前時代的猿パッチの悪習を今に伝える負の遺産だったのですが、 CSP の方ではもう何年も前、日本でいうと平成の頃に解消されていました。 ところが Webperf の方はなんだかんだの事情があって令和4年まで引き伸ばされていて、 >>5 記事中で解説されるように実害が出ていましたし、 後に伸ばせば伸ばすほど、解消のために必要なエネルギーが増えていくという悪い状況だったのです。
[7] 猿パッチは悪だというのは現代ウェブ標準の世界では基本中の基本で、 それこそ HTML5 が WF2 & WA1 という猿パッチから始まって、 猿パッチをやめて「本体」に進化していくという歴史を経てきているのですけど、 初期の頃にはまだ猿パッチの弊害が業界でも十分に理解されていませんでしたし、 猿パッチが駄目だと言われても正規の方法でやるだけの環境がまだ整っていなかったんですね。
[8] Webperf の例でいうと Fetch がまだしっかり仕様化される前の段階から開発が始まっていましたし、 開発が一段落したあと猿パッチを本仕様に吸収していく業界の仕組みも未整備でした。
[9] 今では WICG なり個人やウェブブラウザー事業者の GitHub リポジトリーなりで開発を始める時点では猿パッチ形式の仕様案を用意して、 一通りの準備が終わって事業者間の一定の同意も得られたところで本仕様に猿パッチ部分を還元していくという作業フローが確立しています。
[10] この方法が回り始めたのが平成の終わり頃で、 CSP の他にも Fetch や HTML への追加機能 (猿パッチ) を開発しまくっていた WebAppSec 方面と WHATWG の協業がその走りでした。
[11] 外野から眺める分には、そんなやり方はしなくても WHATWG の本リポジトリーのブランチなり、 fork した git リポジトリーなりで作業して、 同意したらマージ、の方が作業も少なくて済むのではないか、 と思ってしまうのですが、 業界には業界のしがらみというか、 思惑みたいなものもあるみたいです。 他のグループのブランチで開発するよりも独立した WG の作業項目としてやる方が当事者にとって開発しやすいとか、 追加機能本体の他に説明も付加した仕様書がある方が説明しやすいとか、 新機能には機能名とそれを冠した仕様書がないと市場にアピールしづらいとか。
[12] また、 HTML, Fetch, CSS など関連する仕様が複数の仕様書や複数の団体にまたがっているケースも多いので、 開発初期段階では猿パッチを集約して1箇所ですべての仕様案、すべての議論を追いやすくするという動機もあるようです。