w3c / miniapp

MiniApps Standardization

MiniApps Standardization

MiniApps Working Group

• WG Homepage
• WG Specs
• WG Charter
• WG Meeting Minutes
• WG Calendar
• WG Test Suites

MiniApps Ecosystem Community Group

• CG Homepage
• CG Specs
• CG Charter
• CG Meeting Minutes
• CG Calendar

Other documents

• MiniApp Standardization White Paper
• FAQ

miniapp's Issues

Update the manifest explainer

https://github.com/w3c/miniapp/blob/gh-pages/specs/manifest/docs/explainer.md

We should update the manifest explainer to reflect the fact that MAM is now an extension of WAM.

Add privacy and security considerations to the manifest spec

We need a privacy and security considerations section.

References:

• https://www.w3.org/TR/appmanifest/#installation-sec
• https://www.w3.org/TR/appmanifest/#navigation-scope-security-considerations
• https://www.w3.org/TR/appmanifest/#security-and-privacy-considerations
• https://www.w3.org/TR/appmanifest/#media-type-registration

Change the way to access MiniApp programs to make them more suitable for expanding platform interoperability

It is difficult to solve the MiniApp AppKey distribution and query target Package URI by AppKey.
Can we build the de-centrally MiniApp platform system?

Is it possible to use the domain name as the only AppKey of the MiniApp like the HTML5 web page? The browser can load a MiniApp program just like loading an HTML5 web page.

When a user accesses a MiniApp, the main part work for the vendor is that:

• For the browser, request the manifest file in the origin server firstly.
• Get the MiniApp Package URI and meta info from the Manifest.
• Fetch the package file and install it locally.
• Prepare render and logic worker and start the MiniApp pages.
• Update the local cache package file until over max-age.

The benefit of this way is that we don't need a centralized server the get the right AppKey. Any Developer and run it's MiniApp in its server. The user only needs to load the URI of the MiniApp domain to access the MiniApp.

So, we should build an interoperated MiniApp Platform System. And the MiniApp W3C spec can work for China's business environment.

If we change this way to access MiniApp for the de-centrally remote server. Some sub-questions for fetch the package file is that:

• How to verify the security of a server package resource?

• How to know the specific URI path of the small package resource on the server-side?

• How to obtain remote resources? Do you need to specify the network request protocol? Is HTTP redirect allowed?

• How to ensure that there is no tampering during packet transmission, such as man-in-the-middle attacks?

• Can you protect the security of the incoming packet, such as the problem of tampering?

• Package resource decompression path, should the directories of each source be unified?

• Do you want to prohibit the isolation of small package resource caches of different domain names?

Charter: expand WebAppSec citation?

The Web Application Security Working Group is developing guidance on APIs that expose sensitive information, and an API to manage permissions, both of which matter to this group's specifications.

I'm not entirely sure what is intended by this, particularly the first part, and I encourage you to expand on it.

Direction metadata discussion [I18N]

dir
https://w3c.github.io/miniapp/specs/manifest/#dir

dir specifies the base direction of the text value of the app name, short name and description members. The value of dir can be ltr or rtl. ltr means from left to right, rtl means from right to left. Default: ltr.

This section looks okay on its surface, but I would suggest some editorial tweaking on the English, as well as noting the previous concern about a single attribute for all NL values.

Make it clear that MiniApp Manifest will be an extension of Web App Manifest

https://w3c.github.io/miniapp/charters/wg-2020.html#deliverables

The MiniApp Manifest specification will follow the recommendations to extend existing manifest files, provided by the Web Platform Design Principles, with the Web App Manifest as reference.

From this sentence it is not clear that MiniApp Manifest is an extension of Web App Manifest because of the phrase "as reference" (Web App Manifest may be interpreted as a general reference instead of as an extension). Can we mention that "the MiniApp Manifest specification will extend the Web App Manifest" directly?

(This issue comes from a W3C internal discussion.)

i18n review

Following i18n WG ACTION-911, I'm filing this issue to track the status of our i18n review. I'll create the review request issues as separate issues and link to them in this issue.

[charter] In "MiniApp URI Solution", the use of URI is misleading

Also, linking to a document that defines an URI scheme is premature, it would be better to leave it as a new document with a goal to address the use cases pertaining to issue #34

Map API

https://w3c.github.io/miniapp/charters/wg-2020.html

Elements and APIs that would enhance the interoperability among different MiniApp platforms, including UI elements, Device API, and those advanced APIs such as Account API and Map API;

If we want to develop our own mapping API, we should examine the work in the Maps For HTML Community Group and probably mention it in the Coordination section.

WG repo?

If the working group is successfully formed, how do we deal with the miniapp GitHub repo? I think there are two ways: one repo and multiple repos.

The advantage of using one repo (for all the work in the CG and WG) is that there is only a single entrance and it is easy to manage. The disadvantage is the W3C IPR bot doesn't work well with this model (see w3c/ash-nazg#181).

The advantages of using two (one for CG, one for WG) or multiple (one for each spec) are:

• Easier to handle IPR issues
• In the one-repo-for-each-spec model, if a spec is moved to another group, there's no need to set up redirect, move issues etc.

The disadvantage is that if we have too many repos, it is not easy to manage the repos.

appName needs more work [I18N]

appName
https://w3c.github.io/miniapp/specs/manifest/#appname

appName is the name that is directly displayed to the user. It is used as the display name of MiniApp along with the desktop icon and in the context of MiniApp management. MiniApp name may be composed of Chinese characters, English letters, numbers and some special symbols, and its length must be between 4–30 characters.

There are a number of problems with the definition here.

The length limit is defined in "characters", but this is insufficiently clear. See [CHARMOD]. I suspect that the correct definition should be "Unicode code points".

An upper limit of 30 may be very short for some languages, particularly those that use multiple code points for a given grapheme (visual unit of text).

The definition of the permitted list of characters is very imprecise. It is unclear which characters are meant by "Chinese characters", "English characters", "numbers", and so forth. Are specific formally defined character sets (such as GB2312, GB18030, etc.) intended? Why is there a limit here? Why not a wide range of Unicode characters? This specification limits MiniApp to a subset of languages that use (Simplified??) Chinese or ASCII.

shortName usage [I18N]

shortName
https://w3c.github.io/miniapp/specs/manifest/#shortname

shortName provides a short and easy-to-read name for MiniApp, and it can be used when there is insufficient space to display the full MiniApp name provided in appName.

The limit on appName is 30 "characters". This is already a short string for some languages. What is the limit on shortName if it is less than this? What is the character set allowed here?

When defining the length limit, bear in mind that some languages require the use of combining marks to form a "grapheme cluster" (a single visual unit of text) and that limits defined in terms of Unicode code points or UTF-16 code units may impose difficulties on these languages.

draft manifest plan of miniapp

Phase I: Requirement & scope investigation (2019 Q4)

Phase II: Feasibility Analysis and report drafting (2020 H1)

Phase III: First version of report finalizing (2020 H2)

Explain what super/host app is and why we need it

https://w3c.github.io/miniapp/charters/wg-2020.html

To enhance the interoperability between different MiniApp platforms (AKA the super application or host application)

It would be useful to add a sentence or two to explain how super/host app is different from the browsers and why.

FAQ about the proposed MiniApp standards work

While we are moving the MiniApp standards work forward in W3C, especially the charter of the proposed MiniApp Working Group, some initial feedbacks have been received. Some of the feedbacks express questions and concerns about the possibility of MiniApp standards forking currently Web technologies.
It would be very necessary for the MiniApp vendors to clarify the concerns and justify the work of current MiniApp specifications. So I would like to propose a FAQ document to explain the rationale behind the proposed MiniApps standards work.
Here are some initial question list in the FAQ. More questions and answers are welcome.

1. Is MiniApp a part of Web Platform? What is the relationship between MiniApp and Web Platform?
2. If MiniApp uses certain parts of Web technologies, how come it runs without a browser engine?
3. How is MiniApp Manifest different from the Web App Manifest? Could MiniApp Manifest become a unique case for Web App Manifest? Could MiniApp Manifest be merged into the Web App Manifest?
4. Why there is need to create a new URI Scheme specification? How to use the new URI Scheme specification to handle origin? How to handle SecureContext without origin? How to handle CORS?
5. Is it possible to harmonize Page Lifecycle, Page Visibility, Service Worker Lifecycle, and MiniApp Lifecycle specifications? If so, how?
6. Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?
7. What is the implementation expectations of MiniApp specifications in the globe? Are the implementations only expected from Chinese MiniApp vendors?
8. Does MiniApp have its own security model?

auto value of the dir attribute?

https://w3c.github.io/miniapp/specs/manifest/#dir

The dir member in Web App Manifest has an auto value. Do we need this?

Elements and APIs in the charter scope

https://w3c.github.io/miniapp/charters/wg-2020.html

Elements and APIs that would enhance the interoperability among different MiniApp platforms, including UI elements, Device API, and those advanced APIs such as Account API and Map API;

It has been pointed out that the scope is too open-ended and is similar to the scope in the old SysApps WG, and we should clarify more narrowly to help with member acceptance.

(This issue comes from a W3C Strategy Team discussion.)

Communication tools of the group

https://w3c.github.io/miniapp/charters/wg-2020.html#communication

This group primarily conducts its technical work on the [email protected] and on GitHub issues. Other communication tools are allowed if considerable number of the group participants decide to embrace them.

We ought to quantify "considerable number", such as "80% of the participants" and also add "Any decision to use other communication tools must be reevaluated if further W3C Members join the Working Group".

(This comment comes from the W3C Management review of this charter.)

The term "MiniApp"

I have just read that initially Tencent wanted to launch mini app platform with the term "app" in their product name, but they ultimately decided against it because Apple doesn't want such a name. As such, in order to ensure the smooth development of miniapp on different operating systens including iOS, would it be better to abandon the term "miniapp" and use some other words like "mini program" which might be less objectionable?

Web App Manifest compatibility

Should we rename appName and shortName to name and short_name to be compatible with Web App Manifest?

We might also want to consider using snake case instead of camel case for other attributes.

Differences of the two formats: https://github.com/w3c/miniapp/blob/gh-pages/specs/manifest/docs/explainer.md#4-relationship-with-web-app-manifest

Mention EPUB 3 WG in the Coordination section of the charter

https://w3c.github.io/miniapp/charters/wg-2020.html#coordination

We should add EPUB 3 WG in the Coordination section of the charter to ensure our packaging spec is consistent with EPUB's OCF packaging when possible.

Note that the EPUB 3 WG has not been created yet, so we can add it later (when it is created). Here's some background Information:

• W3C strategy funnel issue
• EPUB 3 WG charter proposal
• Blog post that outlines the background of the EPUB work

Define "super-app"

https://w3c.github.io/miniapp/white-paper/

We mentioned "super-app" a few times in the document, but didn't define or explain it.

Define/Explain "UI component"

By @samuelweiler:

"Component" is not defined well enough in the charter. (And perhaps that should be a more general comment.). Specifically: I don't understand what the term means in this context. Explain (in the charter, or by reference within the charter)?

TAG review

This issue tracks the status of our TAG review.

Seek input on accessibility user requirements.

https://w3c.github.io/miniapp/charters/wg-2020.html

We expect that accessibility issues will arise in the development of miniapps that could significantly impact the usability of miniapps by people with disabilities. Addressing these barriers will require more than a post-review of miniapp architecture; instead it will require pro-active early exploration of accessibility user requirements as input to the development process.

Initial identification of accessibility user requirements for miniapps are underway. The charter modification we're requesting is simply to add a line, following the first sentence of subsection 4.1, stating
"The WG will seek input into accessibility user requirements."

MiniApp URI Scheme Draft Community Group Report Q&A

All FAQ had been recorded in https://github.com/w3c/miniapp/blob/gh-pages/specs/uri/docs/Q&A.md

Q1：URI 协议中暴露了下包地址，是否存在安全风险？
A1：就目前的小程序现状而言，下包地址还不是隐秘信息，通过抓包方式也会拿到下包地址， URI 的下包地址并没有增加安全风险。

Q2：为什么 URI 种需要 host 参数，需要从另外一家站点下载包吗？
A2：小程序是有这种诉求的，百度小程序目前的开源联盟就存在一个 APP 从另一个 APP 下载包的场景

Q3：["@" host [ ":" port ]] host 是否限制？
A3：host 字段是可选的，并且值是由宿主解析的，host 可以是空值，也可以是代表某种特殊取包逻辑，比如本地调试。

Q4：location 和 dom 的 location 有关系吗？
A4：没有关系，建议宿主环境在小程序的运行时环境提供 MiniApp URI 的解析结果。

Q5：不支持小程序的浏览器访问 MiniApp URI 时会发生什么？
A5：如果不支持小程序 URI 的解析，那么通常来说，浏览器会交给系统来识别，无法识别则无响应或者提示。如果开发者希望即便是 URI 被不支持的浏览器访问，也仍然能调起小程序的话，那么建议开发者使用一些业界的通用方式，比如 deep link 的方式，调起指定 APP，从而交给能识别并能解析 MiniApp URI 的 APP 来解析。

Q6：为什么是是用 HTTPS 协议下载包？
A6：并未规定下载包，该章节只是一种实践，也可以是用其他协议下载包，或者本地取包等方式。

Testing policy

https://w3c.github.io/miniapp/charters/wg-2020.html

In our draft WG charter, we should include some text about our testing policy.

Here's an example: https://www.w3.org/2019/02/testing-policy.html

Document the changes we made to make MiniApps more web-friendly

Since we have received feedback about MiniApps standards forking existing Web technologies, I think it would be useful to document the changes we already made to make MiniApps more web-friendly (maybe in the FAQ, see also #109).

Relationship between MiniApps and the Web

Clarifying the relationship between the two will help with the standardization. We can discuss this topic in teleconferences and this issue.

Default value for lang in the manifest spec

https://w3c.github.io/miniapp/specs/manifest/#lang

lang specifies the language tag of MiniApp. The value of lang here takes the value of Language-Tag defined in the [BCP47]; please see more details in locales. Default is zh-CN.

zh-CN is an old tag for Chinese used in Mainland China, and should be avoided if possible. I recommend that we use zh-Hans instead (which stands for Simplified Chinese and uses the script subtag instead of the region subtag).

I18N design/architecture unclear

In our teleconference of 2021-01-07, the Internationalization WG actioned me with filing an issue to track discussion of the "internationalization design and architecture of miniapp". In our review of your spec so far and our discussions on various issue threads, it isn't clear how app authors are supposed to create, package, and release apps that serve multiple languages/locales. Some authors may choose to release apps that support quite large numbers of languages. If manifests must be cloned per-language/locale or if information must be duplicated, the result can be brittle (requiring a lot of maintenance) or can bloat application size needlessly.

We also have multiple comments about bidi and language metadata support. We have separately actioned @xfq with organizing additional conversation.

Some questions about MiniApp Lifecycle Draft Community Group Report

是否需要在规范中明确描述如何绑定事件

目前小程序几乎都是以这种方式 Page({onLoad(options) {...}}) 绑定的。现有的方法存在的问题是，用户事件和生命周期事件可能会冲突。

如果需要给出绑定事件的方式，那么需要考虑的因素会更多，比如 App/Page 函数是由哪个规范定义的呢？

是否需要在规范中明确描述事件的参数

通常的 W3C 规范，每个事件都会提供 IDL。

这样，每个事件的参数都需要仔细考虑。

一个子问题是，是否所有的事件应该也继承自一个基本事件类（类似 Event 基类）？

生命周期该包含什么

目前的生命周期只包含了 App.(onLaunch onShow onHide onError)，Page.(onLoad onShow onReady onHide onUnload) 这几个，而目前各个小程序厂商提供的事件都比这个多，那么容易引发问题：生命周期包含事件的标准是什么呢？

另一个小细节是，事件名是是什么？目前小程序写的 onLoad 含义应该是事件回调，所以并不是事件名，所以应该是 load；而这个与绑定事件的方式相关

触发时机与状态

• 规范中，首次 app.onShow page.onShow 的触发不依赖于实际的小程序/页面显示，是否合理？
• 是否应该明确描述所有的生命周期事件触发都是异步的，即只保证先后顺序，不保证是同步的？即，不保证 onLoad 执行完成后同步地执行 onShow
• 某次事件触发，对应于当前小程序的某个状态。触发回调时，除了能拿到输入参数本身，小程序开发者也能间接地感知到这种状态，如通过一些全局的获取当前上下文的 API，比如 getCurrentPages。如果考虑到这些情况，触发时机该如何说明呢？

MiniApp Application Life Cycle

1. develop use case description, 11.29
2. develop draft about application life circle related states, API and feature policies，12.27
3. discuss and update within CG, 1.24
4. finish the CG consensus draft, 3.14

Define a permission model?

Should we define a permission model for MiniApps and corresponding APIs?

Related docs:

MiniApp Manifest

Spec: https://w3c.github.io/miniapp-manifest/#req_permissions-member

W3C

Web pages/applications

Specs:

• Permissions
• Requesting Permissions
• Relinquishing Permissions
• Permissions Policy

Query a permission using the navigator.permissions.query() method to return a promise that resolves with the status for a specific API.

Extensions

Docs: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/permissions

permissions.request() asks for a set of permissions.

WeChat Mini Programs

Docs: https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/authorize.html

Use wx.getSetting to get the user's current permission settings (only for the permissions the Mini Program has requested before).

Use wx.authorize to ask for a set of permissions.

ByteDance Mini Programs

Docs: https://microapp.bytedance.com/docs/zh-CN/mini-app/develop/api/other/user-authorization/

Use tt.getSetting to get the user's current permission settings (only for the permissions the Mini Program has requested before).

Use tt.authorize to ask for a set of permissions.

"Super applications" in the charter

https://w3c.github.io/miniapp/charters/wg-2020.html

To enhance the interoperability between MiniApp platforms and the Web, and between different MiniApp platforms (including super applications and native operating systems)...

We should explain/define "super applications" here.

Mention DID WG in the Coordination section of the charter?

https://w3c.github.io/miniapp/charters/wg-2020.html#coordination

Should we add the DID Working Group in the Coordination section of the charter?

They're working on the DID URI scheme, so we can probably learn from their experience when designing our URI Scheme.

MIME media type

We may need a MIME media type for mini app packages.

Do we really need 'app' as the root folder?

The MiniApp package can just contain the files (and subfolders) at the root level directly, without the need of an wrapper folder 'app'. Can we simply remove the 'app' folder?

[charter] Use new patent policy

https://w3c.github.io/miniapp/charters/wg-2020.html

Section 8 of the proposed charter refers to the old (2017) patent policy. It should be upgraded to refer to the new 2020 Patent Policy.

The only part of the text that needs to change for this is to replace

(5 February 2004 Version updated 1 August 2017)

with

(15 September 2020)

Add new REC-track deliverables without rechartering

In our meeting yesterday we decided that the group can add additional in-scope REC-track deliverables without rechartering and add a paragraph in the charter about this.

Mention CG in the Coordination section of WG charter

https://w3c.github.io/miniapp/charters/wg-2020.html#coordination

We should add the CG as a liaison of the WG.

Handling of `lang` [I18N]

lang
https://w3c.github.io/miniapp/specs/manifest/#lang

lang specifies the language tag of MiniApp. The value here takes the form of Language-Tag as defined in the [BCP47]. The default value is zh-Hans. If not specified, the default value is used.

The English here may need further attention, since it is unclear what the "language tag of MiniApp" means. The value section should probably use some of the conformance language from BCP47.

I understand why the default value is zh-Hans--it is for historical reasons, due to the origins of MiniApp, but this may not make sense as a long term default. While CJK users do need the most display processing help, it might be better to say that the default value is undefined or the empty string, as this may help non-Han languages get better general performance.

Implementers should be encouraged to provide accurate language metadata and this value should match that of the manifest content.

I'd suggest this edit:

lang specifies the default language of the MiniApp manifest's contents. The value here MUST be a well-formed [BCP47] language tag.

MiniApp URI scheme proposal plan

We will give the first draft on November 4, 2019 and consult the internals comment and revision in the next month;
We will complete the second draft on November 29, 2019 and ask for the external advice in the next month;
At last, we will complete draft proposal on December 27, 2019

Chinese translation of "smart assistant" in the Glossary Section

miniapp/white-paper/index.html

Line 666 in 4d09d67

<td>负一屏</td>

Shouldn't it be "智能助理" ?

[charter]: suggest to use positive words

in the current draft charter 'success criteria': "APIs that cannot be demonstrated to be implementable securely will not be released."

How about changing it to: "APIs shall be demonstrated to be implementable securely before released"

Comparison of MiniApp Lifecycle with related work in W3C

It would be good to add a comparison with some related work in W3C (such as Page Visibility and Page Lifecycle) as an appendix in the spec or explainer.

Charter: explain relationship with WPACK

https://w3c.github.io/miniapp/charters/wg-2020.html

Make it clear how this relates to WPACK work and why a separate standard is required.

Unicode support for appName

https://w3c.github.io/miniapp/specs/manifest/#appname

MiniApp name may be composed of Chinese characters, English letters, numbers and some specific symbols

Is there any reason for not allowing other Unicode code points (except for the code points that must be escaped, like quotation mark or reverse solidus)?

---

Edited to add another point:

and its length must be between 4–30 characters.

If we want to limit the length, I would suggest that we explicit mention the type of unit we limit (i.e., Unicode code points). "Character" is a very vague term, and one "character" is not always one Unicode code point.

Spelling of "Mini App"

We discussed the English name in w3c/chinese-ig#152 , but didn't discuss the orthography / usage guide of the term.

Currently in our documents, there are the following usages:

• MiniApp
• MiniApps
• Mini App
• miniapp
• miniapps
• mini app
• mini-app

We may need to unify the usages. Not necessarily to use the same spelling/casing in all cases, but it would be useful if we define some rules/guides.

Charter: will platform operations need to be in scope?

I imagine that some security and privacy mitigations will be easier to make operationally than in protocol. Would you prefer to leave operations in scope, to allow for those? Or do you want to be constrained to making those mitigations in protocol?