Meeting minutes
angel: first item today is to introduce the new CG co-chairs
https://
angel: the current co-chairs had some discussions
… some of the CG co-chairs will resign and move to the WG
… we made some rough consensus that Keith from Google will continue to be co-chair
… we will have three new co-chairs
… they're all very actively participating in the CG
… Dan Zhou from Baidu, Qing An from Alibaba, Yongqing Dong from Xiaomi
[The new chairs introduce themselves]
angel: I'll happily hand over to the new co-chairs
QingAn: from the email sent by angel we discussed some new ideas
https://
https://
Qing_An: we had four initial ideas
… IoT
… UI components
… the introduction and invocation of system capabilities
… the management and loading mechanism of page application container
… proposers can file issues on GitHub
<xueyuan> see GitHub issues list
MiniApps for IoT
https://
QingAn: since IoT devices can run miniapps
QingAn: we can define some client-side API in MiniApps for IoT devices
… similar to Devices and Sensors Working Group
… I listed some possible items
… xfq has provided some comments
… we can discuss how to move this forward
… in our meeting last July we discussed IoT APIs
https://
Qing: not sure what's the next step
… where is the right place to discuss this
martin: any existing use case in mind?
… about how MiniApps are used with these hardware interfaces
… I agree with xfq's issue comment, we should explore the potential relation with the WoT activities. is related to WoT
… I think miniapps focus on user interaction and WoT focuses on @@
… I suggest to understand the needs
… do you have any use cases/scenarios in mind?
QingAn: I can provide some detailed info later
… these APIs are used in IoT environments
… because of this logic we think they can be standardized
… we need a unified way to @@
… xfq has shared some related work about Web GPIO API and Web I2C API
… this work is related to WoT and DAS WGs
… we can try to have some conversion about common use cases in web and in miniapps
… whether IoT MiniApps can use existing specs
… or define new APIs for miniapps
QingAn: at this moment I think this is an collaboration opportunity to work with different working groups
martin: thank you
… look forward to this work and very willing to help
xfq: agree with martin
… we need to document our use cases and requirements
… we can have conversation with relevant existing groups
QingAn: maybe to send this issue to related groups first, to trigger the discussion and talk about potential use cases?
xfq: ok, will do.
Canfeng_Chen: I agree with Martin
… we need to clarify use cases, since different people have different understanding of IoT
… we listed bluetooth but not wifi
… are these low-level APIs really needed by developers?
… personally I don't think developers need to know I2C or SPI
QingAn: we can have further discussions and communicate with WoT groups, to figure out whether low-level APIs like GPIO and I2C are needed
MiniApps for TV
https://
<martin_> One use case could be running a MiniApp on a edge device (kind of Raspberry Pi, Arduino,..), accessing the GPIO, I2C, etc.
QingAn: related to CSS
… maybe we can have a joint meeting with CSSWG to see if we can use CSS
… xfq has provided some existing work
… I'll see whether existing work can satisfy our needs
… we can check with CSSWG and MEIG
… I saw xfq mentioned UI Events KeyboardEvent key Values and UI Events KeyboardEvent code Values
… what's the current status?
xiaoqian: still active, being implemented in Chrome
… blocked in CR because we don't know how to test the spec
… if you would like to refer to the spec, I think it's still valid
… if you want to talk with the editors I'm very happy to help
QingAn: if they can't fully satisfy our requirements we can provide requirements
… we can have discussions with CSSWG
xiaoqian: I agree that can be a starting point
Qing: any further comment on this issue?
[silence]
Ideas from Yongqing
https://
QingAn: Yongqing?
Yongqing: I wanted to draft ideas about introduction and invocation of system capabilities
… but I'm not sure if it's necessary to write it down
… not sure if we can unify it in various MiniApp implementations
… that's the reason I didn't write it down
QingAn: we can have something in a github issue as a starting point and discuss it
Yongqing: will talk to you after the meeting and write it down
Ideas from Tengyuan
tengyuan: we had conversation with Google
… Google wants to use WPACK and is unlikely to support two different package formats
… we should think about this
… @@
… different distribution channel
<tomayac9> Some more background on this: https://
QingAn: any further comment on this agenda item?
<tomayac9> There is work happening around Resource Bundles in https://
QingAn: any further ideas?
tomayac9: resource bundles
… one question: if MiniApps should use WPACK
… if you read their FAQ
… it mentions the MiniApp use case specifically
… I'm not fully informed about the complete details between resource bundles and WPACK specifically
… resource bundles is developed in the context of WPACK
<tomayac9> (Better link for the FAQ: https://
QingAn: Yongjing had some comparison about MiniApp Packaging, WPACK, and other packaging technologies
… any comment from Yongjing?
Yongjing: haven't checked the details of Resource Bundles yet
… we should take a look and provide some feedback
MiniApp i18n
[zitao shares his screen]
zitao: @@
… i18n WG has raised some issues on github
… if we want to deploy a MiniApp in different languages we need multiple manifest files for different languages
… one manifest per language
… the i18n WG may think there are duplicate info
<tomayac9> A similar issue was raised in the Web App Manifest repo: https://
zitao: three ways to address this issue
… first is multiple manifest, i.e., one manifest per language
… compatible with Web App Manifest
… if the developer wants to use another language they need to change the manifest
… @@ language negotiation
… the second way is the JSON-LD way
[Intorduce the JSON-LD way]
zitao: this may be the solution the i18n WG recommends
… properties are represented in RDF semantics
… but has additional complexity
… and not compatible with Web App Manifest
… the third way is to refer to i18n string resources
[Introduce the third way]
zitao: $string:<resource-name>
… currently I think the third way is the good way
… if you think this makes sense I can upload the proposal to GitHub and we can discuss with W3C i18n WG
tomayac: I pasted a link on IRC
… on the Web App Manifest front there's a similar problem
… initially for dark mode
… about the media attribute
… also related to multiple languages
… I don't think we have a solution yet for Web App Manifest
… we're still discussing it
… I mentioned it here since we would like to align MiniApp Manifest and Web App Manifest
QingAn: thanks zitao and tomayac
… we can discuss in a GitHub issue and refer to the Web App Manifest issue
… any comments?
<tomayac> Yes, please do! Thanks.
[silence]
Next teleconference time
March 25, same time