├── CONTRIBUTING.md
├── README.md
├── SourceCodeLicense
└── LICENSE.txt
├── cg-charter.html
└── wg-charter.html
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # GPU for the Web
2 |
3 | This repository is being used for work in the [W3C GPU for the Web Community
4 | Group](https://www.w3.org/community/gpu/), governed by the [W3C Community
5 | License Agreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To
6 | make substantive contributions, you must join the CG.
7 |
8 | Contributions to the source code repository are subject to the terms of the
9 | [3-Clause BSD License](https://github.com/gpuweb/admin/blob/SourceCodeLicense/LICENSE.txt).
10 |
11 | If you are not the sole contributor to a contribution (pull request), please identify all
12 | contributors in the pull request comment.
13 |
14 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows:
15 |
16 | ```
17 | +@github_username
18 | ```
19 |
20 | If you added a contributor by mistake, you can remove them in a comment with:
21 |
22 | ```
23 | -@github_username
24 | ```
25 |
26 | If you are making a pull request on behalf of someone else but you had no part in designing the
27 | feature, you can remove yourself with the above syntax.
28 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Administrative documents for the GPU on the Web group.
2 |
--------------------------------------------------------------------------------
/SourceCodeLicense/LICENSE.txt:
--------------------------------------------------------------------------------
1 | Copyright
2 |
3 | Redistribution and use in source and binary forms, with or without
4 | modification, are permitted provided that the following conditions are met:
5 |
6 | 1. Redistributions of source code must retain the above copyright notice,
7 | this list of conditions and the following disclaimer.
8 |
9 | 2. Redistributions in binary form must reproduce the above copyright notice,
10 | this list of conditions and the following disclaimer in the documentation
11 | and/or other materials provided with the distribution.
12 |
13 | 3. Neither the name of the copyright holder nor the names of its
14 | contributors may be used to endorse or promote products derived from this
15 | software without specific prior written permission.
16 |
17 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
18 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
19 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
20 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
21 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
22 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
23 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
24 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
25 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
26 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
27 |
--------------------------------------------------------------------------------
/cg-charter.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | GPU for the Web Community Group Charter
6 |
7 |
8 |
9 |
10 |
29 |
30 |
31 |
32 | [DRAFT] GPU for the Web Community Group Charter
33 |
34 |
35 | This Charter is work in progress. To submit feedback,
36 | please use GPU for the Web Github Issues
37 | where this charter is being developed.
38 |
39 |
40 |
This Charter: 2017-03-29
41 |
42 |
Start Date: TODO
43 |
44 |
Last Modified: TODO
45 |
46 |
47 |
48 | Goals
49 |
50 |
51 | The mission of the GPU for
52 | the Web Community Group is to provide an interface between the Web
53 | Platform and modern 3D graphics and computation capabilities present on
54 | native system platforms.
55 |
56 |
57 | The current practice in accelerated graphics for the Web Platform is to
58 | use WebGL (as of early 2017). This Community Group aims to produce a
59 | more advanced technology with the following features:
60 |
61 |
62 |
An API that maps nicely to modern Web platform design patterns;
63 |
A lower-level API that allows greater performance in applications;
64 |
An API that exposes the GPU computation functionality provided by more
65 | modern APIs and available on many devices;
66 |
67 |
A technology that can be reasonably implemented on all platforms
68 | that have a modern, low-level graphics API;
69 |
70 |
An API designed to provide a efficient bindings for both JavaScript and
71 | WebAssembly, possibly
72 | requiring separate interfaces for each.
73 |
74 |
75 |
76 |
77 | If successful, the output from this Community Group will establish a
78 | new programming layer for the Web Platform that is more modern, more
79 | efficient, more functional, better integrated with other aspects of
80 | the Web Platform, and designed to be implemented on a wide variety of
81 | modern graphics platform or, in a worst case scenario, in a software
82 | fallback. We expect most participants of this Community Group to
83 | commit to a Final
85 | Specification Agreement.
86 |
87 |
88 |
89 | Scope of Work
90 |
91 |
92 |
93 | This Community Group will recommend a Web programming interface for
94 | graphics and computation that:
95 |
96 |
97 |
98 |
enables rendering of modern graphics to both onscreen and offscreen drawing surfaces
99 |
enables computation tasks to be performed, and the results of such tasks to be retrieved
100 |
This group will also recommend a companion Shading Language that describes the graphics and
101 | computation tasks in a format
102 | that can be translated or compiled into platform-specific instructions
103 |
104 |
105 |
106 | The API will not be restricted to any particular platform technology. Instead, it will
107 | be generic enough to be implemented on top of modern GPU libraries, such as
108 | Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan.
109 |
110 |
111 |
Target Audiences
112 |
113 |
114 | The deliverables of this Community Group are
115 | primarily addressed, either directly or indirectly, to the following audiences:
116 |
117 |
118 |
119 | Developers of 3D and game engines/tools that are producing Web
120 | content via transpilation. For example, Unity and the Unreal Engine use emscripten to
124 | compile content for the Web.
125 |
126 |
127 |
128 | JavaScript framework developers who are building GPU libraries,
129 | intended to be used in Web content, but providing a higher-level
130 | API and hiding much of the low-level graphics and compute details
131 | from their users. For example, three.js.
133 |
134 |
135 |
136 | Web developers who are competent in GPU technologies, and will want to
137 | use the GPU for the Web API directly to create content, rather than
138 | a higher-level framework.
139 |
140 |
141 |
142 |
143 | The typical Web, or even non-Web, developers are a secondary audience, since
144 | they often prefer using a higher-level framework rather than the low-level
145 | technology. Such developers are an important part of the community, and some
146 | of the Community Group's non-normative deliverables
147 | are addressed to them.
148 |
149 |
150 |
Out of Scope
151 |
152 |
153 | The scope of work is restricted to the development of a programming
154 | interface between the Web Platform and modern 3D graphics and
155 | computation capabilities present on native system platforms. The work
156 | will not define hardware features or algorithms, and the interface it
157 | defines is not intended to be directly exposed by a GPU driver.
158 |
159 |
160 |
161 | Definitions
162 |
163 |
164 |
GPU
165 |
166 |
Graphics Processing Unit. Typically a piece of hardware dedicated to
167 | efficiently processing graphics and related features.
168 |
169 |
Shading Language
170 |
171 |
A restricted programming language that can be used to perform graphics
172 | or computation tasks, and can usually be compiled into a more efficient
173 | format for direct execution on GPUs.
174 |
175 |
176 |
177 | Deliverables
178 |
179 |
180 | Specifications
181 |
182 |
183 |
GPU for the Web Specification
184 |
185 |
An API as described above.
186 |
187 |
WebGPU Shading Language
188 |
189 |
A Shading Language specification that defines the programmable
190 | interface to the GPU for the Web graphics and computation
191 | pipeline, and that can be translated into the shading languages
192 | of the system APIs WebGPU is implemented upon.
193 |
194 |
195 | Non-Normative Reports
196 |
197 |
The group may produce a draft Charter for a GPU for the Web Working
198 | Group at W3C.
199 |
200 |
201 | The group may also produce other Community Group Reports within the scope of
202 | this charter but that are not Specifications, for instance use cases,
203 | requirements, or white papers.
204 |
205 |
206 | Tutorials
207 |
208 |
209 | The group may produce tutorial or explanatory content designed
210 | to help people learn the technical material. For example, an interactive
211 | tutorial could introduce the graphics pipeline or shader programming.
212 |
213 |
214 | Test Suites and Other Software
215 |
216 |
217 | The Community Group will develop a test suite that exercises the GPU for the Web API.
218 | Please see the GitHub LICENSE file for test suite contribution licensing
219 | information.
220 |
221 |
222 | The Community Group may develop a software library that implements the GPU for the
223 | Web work across multiple platforms using existing native APIs. For example, a
224 | C++ library that exposes GPU for the Web using Direct3D, Metal or Vulkan. Such software
225 | will be developed using the
227 | W3C Software and Document License.
228 |
229 |
230 | The Community Group may develop a continuous integration mechanism to validate the
231 | grammar of WebGPU Shading Language against syntactic ambiguities and potential
232 | mechanical issues with primary reliance on an open-source, commercially-permissive
233 | license tool that can report ambiguity and generate playgrounds that can run on the Web
234 | so that community can leverage and extend easily to enhance the ecosystem. Such software
235 | will be developed using the
237 | W3C Software and Document License.
238 |
239 |
240 | Community and Business Group Process
241 |
242 |
243 | The group operates under the Community and Business
245 | Group Process. Terms in this Charter that conflict with those of the
246 | Community and Business Group Process are void.
247 |
248 |
249 | As with other Community Groups, W3C seeks organizational licensing
250 | commitments under the W3C Community
252 | Contributor License Agreement (CLA). When people request to
253 | participate without representing their organization's legal interests,
254 | W3C will in general approve those requests for this group with the
255 | following understanding: W3C will seek and expect an organizational
256 | commitment under the CLA starting with the individual's first request to
257 | make a contribution to a group Deliverable.
258 | The section on Contribution Mechanics describes
259 | how W3C expects to monitor these contribution requests.
260 |
261 |
262 | Work Limited to Charter Scope
263 |
264 |
265 | The group will not publish Specifications on topics other than those
266 | listed under Specifications above. See
267 | below for how to modify the charter.
268 |
279 | Specifications created in the Community Group must use the
281 | W3C Software and Document License. All other documents produced by
282 | the group should use that License where possible.
283 |
284 |
285 | Community Group participants agree to make all contributions in the
286 | GitHub repository the group is using for the particular document. This may be
287 | in the form of a pull request (preferred), by raising an issue, or by
288 | adding a comment to an existing issue.
289 |
290 |
291 | All Github repositories attached to the Community Group must contain a
292 | copy of the CONTRIBUTING
294 | and LICENSE
296 | files.
297 |
298 |
299 | Transparency
300 |
301 |
302 | The group will conduct all of its technical work in public. All technical work
303 | will occur in the GitHub repositories
304 | (and not in mailing list discussions). This is to ensure contributions
305 | can be tracked through a software tool.
306 |
307 |
308 | Meetings may be restricted to Community Group participants, but a public
309 | summary or minutes must be posted to the group's public mailing list, or
310 | to a GitHub issue.
311 |
312 |
313 | Decision Process
314 |
315 |
316 | This group will seek to make decisions where there is consensus. Consensus
317 | will be assessed by one of:
318 |
319 |
320 |
Participants who have earned Committer status for a history of useful contributions
321 |
The Chair
322 |
323 |
324 | Where consensus is not
325 | clear there is a Call for Consensus [CfC] to allow multi-day online
326 | feedback for a proposed course of action.
327 |
328 |
329 | Participants can earn Committer status through a history of valuable
330 | contributions as is common in open source projects. After discussion and
331 | due consideration of different opinions, a decision should be publicly
332 | recorded (where GitHub is used as the resolution of an Issue).
333 |
334 |
335 | If substantial disagreement remains (e.g. the group is divided) and the
336 | group needs to decide an Issue in order to continue to make progress, the
337 | Committers will choose an alternative that had substantial support (with
338 | a vote of Committers if necessary). Individuals who disagree with the
339 | choice are strongly encouraged to take ownership of their objection by
340 | taking ownership of an alternative fork. This is explicitly allowed (and
341 | preferred to blocking progress) with a goal of letting implementation
342 | experience inform which specification is ultimately chosen by the group to move
343 | ahead with.
344 |
345 |
346 | Any decisions reached at any meeting are tentative and should be recorded
347 | in a GitHub Issue for groups that use GitHub and otherwise on the group's
348 | public mail list. Any group participant may object to a decision reached
349 | at an online or in-person meeting within 7 days of publication of the
350 | decision provided that they include clear technical reasons for their
351 | objection. The Chairs will facilitate discussion to try to resolve the
352 | objection according to the decision process.
353 |
354 |
355 | It is the Chairs' responsibility to ensure that the decision process is
356 | fair, respects the consensus of the CG, and does not unreasonably favour
357 | or discriminate against any group participant or their employer.
358 |
359 |
360 | Chair Selection
361 |
362 |
363 | Participants in this group choose their Chair(s) and can replace their
364 | Chair(s) at any time using whatever means they prefer. However, if 5
365 | Committers, no two from the same organisation, call for an election,
366 | the group must use the following process to replace any current Chair(s)
367 | with a new Chair, consulting the Community Development Lead on election
368 | operations (e.g., voting infrastructure and using RFC 2777).
370 |
371 |
372 |
Participants announce their candidacies. Participants have 14 days to
373 | announce their candidacies, but this period ends as soon as all
374 | participants have announced their intentions. If there is only one
375 | candidate, that person becomes the Chair. If there are two or more
376 | candidates, there is a vote. Otherwise, nothing changes.
377 |
378 |
Participants vote. Participants have 21 days to vote for a single
379 | candidate, but this period ends as soon as all participants have voted.
380 | The individual who receives the most votes, no two from the same
381 | organisation, is elected chair. In case of a tie, RFC2777 is used to
382 | break the tie. An elected Chair may appoint co-Chairs.
383 |
384 |
385 |
386 | Participants dissatisfied with the outcome of an election may ask the
387 | Community Development Lead to intervene. The Community Development Lead,
388 | after evaluating the election, may take any action including no action.
389 |
390 |
391 | Initial Chair and Committers
392 |
393 |
394 | As of the date of this document, the initial co-Chairs for the Community
395 | Group are Dean Jackson (Apple) and Corentin Wallez (Google).
396 |
397 |
398 | The initial Committers are:
399 |
400 |
401 |
Corentin Wallez (Google)
402 |
Dean Jackson (Apple)
403 |
Dzmitry Malyshau (Mozilla)
404 |
Jeff Gilbert (Mozilla)
405 |
Jon Lee (Apple)
406 |
Kai Ninomiya (Google)
407 |
Ken Russell (Google)
408 |
Milan Sreckovic (Mozilla)
409 |
Myles Maxfield (Apple)
410 |
Theresa O'Connor (Apple)
411 |
412 |
413 | Amendments to this Charter
414 |
415 |
416 | The group can decide to work on a proposed amended charter, editing the
417 | text using the Decision Process described above.
418 | The decision on whether to adopt the amended charter is made by
419 | conducting a 30-day vote on the proposed new charter. The new charter, if
420 | approved, takes effect on either the proposed date in the charter itself,
421 | or 7 days after the result of the election is announced, whichever is
422 | later. A new charter must receive 2/3 of the votes cast in the approval
423 | vote to pass. The group may make simple corrections to the charter such
424 | as deliverable dates by the simpler group decision process rather than
425 | this charter amendment process. The group will use the amendment process
426 | for any substantive changes to the goals, scope, deliverables, decision
427 | process or rules for amending the charter.
428 |
429 |
430 |
431 |
432 |
--------------------------------------------------------------------------------
/wg-charter.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | GPU for the Web Working Group Charter
7 |
8 |
9 |
10 |
11 |
50 |
51 |
52 |
53 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
PROPOSED GPU for the Web Working Group Charter
76 |
77 |
Warning: This document has no official status. It is a draft charter for discussion within the GPU for the Web groups and the W3C Advisory Committee.
78 |
79 |
The mission of the GPU for the Web Working Group is to
81 | provide an interface between the Web Platform and modern 3D graphics and
82 | computation capabilities present on native system platforms.
137 | Teleconferences: weekly or bi-weekly calls, as necessary.
138 |
139 | Face-to-face: 3 times per year as necessary,
140 | including during W3C's annual Technical Plenary week.
141 |
142 |
143 |
144 |
145 |
146 |
147 |
Motivation and Background
148 |
149 | In this document, the term GPU stands for Graphics Processing Unit, typically a piece of hardware dedicated to efficiently processing graphics and related features.
150 |
151 |
152 | GPUs have become essential for drawing complex images efficiently, including for rendering virtual reality and augmented reality scenes in real-time as needed by the WebXR Device API. GPUs are also at the heart of computations that leverage parallelism, such as machine learning inference.
153 |
154 |
155 | Web applications may leverage GPUs through the WebGL family of APIs, but WebGL does not enable access to more advanced features of GPUs, focuses on drawing images and does not provide first-class support for performing general computations, and is not agnostic of the GPU system API exposed by the underlying operating system.
156 |
157 |
158 | The overall goal of the GPU for the Web Working Group is to provide a foundation that can be implemented on top of modern GPU system APIs to expose modern GPU functionality on the Web, both for computation and for image rendering.
159 |
160 |
161 | See also the WebGPU Explainer, maintained by the GPU for the Web Community Group, for additional background, use cases, and design considerations.
162 |
163 |
164 |
165 |
166 |
Scope
167 |
168 | This Working Group will recommend a Web programming interface for
169 | graphics and computation that:
170 |
171 |
172 |
173 |
enables rendering of modern graphics to both onscreen and offscreen drawing surfaces
174 |
enables computation tasks to be performed, and the results of such tasks to be retrieved
175 |
This group will also recommend a companion Shading Language that describes the graphics and computation tasks in a format
176 | that can be translated or compiled into platform-specific instructions
177 |
178 |
179 |
180 | The API will not be restricted to any particular platform technology. Instead, it will
181 | be generic enough to be implemented on top of modern GPU system APIs, such as
182 | Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan.
183 |
184 |
185 |
186 | This Working Group will investigate and document threat mitigation
187 | strategies for the API, notably to address fingerprinting issues
188 | and to prevent unauthorized use of computational resources.
189 |
190 |
191 |
Out of Scope
192 |
193 | The scope of work is restricted to the development of a programming
194 | interface between the Web Platform and modern 3D graphics and
195 | computation capabilities present on native system platforms. The work
196 | will not define hardware features or algorithms, and the interface it
197 | defines is not intended to be directly exposed by a GPU driver.
198 |
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to reach a stable state. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.
234 | A Shading Language specification that defines the programmable
235 | interface to the GPU for the Web graphics and computation
236 | pipeline, and that can be translated into the shading languages
237 | of the system APIs WebGPU is implemented upon.
238 |
253 | This Working Group will produce conformance test suites and
254 | implementation reports for its normative deliverables.
255 |
256 |
257 | Other non-normative documents may be created, including:
258 |
259 |
260 |
Reference implementations of the group's deliverables
261 |
Use case and requirement documents
262 |
Explainers, primers and best-practice documents
263 |
264 |
265 |
266 |
267 |
268 |
269 |
Success Criteria
270 |
There should be testing plans for each specification, starting from the earliest drafts. Normative specification changes are generally expected to have a corresponding set of tests, either in the form of new tests or modifications to existing tests, or must include the rationale for why test updates are not required for the proposed update.
271 |
Each specification should contain sections detailing all known security and privacy —including fingerprinting— implications, and suggested mitigation strategies for implementers, web authors, and end users. The group should not publish a specification if acceptable mitigation strategies cannot be found.
272 |
Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.
All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.
275 |
276 |
277 |
278 |
279 |
Coordination
280 |
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.
281 |
282 |
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
The GPU for the Web Community Group developed the specifications adopted by this Working Group. It is expected that the Community Group will continue to work on test suites, tools, white papers and other non normative reports associated with the deliverables of this Working Group.
The Immersive Web Working Group produces specifications to interact with Virtual Reality (VR) and Augmented Reality (AR) devices and sensors, and may add a 3D rendering layer based on the WebGPU API.
This Working Group develops a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.
The Unicode Technical Committee is responsible for the development and maintenance of the Unicode Standard, including the Unicode Character Database. This Working Group will coordinate with the UTC where appropriate, notably with regards to supporting Unicode identifiers in the WebGPU Shading Language specification.
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 |
320 | Participation
321 |
322 |
323 | To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
324 |
325 |
326 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
327 |
328 |
329 | The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
330 |
331 |
332 | Participants in the group are required
333 | (by the W3C Process)
334 | to follow the W3C
335 | Code of Conduct.
336 |
337 |
338 |
339 |
340 |
341 |
342 |
343 | Communication
344 |
345 |
346 | Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
347 |
348 |
349 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the GPU for the Web Working Group home page.
350 |
351 |
352 | Most GPU for the Web Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
353 |
354 |
355 | This group primarily conducts its technical work in its public repositories. There is also a public mailing list public-gpu@w3.org (archive). The public is invited to contribute to the github repositories and post messages to the list. Regular activity summaries around the github repositories will be provided.
356 |
357 |
358 | The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
359 |
360 |
361 |
362 |
363 |
364 |
365 |
366 | Decision Policy
367 |
368 |
369 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
370 |
371 | However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
372 |
373 |
374 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
375 |
376 | A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from 10 working days, depending on the chair's evaluation of the group consensus on the issue.
377 |
378 | If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
379 |
380 |
381 | All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
382 |
395 | This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis.
396 |
397 | For more information about disclosure obligations for this group, please see the licensing information.
398 |
411 | This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
412 |