forked from w3c/charter-html
-
Notifications
You must be signed in to change notification settings - Fork 0
/
html-plan.html
201 lines (140 loc) · 13.2 KB
/
html-plan.html
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
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
<!DOCTYPE html>
<html lang=en>
<head>
<title>html-plan</title>
<title>Title</title>
<meta charset='utf-8'>
<meta name=viewport content='width=device-width'>
<link rel=stylesheet href='https://www.w3.org/StyleSheets/TR/base'>
<style>
body {
max-width: 60em;
margin: auto;;
}
.sign {
font-size: small;
margin-top: 2em;
font-style: italic;
border-top: 1px solid black;
padding-top: 0.5ex;
}
*:target {
background-color: yellow;
}
</style>
</head>
<body>
<h1 id="warning">NOTE: This document is mainly historical at this point.</h1>
<h1>Achieving maintenance and future progress of HTML</h1>
<p>The goal of this plan is to improve the tone and participation at W3C so that we achieve interoperability around HTML and continue to enhance the specification.</p>
<p>That can be achieved in 4 phases:</p>
<ol>
<li>Incubating new ideas</li>
<li>Efficient data-driven standards work</li>
<li>Interoperability</li>
<li>Maintenance (aka actual interoperability)</li>
</ol>
<p>This plan proposes to create one Community Group to incubate ideas, and reshape the Working Groups to achieve interoperability.</p>
<h2 id='incubating'>Incubating new ideas</h2>
<p>There is one Community Group, called the <a href="incubator-cg-charter.html"><strong>Web Platform Incubator</strong></a> Community Group (Web Platform ICG). Its mission is to attract, foster, and incubate ideas and proposals around the Web Platform, by facilitating communication with developers at large or by using data-driven metrics to identify common patterns that warrant first class support in the Web Platform. If the Web Platform ICG works with consensus, it will significantly reduce the effort to transition from CG to W3C Recommendation.</p>
<p>
The W3C Team and Leadership of the Community and Working Groups should ensure proper transitioning of ideas towards the standardization track, while also ensuring proper continuity in participation.
</p>
<p>Note that the creation of the Web Platform ICG would not preclude new ideas from being discussed in other Community or Working Groups. It simply provides an easy forum with the Community already present without the need to create one more new Community Group if one doesn't wish to.</p>
<h3 id='transition'>From ideas to standards work</h3>
<p>Once a proposal becomes mature enough to justify formal standardization, it becomes the mission and responsibility of a Working Group to ensure proper acceptance, through consensus, wide reviews, <a href='#footnote1'>data-driven</a> analysis, and technical merit. A proposal may become ready for standardization efforts because of implementation experience or broad support.
<p>Supporters of the proposal should perform an "<em><a href='request-to-transition.html'>Intent to Migrate</a></em>" assessment, outlining use cases, as well as implementation considerations, security, privacy, accessibility, and internationalization impacts. It is the role of the proper Working Group (HTML, CSS, WebApps, etc.) to evaluate such assessment before starting a standardization effort.</p>
<h3 id="steps">CG Considerations</h3>
<p>Contributions will be need to be tracked to ensure proper commitments. As such, we'll need the following setup:</p>
<ul>
<li>Map the GitHub identities to the W3C identities</li>
<li>Facilitate the creation of a GitHub repository for the purpose of fostering a proposal</li>
<li>Ensure people making comments/pull requests are aware of the IPR commitment they are making, such as appropriate <a href='https://github.com/w3c/web-nfc/blob/gh-pages/CONTRIBUTING.md'>CONTRIBUTING</a> and <a href='https://github.com/w3c/web-nfc/blob/gh-pages/LICENSE.md'>LICENSE</a> disclaimers</li>
<li>All contributors to a commit or a pull request (PR) should be identified, not just the individual who made the commit or PR. A tool will flag if a pull request should be merged depending on its contributors</li>
<!--
@@check with Mike Champion
<li>Tooling to assist W3C Members who may wish their employees to participate in some but not all the GitHub repos affiliated with a CG</li>
-->
<li>Tools to help W3C Members track which affiliated GitHub repos their employees are contributing to</li>
<li>Encouraging to get broad patent commitments on a spec via a Final Specification Agreement as part of an intent to migrate to a Working Group</li>
<li>Generate weekly activity reports from the Github repos</li>
</ul>
<h2 id='efficent'>Efficient data-driven standards work</h2>
<p>(see <a href='https://github.com/w3c/charter-html/issues/14'>issue 14</a>)</p>
<p>
The goal of the <strong>HTML Working Group</strong> is to continue the development of the HTML language. As such, it will continue to maintain and produce incremental revisions to the HTML specification and its extensions, and drive interoperability of implementations.
As in the CSS or WebApps Working Groups, a limited number of individuals from the general public can become (true) invited experts based on expertise.</p>
<p>
Each document worked in the Working Group should have two branches: a <strong>development</strong> one and a <strong>stable</strong> one. Daily work is expected to happen on the dev branch, including bug fixing. When applicable, changes must be backported to the stable branch. It is encouraged to have different individuals between the dev and the stable branches. The goal of the development branch is to encourage convergence of the implementations towards interoperability as well as introduce new function. The goal of the stable branch is to document expected interoperability.
</p>
<p>
The amount of resources from the W3C Team will vary depending on the need for innovation and interoperability around HTML.
</p>
<h2 id='interop'>Interoperability</h2>
<p>The HTML Working Group is expected to demonstrate interoperability to move stable branches towards W3C Recommendation status. It is recommended to have a common set of exit criteria for the modules. This effort must be coordinated with testing through the Test the Web Forward efforts.
<p>For features that are well known to be widely implemented and deployed, and where implementations are believed to match the specification, the Working Group will make judgment call to move to W3C Recommendation status based on sufficient testing; 100% pass rate will not necessarily be required. In any case where the judgment is debatable, it will be a Working Group decision whether sufficient interoperability has been achieved.</p>
<h2 id='maintenance'>Maintenance</h2>
<p>Althougth we demonstrate interoperability while moving to W3C Recommendation status, the Web Platform changes and we need to continually update the specifications to maintain actual interoperability <em>in the field</em>.
The HTML Working Group's goal is to monitor interoperability of the implementations to <strong>achieve actual interoperability</strong>. As such, it is expected to maintain HTML and its extensions, and the Chairs and Team need to ensure that bugs get property triaged, <strong>prioritized</strong>, and addressed. The triage and prioritarization should be based on real-world usage.</p>
<h2 id='org'>Organization</h2>
<h3 id='license'>Licensing</h3>
<p>
A GPL-compatible with attribution License, such as the <a href='http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document.html'>W3C Software and Document license</a>, will be used for the HTML specification and the HTML extensions in the Community Group and the Working Group.
</p>
<h3 id='leader'>Leadership</h3>
<p>The Web Platform Incubator Community Group and the HTML Working Group are expected to have well-coordinated good leaders, well accepted and recognized by the community. The leaders should be selected to be magnets for the community - that HTML@W3C has become an effective place to get work done. The leaders must ensure efficient progress and prevent discussion derailments. Due process, broad consensus, transparency, balance, and openness are the principles guiding the Community and Working Groups. Note that CG and WG leaders have different qualities:</p>
<ul>
<li>CG Leadership: outreach, administrivia, coaching</li>
<li>WG Leadership: process (avoid derailment, drive decision, drive schedule), technical (expertise in use and implementation), leadership skills/credibility, no W3C Team, no editor</li>
</ul>
<h3 id='contributions'>Contributions and Communications</h3>
<p>The Web Platform Incubator Community Group and the HTML Working Group conduct their work primarily through github repositories, for contributions and communications. <a href='http://discourse.specifiction.org/'>Discourse</a> may be used for broad discussions with the community. There will be one github repository per document. Similar to open-source software development, peer production is encouraged: changes will be executed through Pull Requests, where each pull request gets preferably reviewed before being merged.<br>
See also <a href='https://specs.webplatform.org/docs/'>Web Platform Specs</a>. The Community and Working Groups will use common communication means, to facilitate participation and continuity (e.g. similar github repositories or list).
</p>
<p>Regular activity summaries around the github repositories must be provided.</p>
<h3 id='participation'>Participation</h3>
<p>All Working Group participants are also encouraged to be participants in the Web Platform Incubator Community Group. A major objective of this new plan is to encourage participation by those who can best drive innovation and interoperability for the web platform. When an idea gets transitioned into the Working Group, care should be taken in ensuring continuity in participation.</p>
<h3 id='team'>Team Participation</h3>
<p>W3C Team will participate in both Groups, integrate data sources for interoperability and prioritarization purposes, and help the leadership with transitioning ideas.</p>
<h3 id='browsers'>Browser engines meeting</h3>
<p>(see <a href='https://github.com/w3c/charter-html/issues/10'>issue 10</a>)</p>
<p><strong>Note:</strong> This section is somewhat orthogonal to the proposal and will probably be removed in the future.</p>
<p>
To ensure proper focus and prioritization, the W3C Team will ensure proper sychronization of vendor interests. As such, the W3C Team will hold quarterly meetings with those with authority over what gets committed to a consumer browser engine codebase. The scheduling, agenda, and minutes of those meetings will be made publicly available.
</p>
<h2 id='datadriven'>Data-Driven Group</h2>
<p>There are several existing data metrics to help prioritize interoperability issues:</p>
<ul>
<li>Web Page usage and metrics: httparchive, <a href='http://commoncrawl.org/'>commoncrawl</a>, browser metrics (e.g. <a href='https://www.chromestatus.com/metrics/feature/popularity'>blink</a>)</li>
<li>Implementation status: <a href='https://www.chromestatus.com/features'>blink</a>, <a href="https://status.modern.ie/">IE</a>, <a href='http://caniuse.com/'>caniuse</a></li>
<li>Test metrics: <a href='http://testthewebforward.org/'>Test the Web Forward</a></li>
<li>Vendor bug feedback: issues raised against the specifications should be associated with issues raised against implementations</li>
</ul>
<h2 id='directions'>Technical Directions</h2>
<p>While the technical direction for HTML will continue to evolve, here are some of the topics which we already know to be of interest for HTML.next, and should be considered by the Web Platform ICG based on data-driven metrics to identify common patterns:
<dl>
<dt id='mobile'>Markup for mobile UI widgets</dt>
<dd>There may be a set of elements that could usefully be added to HTML for (semantic) application components. One widget may be to provide a way for the user to indicate his geolocation to the application, without having to go through extra validation.</dd>
<dt id='form'>Stylable form controls</dt>
<dd>HTML5 Forms have the serious drawbacks of not being stylable, impeding their adoption. In order to define style, those forms would need to have structure, such as through Web Components</dd>
<dt id='responsive'>Responsive-but-performant design</dt>
<dd>The Responsive Images Community Group made progress in the area of images but more needs to be done.</dd>
<dt id='mediacg'>Media APIs</dt>
<dd>New Media APIs are needed, and some coherence could usefully be brought amongst all the people extending HTMLMediaElement.</dd>
<dt id='canvas'>Canvas</dt>
<dd>The 2DContext is an area of continued interest and given its specific, focused work.</dd>
</dl>
<p>The HTML Working Group will continue the following efforts:</p>
<dl>
<dt id='editing'>Editing</dt>
<dd>The existing joint HTML-WebApps TF is already well under way.</dd>
<dt id='media'>Media APIs</dt>
<dd>There is ongoing work around media streams and encrypted media extensions.</dd>
<dt id='a11y'>Accessibility</dt>
<dd>Much useful work is still needed in order for the Web platform to be accessible, such as <a href='https://specs.webplatform.org/common-panel/bkardell/gh-pages/'>panels</a>, or the <a href="http://w3c.github.io/aria/html-aam/html-aam.html">Accessibility API mappins</a>.</dd>
</dl>
<p class='sign'>
<a href="https://www.twitter.com/plhw3org">@plhw3org</a>, contribute: <a href="https://github.com/w3c/charter-html">w3c/charter-html</a>
</p>
</body>
</html>