The WebView Community Group aims to identify, understand, and reduce the issues arising from the use of software components (typically referred as WebViews) that are used to render Web technology-based content outside of a Web browser (Native Apps, MiniApps, etc).
The WebView Community Group will:
- identify the issues, challenges, and limitations that arise from the usage of WebViews, regardless of the platform and type of device they're used on, including gathering support data to document interoperable surface of WebViews,
- determine whether they can be addressed through improvements to the Web Platform, WebView capabilities, the surrounding ecosystem (e.g. documentation, testing frameworks), or through other mechanisms,
- develop technical proposals (explainers) targeting the agreed upon issues, challenges, and limitations that would be implemented in a WebView,
- raise awareness about the impact of WebViews for Web technologies in relevant communities (e.g. existing W3C groups)
The following things are out of scope:
- Proposals that are not applicable to WebViews as defined in this charter (e.g. proposals on browser related improvements),
- Normative specifications. Actual incubation of the explainers developed by the group is not in scope of this charter.
- Machine-readable data describing the differences between WebView & browser implementations that can be consumed by documentation platforms and other tools, by February 2025
-
WebView use cases and limitations: a document describing the type of use WebViews fulfill and the challenges they create in distributing content and applications built on top of Web technologies.
The group intends to continue updating the document with relevant usages and challenges.
-
Technical proposals: Explainers outlining solutions for the agreed upon challenges.
- MiniApps Ecosystems Community Group and MiniApps Working Group: MiniApps rely extensively on WebViews
- Web Application Security Working Group: the Web Application Security Working Group oversees the security model applied to Web content in browsers, which impacts Web technologies used outside of that context
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to a GitHub issue if the group uses GitHub.
This group will seek to make decisions where there is consensus. Actions/proposals that require consensus should be proposed publicly on the group's mailing list. The chairs should provide ample time for participants to voice concern (7+ days).
If there is no opposition, the action/proposal will proceed.
If there is sustained opposition without changes to the issue, and the proposer still wishes to proceed, the Chairs will hold an approval vote in the Community Group. Each organisation will have one vote. This is only to be used as a last resort if consensus can’t be reached and no progress is being made. Generally an approval vote requires a simple majority, though amendments to the Charter will require a two-thirds majority.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to this decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
The group chairs can propose the group adopts an amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the regular group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.