/
384.txt
67 lines (55 loc) · 4.19 KB
/
384.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
[1] [CITE@ja[モンキーパッチ - Wikipedia]]
( ([TIME[2013-11-24 16:54:40 +09:00]] 版))
<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] [CITE[Monkey patch — Anne’s Blog]]
( ([TIME[2014-02-13 11:39:23 +09:00]] 版))
<http://annevankesteren.nl/2014/02/monkey-patch>
[3] [CITE@en[Where is the spec? · Issue #481 · w3c/webcomponents]]
([TIME[2016-04-26 18:31:29 +09:00]] 版)
<https://github.com/w3c/webcomponents/issues/481>
[4] [CITE@en['''['''css-ui-4''']''''''['''css-sizing''']''' Moving box-sizing to the right spec · Issue #1906 · w3c/csswg-drafts]]
([TIME[2017-12-08 15:44:56 +09:00]])
<https://github.com/w3c/csswg-drafts/issues/1906>
[5]
[CITE@en[The WHATWG Blog — Retro-specifying fetch/performance]],
March 17th, 2022,
[TIME[2023-10-17T06:07:12.000Z]], [TIME[2023-10-17T07:36:54.084Z]] <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箇所ですべての仕様案、すべての議論を追いやすくするという動機もあるようです。