Meeting minutes
Projects Progress review
angel: let's go through the current status of the 4 proposals
… first is URI scheme
https://w3c.github.io/miniapp/specs/uri/
DanZhou: added a new section
… "使用 HTTPS 协议作为下载小程序包的网络协议" in https://w3c.github.io/miniapp/specs/uri/#https
… a non-normative section on how to download a miniapp package
… added a new use case
… "在一个小程序内使用 MiniApp URI" in https://w3c.github.io/miniapp/specs/uri/#x1-miniapp-uri
… and a few editorial fixes in other sections
[DanZhou goes through https://w3c.github.io/miniapp/specs/uri/#https]
DanZhou: https is recommended but not required
… other protocols are also allowed
angel: When will the first complete draft be completed?
danzhou: I think it is already a first complete draft now
angel: we'll review it within the CG for 2-3 weeks
… and submit it to relevant W3C groups for horizontal review
DanZhou: we will translate it into English with the help of W3C
angel: any question?
DanZhou: there were some questions in the last meeting
… I filed a GitHub issue for that
… https://github.com/w3c/miniapp/issues/20
angel: let's go to manifest
https://w3c.github.io/miniapp/specs/manifest/
shouren: I added a few sections since last teleconference
… including dir, lang, icon, widgets
… added a packaging section
… dir and lang are the same as web app manifest
… a miniapp can contain pages and/or widgets
… widget and mini app share some manifest properties
… the 'widgets' property contains 'name', 'path', and 'minPlatformVersion' properties
… we can add more in the future if needed
… on packaging
… https://w3c.github.io/miniapp/specs/manifest/#packaging
… referred to various mini app implementations when designing it
… first, there is a manifest.json file, an app.js file, and an app.css file in the root level
… app.js manages the global miniapp lifecycle
… app.css specifies the global styling
… every page has its own lifecycle
… the example manifest.json file was also updated
… https://w3c.github.io/miniapp/specs/manifest/#example
… any question?
angel: timeline of the proposal?
zhiqiang: this is currently a relatively complete first draft
… a few points might need discussions
… including widgets
… any comment on the relationship of mini app and widgets?
… currently one miniapp can only contain one widget
… any use case for multiple widgets in one miniapp?
yinli: packaging itself is not a big issue
… but a package should be able to contain zero or one or more pages, and zero or one or more widgets
zhiqiang: ok, then a miniapp can contain more than one widgets
yinli: a widget is like a page running on other hosts
zhiqiang: what's the distribution method of widgets?
yinli: widgets and pages can be split into two packages or combined into one package
… two widgets can also be split into two packages or combined into one package
yinli: for example, if we have a weather widget, we can design a widget for the voice assistant and a widget for the smart assistant
… these two widgets can be in the same package
… but if there are major differences between the two widgets, it is better to try to separate them into two packages
… for example, for Didi (private car hailing), we can have one widget for calling a car and another widget for the status of the current trip
… it depends on the requirement of the app developer
zhiqiang: I see
… can we describe this in the proposal?
yinli: yes
… I can add more description on the multi-widget use case
zhiqiang: thank you
… we can also update the relavant part in the manifest
yinli: different widgets may have different hosts
… so we may need a property describing the host
… about which host hosts the widget
… need to think about this more
zhiqiang: alternatively, we can control this in the host side rather than in the manifest side
yinli: about window https://w3c.github.io/miniapp/specs/manifest/#window
… can you add a table?
zhiqiang: yes
Qing: a few questions
… Packaging is in the manifest spec now
… I suggest that we write this in a separate document
Qing: is just defining the project directory structure enough?
… or do we need to define the built directory structure as well?
zhiqiang: the first step is to define the "not built yet" directory structure
… because there may be implementation-specific optimizations for the built directory structure
… for example, a .js file may not be a .js file after compilation
DanZhou: https://www.w3.org/TR/widgets/
… this document contains both configuration and packaging
… so the spec title is not manifest
zhiqiang: If there is no objection, we will divide this document into two
… but the two document is related
chunming: this is a good start
… on the relationship between this manifest and the W3C web app manifest
… I just compared the properties on the two documents, and a few properties are the same
… I think it would be useful to add a comparison table as an appendix or some other form
… and rationale on the differences of the two documents
… also, all other properties are in singular form, only 'widgets' is in plural form. Any reason for that?
zhiqiang: there can be more than one widgets
… we can add a a comparison table with ratioinale indeed
… but the priority now is to refine the document content
DanZhou: specifying packaging in the manifest spec is strange indeed
… is the package a ZIP archive or some other format?
DanZhou: need to specify it
… versionName vs versionCode
… which should I use?
shouren: versionCode
… versionName do not change often
DanZhou: can we change appID/appName to ID/name?
angel: we can discuss this in GitHub issues
angel: next is lifecycle
https://w3c.github.io/miniapp/specs/lifecycle/
<chaals> [+1 to Chunming on a comparison table for miniapp manifest and W3C webapp manifest]
Qing: No major updates on the document
… I'm not sure if I need to write some implementation details
… any comment?
@@: I think some implementation details are needed
<Chunming_> one possible solution of appName/name is , name (alias appName), compatable with name in WebAppManifest
xiaoqian: we can refer to the Service Worker Lifecycle and Page Lifecycle in WICG as well
yinli: widgets and lifecycle @@
Qing: we can discuss this offline
angel: next is widgets
<xiaoqian> https://www.w3.org/Member/wiki/MiniApp/widget
yinli: https://www.w3.org/Member/wiki/MiniApp/widget (will sync to github after the meeting)
… I added more detailed descriptions
… including the user agent of the widget
yinli: The styling on the widget and user agent should be consistent
… so some information on the user agent (such as dark mode) needs to be exposed/synchronized to the widgets
[yinli goes through the document]
yinli: more detailed description on URI and packaging
… editorial fixes on the manifest section
… no change on the lifecycle section
yinli: I made the document easier to understand, and added some examples
angel: Do we still need major changes to the documents?
yinli: I don't think so, but some editorial changes are still needed
DanZhou: The organization of this document is not clear enough
yinli: this is a requirement document
yinli: Widgets cover a wide range of technologies, so we want to sort out the requirements first, thus the requirements document
DanZhou: any further plan?
yinli: For the different requirements of the widget, we will write the corresponding documents, or update existing documents
angel: any further question?
… regarding the URI scheme document, can we start CG internal review?
DanZhou: OK
xiaoqian: I suggest that we start CG internal review after translating the document into English
Angel: we can begin the review for the Chinese miniapp vendors earlier
… regarding manifest, we need two weeks for updating the document and split the packaging part
… regarding lifecycle, if we need to add some implementation details, how long does it take?
Qing: two weeks
CG Report for AC2020
angel: I'd like to report this as part of the Chinese IG update in AC 2020
… I hope that everyone can make more progress before AC 2020
Next meeting
angel: next meeting, March 12, 9:00 AM Beijing time
… we can discuss issues in GitHub
xiaoqian: it would be good to update the documents in GitHub directly
xueyuan: Can we start the translation right now and then update the English version?
Angel: I suggest we wait a little longer
… translate URI scheme first
… and translate other documents after two weeks
… thanks all!
[adjourned]