w3c / miniapp Goto Github PK
View Code? Open in Web Editor NEWMiniApps Standardization
License: Other
MiniApps Standardization
License: Other
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.
We need a privacy and security considerations section.
References:
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:
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?
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.
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.
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.)
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.
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
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.
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:
The disadvantage is that if we have too many repos, it is not easy to manage the repos.
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
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.
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)
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.
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.
https://w3c.github.io/miniapp/specs/manifest/#dir
The dir member in Web App Manifest has an auto
value. Do we need this?
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.)
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.)
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?
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
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:
https://w3c.github.io/miniapp/white-paper/
We mentioned "super-app" a few times in the document, but didn't define or explain it.
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)?
This issue tracks the status of our TAG review.
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."
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:并未规定下载包,该章节只是一种实践,也可以是用其他协议下载包,或者本地取包等方式。
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
Clarifying the relationship between the two will help with the standardization. We can discuss this topic in teleconferences and this issue.
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).
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.
目前小程序几乎都是以这种方式 Page({onLoad(options) {...}})
绑定的。现有的方法存在的问题是,用户事件和生命周期事件可能会冲突。
如果需要给出绑定事件的方式,那么需要考虑的因素会更多,比如 App/Page 函数是由哪个规范定义的呢?
通常的 W3C 规范,每个事件都会提供 IDL。
这样,每个事件的参数都需要仔细考虑。
一个子问题是,是否所有的事件应该也继承自一个基本事件类(类似 Event 基类)?
目前的生命周期只包含了 App.(onLaunch onShow onHide onError),Page.(onLoad onShow onReady onHide onUnload) 这几个,而目前各个小程序厂商提供的事件都比这个多,那么容易引发问题:生命周期包含事件的标准是什么呢?
另一个小细节是,事件名是是什么?目前小程序写的 onLoad 含义应该是事件回调,所以并不是事件名,所以应该是 load;而这个与绑定事件的方式相关
Should we define a permission model for MiniApps and corresponding APIs?
Related docs:
Spec: https://w3c.github.io/miniapp-manifest/#req_permissions-member
Specs:
Query a permission using the navigator.permissions.query()
method to return a promise that resolves with the status for a specific API.
Docs: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/permissions
permissions.request()
asks for a set of permissions.
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.
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.
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.
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.
We may need a MIME media type for mini app packages.
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?
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)
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.
https://w3c.github.io/miniapp/charters/wg-2020.html#coordination
We should add the CG as a liaison of the WG.
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.
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
miniapp/white-paper/index.html
Line 666 in 4d09d67
Shouldn't it be "智能助理" ?
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"
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.
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.
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.
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:
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.