├── README.ja.md
└── README.md
/README.ja.md:
--------------------------------------------------------------------------------
1 | The Extensible Web Manifesto
2 | ============================
3 |
4 | 私たち -[このマニフェストへの署名者](https://extensiblewebmanifesto.org/#signatories)- は、 Web 標準化団体が新しい機能の追加やその優先順位を決めるために取ってきた、旧来の方法を変えるべきだと主張します。これは、これから先の長い期間に渡って、 Web が健全であるために必要なことだと考えているからです。
5 |
6 | 第一の目標は、Web 標準仕様のエディタと Web 開発者の間で、しっかりとフィードバックのループがまわることです。
7 | 標準化が発展していくモデルとして、手順を重視しトップダウンで決定するモデルよりも、多くの有能な開発者によって駆動するモデルを選びます。
8 |
9 | ブラウザベンダは、基盤となるプラットフォームが持つ可能性を、低レベルの機能としてできる限り提供すべきです。
10 | 新しい高レベル API を JavaScript による実装をもとに議論できるように、土台を提供すべきです(すでに Mozilla の [X-Tags](http://www.x-tags.org/) や Google の [Polymer](http://www.polymer-project.org/) で行われています)。
11 | これにより、開発者は標準化に参加可能になり、ブラウザの外で議論が繰り返されることで、粗悪な API が定義されるのを防ぎます。
12 |
13 | 特に、 Extensible Web プラットフォームに対して、以下の方針を提唱します。
14 | * 標準化プロセスは、 Web プラットフォームに対するセキュアで効果的な ***新しい低レベルな機能*** の策定に注力すべきです。
15 | * Web プラットフォームは、 HTML や CSS などの ***既存の特徴を説明*** する低レベルな機能を提供することで、開発者がそれを理解し再現することが可能となるようにすべきです。
16 | * Web プラットフォームは、開発者が新しい高レベル API の開発・表現・テストを JavaScript で行い、それが標準化される前にくりかえし行えるようにすべきです。これは、 ***価値のあるサイクル*** を仕様策定者と開発者の間にもたらします。
17 | * 標準化プロセスは、これらの方針に従って ***優先順位づけ*** をすべきであり、そうなっていないものは、優先度を見直すべきです。
18 |
19 | ------
20 |
21 | ***新しい低レベルな機能*** の仕様化にフォーカスし、その観点から新しい機能を実装することで、
22 |
23 | * 新しいセキュリティの問題を抑制することができます。
24 | * ブラウザエンジンが、これから追加する API に影響するような、コア部分の最適化に注力できます。これにより、小さい実装コストで、より良いパフォーマンスを得ることに繋がります。
25 | * ブラウザベンダとライブラリ作者が、開発者のニーズにあった高レベル API としてのライブラリの開発を行えるようになります。
26 |
27 | ***低レベルな機能の視点から*** 既存の機能とこれから追加される新しい特徴を説明することは
28 | * 実装の複雑さの低減や、バグの減少に貢献します。
29 | * より多くの新機能のポリフィルを可能にします。
30 | * 新しい機能についての学習コストを減らします。学習に必要なコンテンツも、すでにプラットフォームにあるコンセプトをもとに作り直すことができます。
31 |
32 | 新しい機能の理解を簡単にし、それらをポリフィルすることは ***価値のあるサイクル*** をまわします。
33 | * 開発者は新しい API をより早く試し、仕様が固まる前にプラットフォームに対してフィードバックを送ることができます。
34 | * API を利用する開発者や、ライブラリを提供する作者によって、 API のミスはよりすばやく洗い出され、適切で重要なフィードバックをブラウザベンダやプラットフォームのデザイナに提供することができます。
35 | * ライブラリの作者は、新しい API を用いて知見をため、プラットフォームが進むべき道を示すことができます。
36 |
37 | 以下の方針に基づいて ***優先順位づけ*** することで、
38 | * (特に短期間の)標準化プロセスを解放し、セキュリティやパフォーマンスへの懸念や、新しいハードウェアなどプラットフォームレベルでしか追加しえない機能の標準化に注力できます。
39 | * Web 開発者とブラウザ由来のライブラリが、コストのかかる調査を主導できます。
40 | * すでに実世界で、実装され意味を成している新しい API があることで、長期に渡る標準化プロセスをシンプルかつ効率化します。
41 |
42 |
43 | もっと開発者がコードを書いて欲しいと考えています。それは、新しい形式を取り入れる上での標準化のボトルネックを取り除き、ライブラリとフレームワークの作者に、開発のために必要なツールを提供します。
44 |
45 | オープンな Web がそれを取りまく競合と競うためには、 Web 開発者の良いアイデアを、Web のインフラの一部とするためのはっきりとした手段が必要です。
46 |
47 | このマニフェストに賛同する人々
48 |
49 | * Brendan Eich
50 | CTO and SVP Engineering, Mozilla; Creator of JavaScript
51 |
52 | * Yehuda Katz
53 | Member, TC39, W3C TAG; Core Team, Ember.js, Rails
54 |
55 | * Alex Russell
56 | TC39, W3C TAG; Google Chrome Team
57 |
58 | * Brian Kardell
59 | Chair, Extensible Web Community Group, W3C
60 |
61 | * François REMY
62 | Co-founder, Extensible Web Community Group, W3C
63 |
64 | * Clint Hill
65 | Co-founder, Extensible Web Community Group, W3C
66 |
67 | * Marcos Caceres
68 | Co-founder, Extensible Web Community Group, W3C
69 |
70 | * Tom Dale
71 | Core Team, Ember.js
72 |
73 | * Anne van Kesteren
74 | Editor of standards, Architecture Astronaut at Mozilla
75 |
76 | * Sam Tobin-Hochstadt
77 | Member, TC39
78 |
79 | * Domenic Denicola
80 | Co-Editor, Promises/A+
81 |
82 | * Chris Eppstein
83 | Maintainer, Sass
84 |
85 | * Dave Herman
86 | Mozilla Research and TC39
87 |
88 | * Alan Stearns
89 | Member, CSSWG
90 |
91 | * Rick Waldron
92 | Member, TC39
93 |
94 | * Paul Irish
95 | Google
96 |
97 | * Ted Han
98 | Lead Developer, DocumentCloud
99 |
100 | * Tab Atkins
101 | Member, CSS WG; Google
102 |
103 | -----
104 |
105 | **関連エントリ**
106 | * [Extend the Web Forward](http://yehudakatz.com/2013/05/21/extend-the-web-forward/), by Yehuda Katz, このアイデアの詳細を解説したエントリ
107 | * [An Extensible Approach to Browser Security Policy](http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/), by Yehuda Katz, これらの方法を実践したアプリケーションとして、ブラウザの Content Security Policy の API デザインについての問題についての解説。
108 | * [Dropping the F-Bomb on Web Standards](https://briankardell.wordpress.com/2013/05/17/dropping-the-f-bomb/), by Brian Kardell, 開発者のコミュニティから出たアイデアや言語を、相互接続可能な標準にどう取り込むかについての実践的な議論。
109 | * [Bedrock](http://infrequently.org/2012/04/bedrock/), by Alex Russell, 2012年に、拡張可能な("レイヤリングされた")デザインにもとづくプラットフォームに関する、知見と哲学の詳細な調査。
110 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | The Extensible Web Manifesto
2 | ============================
3 |
4 | We—the undersigned—advocate a change to the approach that web standards committees use to create and prioritize new features. We believe that this is critical to the long-term health of the web.
5 |
6 | Our primary goal is to tighten the feedback loop between the editors of web standards and web developers. We prefer an evolutionary model of standardization, driven by the vast army of web developers, to a top-down model of progress driven by standardization.
7 |
8 | Browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible. They should seed the discussion of high-level APIs through JavaScript implementations of new features (as done in the cases of [Mozilla’s X-Tags](http://www.x-tags.org/) and [Google’s Polymer](http://www.polymer-project.org/)). This involves web developers in the process and by iterating outside of the browser, avoids the platform getting stuck with bad APIs.
9 |
10 | Specifically, we offer the following design principles for an Extensible Web Platform:
11 | * The standards process should focus on adding ***_new low-level capabilities_*** to the web platform that are secure and efficient.
12 | * The web platform should expose low-level capabilities that ***_explain existing features_***, such as HTML and CSS, allowing authors to understand and replicate them.
13 | * The web platform should develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a ***_virtuous cycle_*** between standards and developers.
14 | * The standards process should ***_prioritize efforts_*** that follow these recommendations and deprioritize and refocus those which do not.
15 |
16 | ------
17 |
18 | By focusing on standardizing ***_new low-level capabilities_***, and building new features in terms of them, we:
19 | * Contain new security surface area.
20 | * Allow optimizations in browser engines to focus on the stable core, which affects more APIs as they are added. This leads to better performance with less implementation effort.
21 | * Allow browser vendors and library authors to iterate on libraries that provide developer-friendly, high-level APIs.
22 |
23 | By explaining existing and new features ***_in terms of low-level capabilities_***, we:
24 | * Reduce the rate of growth in complexity, and therefore bugs, in implementations.
25 | * Make it possible to polyfill more of the platform's new features.
26 | * Require less developer education for new features. Educational materials can build off of concepts that are already in the platform.
27 |
28 | Making new features easy to understand and polyfill introduces a ***_virtuous cycle_***:
29 | * Developers can ramp up more quickly on new APIs, providing quicker feedback to the platform while the APIs are still the most malleable.
30 | * Mistakes in APIs can be corrected quickly by the developers who use them, and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.
31 | * Library authors can experiment with new APIs and create more cow-paths for the platform to pave.
32 |
33 | By ***_prioritizing efforts_*** that follow these principles, we:
34 | * Free up the standards process (especially in the short-term) to focus on features with security or performance concerns, and features that can only be added at the platform level, such as new hardware.
35 | * Allow web developers and browser-initiated libraries to take the lead in costly explorations.
36 | * Simplify and streamline the longer-term process of standardizing new APIs, which will already have implementations and significant real-world usage.
37 |
38 |
39 | We want web developers to write more declarative code, not less. This calls for eliminating the standards bottleneck to introducing new declarative forms, and giving library and framework authors the tools to create them.
40 |
41 |
42 | In order for the open web to compete with its walled competitors, there must be a clear path for good ideas by web developers to become part of the infrastructure of the web. We must enable web developers to build the future web.
43 |
44 |
45 | In support of these principles,
46 |
47 | * Brendan Eich
48 | CTO and SVP Engineering, Mozilla; Creator of JavaScript
49 |
50 | * Yehuda Katz
51 | Member, TC39, W3C TAG; Core Team, Ember.js, Rails
52 |
53 | * Alex Russell
54 | TC39, W3C TAG; Google Chrome Team
55 |
56 | * Brian Kardell
57 | Chair, Extensible Web Community Group, W3C
58 |
59 | * François REMY
60 | Co-founder, Extensible Web Community Group, W3C
61 |
62 | * Clint Hill
63 | Co-founder, Extensible Web Community Group, W3C
64 |
65 | * Marcos Caceres
66 | Co-founder, Extensible Web Community Group, W3C
67 |
68 | * Tom Dale
69 | Core Team, Ember.js
70 |
71 | * Anne van Kesteren
72 | Editor of standards, Architecture Astronaut at Mozilla
73 |
74 | * Sam Tobin-Hochstadt
75 | Member, TC39
76 |
77 | * Domenic Denicola
78 | Co-Editor, Promises/A+
79 |
80 | * Chris Eppstein
81 | Maintainer, Sass
82 |
83 | * Dave Herman
84 | Mozilla Research and TC39
85 |
86 | * Alan Stearns
87 | Member, CSSWG
88 |
89 | * Rick Waldron
90 | Member, TC39
91 |
92 | * Paul Irish
93 | Google
94 |
95 | * Ted Han
96 | Lead Developer, DocumentCloud
97 |
98 | * Tab Atkins
99 | Member, CSS WG; Google
100 |
101 | -----
102 |
103 | **Related reading**
104 | * [Extend the Web Forward](http://yehudakatz.com/2013/05/21/extend-the-web-forward/), by Yehuda Katz, which fleshes out these ideas more.
105 | * [An Extensible Approach to Browser Security Policy](http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/), by Yehuda Katz, which presents a practical application of these principles to the problem of designing an API for the browser's Content Security Policy.
106 | * [Dropping the F-Bomb on Web Standards](https://briankardell.wordpress.com/2013/05/17/dropping-the-f-bomb/), by Brian Kardell, a practical discussion of how ideas and language from the developer community can be integrated back into interoperable standards.
107 | * [Bedrock](http://infrequently.org/2012/04/bedrock/), by Alex Russell, a 2012 post that explores, in-depth, the philosophy and practice of designing the platform in an extensible ("layered") way.
108 |
--------------------------------------------------------------------------------