See also: IRC log
<xiaoqian> zhiqiang: [going through the agenda]
<xiaoqian> scribe: xiaoqian
Song: co-editor of the proposal, another editor is from Bilibili
... we also invited the experts from Niconico
... 1. difference from between subtitle and bulletchatting
... subtitle is usually coming from words of the actors
... or description about a certain scene
... bulletchatting is more about the comment incentive by the content of the video
... to express the emotion of the audience in real time
... to share the feeling about the same scene of the video
... users can send out the bullet chat at the same time as they watch the video
... subtitle is usually displayed in 1-3 lines
... the display area is fixed in the video
... bullet chat can show up in any row of the video area
... and it's usually moving from one side to another side
nigel: regarding the presentation, what's the difference between the two?
... especially the text overlap
... it's not technical limit, more editorially
Song: the present mode
... subtitle is usually static
... bullet chat can interact with the users
... more dynamic
... text direction
... TTML aims to define a format for subtitle
... it describe the show-time, the display style, the position and the content
... while bullet chat, is to help implement bullet chat in the Web
... we would like to have it as an HTML element, it'd be nice if it can help define the attributes and events about the style, the position, time, and content
xfq: it tries to describe the attributes and events to help implement those use cases that are not covered by TTML
atai: from the current statics, which spec are you targeting when you analysis the gap? the HTML spec?
... what kind of applications do you think will be the major vendor for this API or element?
Song: not sure yet, need more conversations with the other companies
... but there are hundreds Webapps companies working on bullet chat in China and Japan
... with very different implementation
... we may not be about to cover all the use cases
... would like to design an API or element which can be extensive
... f.ex., the AI masking cases
atai: whether HTML element is necessary may be a different question
Song: agree
Glenn: so it can also be a JS library
... a lib including the queue objects
... have you considered that option?
Song: some of the companies may be implementing with JS lib
... but it must be with some limits so they are asking for an extra standardised API
Glenn: A JS lib can be a good starting point if it gets consensus from the other players
Song: our co editor and my engineers team really hope to standardise the bullet chat
... but from the discussion this week, we also see the potential to reuse the current technologies
... we would like to have an element which describes the control for show area, time, delay, styling
Eric_Carlson: if I understand correctly, there is also requirements that are not covered by the WebVTT and TTML
Nigel: animation?
Glenn: we have animation, but we would love to hear more requirements for bullet chat
... if both solution are too heavy way
... you can consider a light way of implementation
Lin: current limitation is more on performance as they are using CSS and JS
... so they would like to have an API to ease the implementation
... requirements including animation, speed control, font-style
... it's more about how to make things easier
atai: thank you for the introduction over the week
... it seems you already have the technology to solve the problem
... what you want now is introperability
... if your application is trying to solve the same problem as WebVTT and TTML?
... it will be successful to bring the an new format if it can help the implementation easier
Glenn: it will be helpful to show some demo
Song: the problem now is I don't think any developers is using the WebVTT and TTML to implement it
... next question is about the layout to display the text
... our point of view is how to display the bullet chat with markup
... what is really needed is the element to represent the bullet chat
nigel: when you send the bullet chat, do you send everything to the client? or just the content?
xfq: I think there is lots of possibilities in the implementation from different companies
Michael_Li: the rendering calculation is done in the client side
... so we need to send all the necessary things
... but we also see potential to improve this implementation
nigel: that seems to be an important things to agree on
Song: bilibili also mentioned the key to extent the bullet chat on top of any existing technologies is live transportation
... as one of the important use case is live streaming or live events
... so we need to log the elements in real time
... for the on-demand playback, if User A is watching at 10', and User is watching at 5', both of them can send a comment at the same time
... the system needs to accept the comment and generate the bullet chat in real time
... so when User B arrives at 10'
... he can see User A's comment for 10'
[demos from Niconico]
Michael_Li: demo about the scrolling of content
... users can play art works with bullet chat
... the styling can but sync with the music
... if I slow down the play speeds, the comments also slow down
... you can also do crazy things with unicode letters
Eric_Carlson: so you may still need JS to do this kind of effect even you have a file format
<nigel> niconico example
<xfq> description by niconico: https://rentry.co/bgc5h
Michael_Li: we would be happy to accept what can be standardised if it's helpful
... not necessary to cover all the use cases
Eric_Carlson: so you would like to standardise something that can reduce the JS work
... f.ex., we want to standardised in our work whether it's playing or not, the current time of the element
nigel & plh: it can also be helpful for a11y
nigel: I haven't get a clear idea where the work should happen
xfq: it would be helpful to create a communicate channel
[another demo about the champion cup of world game]
song: there can be different layout of the texts
<nigel> Bilibili example
<xfq> zhiqiang: maybe we need to set up a regular communication channel to discuss more details in the future
<xfq> xiaoqian: we can create a CG
<xfq> ... invite Chinese IG editors, Japanese companies, timed text people in W3C etc.
Bobby: I'm Bobby Tung, from Taiwan, i18n invited expert, working on CLReq
... our last Chinese discussion was 6 yrs ago
... CSS Writing Mode
... resolved to move to PR in this TPAC meeting
... L3
... it started from 2010
... it's very important to CJK and mongolian
... it will be a great help to Japanese, Mongolian, and old books
... [stories about the editors and the spec]
... actually, it comes from the JLReq
... JLReq started from 2007
... Richard contributed a lot the work
... back to 1984-1985
... Mac-Aides Pagination-Adobe, want to explore the market in Japan
... the engineers needed help from the publishers on typewriting
... JIS X-4051:2004 from 1993
... so they invited experts from the industry to work on a very detail document for typewritting
... to properly display the Japanese language
... they started from writing mode, Ruby...
xfq: Ruby started from 1998
Bobby: 1998, XML was the popular language
... librarian wanted to storage the books digitally
... when it came the HTML5 and CSS3
... in 2014, W3C published the HTML5.0 REC
... dpub-er would like to have a format other than kindle
... publishers have explored lots of possibilities
... then people agreed on solution with the Web technologies
... then we have problem, for the full-width and half-width
... there is some differences in Traditional Chinese and Japanese according to the national standard
... then I realised it's a common problem for the W3C i18n IG, unicode C
... for example, in Japan they changed the name of the year starting from 2019
... there is not document to record the layout differences between the Japanese, Traditional Chinese and Simplified Chinese
... so I wrote down an initial draft of CLReq based on the TC requirements
... we got support from W3C in 2013 to started the CLReq TF
... it's a document with 3 language version
... Yijun knows well about SC and TC
... Eric speaks both Japanese and SC
... Hui Jing comes from the Singapore community
... fuqiao is also pushing for teleconfs
... one issue is how to avoid hanging punctuation at the beginning of the line
... modern Traditional Chinese in Taiwan is complicated
... some punctuations is acceptable as the starting point in Traditional Chinese
... some experts is keen of the idea to keep every Chinese character in a unique cell
... Traditional Chinese is actually looser than Japanese in some of these details
... Eric is hosting a Type is beautiful project to identify these kind of features
... another important topic is Ruby
... we usually put a tone on the top of the Romanization
... Xidorn implemented a very unified Ruby in Firefox based on the standard
... while another engineer in Apple implemented Ruby in a very different system
... Eric is collecting requirements on Ruby
... we are also exploring the next step of Ruby
... we hope to collaborate with all of you
Zhiqiang: is there any new requirements in CLReq which is not included in JLRep?
Bobby: no, but if you are going to support just Chinese in your system or application
... you can implement a looser layout system
... also we want to document the requirements for Chinese
Qingqian: anything we can help from the Chinese IG?
Bobby: it'd be nice if you can help complete the data in CanIUse about layouts
... please also file bugs to Chromium and Webkit if possible
<xfq> bobby: in the past we can only contact the implementers to feedback on Chinese layout issues
<xfq> ... japan has been pushing electric textbooks recently
<xfq> hax: Chinese reader application developers may also provide input
<xfq> ... like Tencent
<xfq> ... in narrow screens prohibition rules for line start and line end might be different, for example
<xfq> ... currently it's only in some products
<xfq> ... but not in clreq
qingqian: would like to give an update of the progress
... explore the possible next step
... if everyone knows the previous discussions, let's skip this part
... we, with the other vendors, have been working on a WhitePaper
... we have received feedback from the Chrome team and the TAG
... breakout presentations this week
... the TAG suggested open the content of MiniApp to allow discovery of the search engine and other systems
... and to collaborate with the other W3C APIs and groups
... in the AC meeting, Judy presented it again to the AC Reps
... TAG provided a formal review comments to MiniApp
<angel> https://www.w3.org/community/miniapps/
Zhiqiang: in the Breakout session, they also suggest us to interoperate with the current APIs, f.ex., the manifest
Qingqian: let's focus on the workable items for the next step
... for those things we agree to standardise
... 1. those features needed only by MiniApps
... we can start incubating the proposals
... 2. the existing Web APIs, but with different interface in MiniApps
... we shall submit requirements to W3C
... one issue maybe the MiniApp vendors will think W3C groups are too slow
Zhiqiang: we can take a subset from the existing APIs, f.ex., Manifest
Qingqian: we should be open-minded on this
... as the vendors also need to consider business requirements
... I'm proposing everyone to look at the Manifest API
... to see if we can use it as a solution of MiniApp
... another idea is the Web Packaging
Zhiqiang: what do you mean by packaging?
Qingqian: the structure of the files, how to compress it
... I think the current format isn't very dev-friendly
Zhiqiang: so we need to define the format and how to export the package
Qingqian: let's also figure out how to collaborate on these APIs
Zhiqiang: Package, Manifest, URI... I think these are important starting points
Qingqian: we need someone to take actions
Zhiqiang: I'm also hoping we can open source the implementations
Qingqian: TAG commented URI is necessary if MiniApp wants to run on the Web
... as the Web relies on origin
... can we reach consensus on a few important proposal today?
Hax: most vendors also have it, but it's not open to the developers
Zhiqiang: most of them have a private protocol
Qingqian: most of the MiniApps of Baidu works on the browser
... f.ex., domain is smartapp/
... but it's not the ideal implementation
... technically it can be shared to other platform, but with bugs
... we want to use runtime to convert it to a unified URI
... so it can discovered by the Web
Zhiqiang: it will be tricky if we want the apps to be validated
Qingqian: we can create a runtime to approve the MiniApps on a white list
Zhiqiang: would like to discuss the detail of URI
... every vendor requires MiniApps to be validated
Qingqian: 1. we need a URI for each MiniApp; 2. user can only access those MiniApps validated by the vendor
... this is not conflict
Zhiqiang: most users don't usually visit a MiniApp with URI
... what's the point of having a URI?
chumming: to share a MiniApp?
Zhiqiang: makes sense
... f.ex., if an application have published a feature for different MiniApp for different platform, it's going to be using the same URI or a different one?
hax: same domain name with different URIs?
Qingqian: similar to open a file in the OS
Bowen: will it be possible MiniApp are only kept in a platform?
Qingqian & Zhiqiang: it's not practical
Qingqian: it may be possible with Web Packaging
Zhiqiang: signature is necessary for every MiniApp
Qingqian: signature after a unified URI?
... who will be rule maker for the signature?
... now it's decided by the platform
hax: it'd be nice to have a unified signature
Zhiqiang: so URI is common requirement for us
Qingqian: agree
... we are willing to lead the effer
<scribe> ACTION: Qingqian to talk to other vendors to standardise URI of MiniApp next, Manifest [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
<scribe> ACTION: Zhiqiang to lead the researching of Minifest next, packaging [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
<scribe> ACTION: Alibaba to lead the work on packaging next, widget [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
<scribe> ACTION: Xiaomi to explore the standardising work on Widget individual APIs every vendor should submit their own requirements to W3C [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
<scribe> ACTION: fuqiao to help coordinate the single API proposals [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
<xfq> https://www.w3.org/community/miniapps/
UNKNOWN_SPEAKER: Chaals helped us to create a CG
... shall we have co-chairs for the CG?
[angel explain difference between CG and IG]
angel: CG can help us communicate with a broader community
Zhiqiang: I think another important proposal is lifecycle
... it defines the minimal requirements to run a MiniApp
Angel: please incubate all the proposals in the CG first
Zhiqiang: let's figure the minimal features of a MiniApp first
qingqian: agree, and to extend other features in the future
Zhiqiang: correct, packaging, manifest, lifecycle, basic APIs
Anqi: if something is within a scope of an existing WG, lets have the work there
Zhiqiang: can we open-source those minimal features?
Qingqian: +1 from Baidu
QuickApp vendors: we haven't reach the point yet, but will try
qingqian: signature is a sub-feature of packaging, but with a lot of business consideration
... let's explore the possibilities to standardise it
Juejia: good discussion today!
Angel: work mode of the CG
... monthly call of the CG
... each TFs can have its own communication channel
chaals: present your proposal to the WICG once it's ready
... get broader review from them
<chaals> [No need for it to be ready, just that you agree to work on something, and then they can give you a repo. Or you can use your own repository e.g. in miniapps CG]
Angel: we shall aimed at a WG to publish the minimal features for patent policy
... update every 12 months
... when we have finish the first version of each MiniApp features
Juejia: we would like work with the Web and W3C
... leader of each TF should keep this in mind
Angel: agree
RESOLUTION: Reuse the MiniApp-whitepaper repo, rename to MiniApp
... we should keep using the name MiniApp
chunming: mission of the CG or WG?
... to have a standardised display or interaction of application on the Native Apps and the Web?
... clearly document the scope
Angel: MiniApp should be an extension of the Web Apps
Chunming: lets try not to over emphasis the difference of MiniApp to the Web App
Chaals: tell them, you want to standardise Web App in a package
... MiniApp is a PACKAGE!
xiaoqian: next question, shall we publish documents in English or in Chinese?
RESOLUTION: Proposals should be published in English
Angel: we also need to create a mailing list
Wanming: APIs needs two independent implementation
... can we have MiniApp vendors as implementation as well?
Qingqian: we only need implementation from 2 MiniApp vendors
others: agree
Xiaoqian: how do you define independent?
Zhiqiang: we are using different render engine
chaals: for implementation, what you need to show, it's to show it's widely accepted
... if you have a device API, and there is another API in W3C
... you have a problem
<chaals> [we have mailing list public-miniapps@w3.org archived at https://lists.w3.org/Archives/Public/public-miniapps/]
<chaals> … because if most of the web is going to use another API for the same thing, then you don't meet the conditions, and need to explain why we should have two different APIs. Easier to make sure the other API meets your needs, usually
Wanming: we would like to work with the MiniApp community
Qingqian: would you consider runtime implementation for MiniApp?
Wanming: as only there is any need for Desktop
Xiaoqian: decision policy?
Angel: we are a small group
... I proposed major consensus, no formal objections
... majority = more than 2/3
... vote from at least 2/3 vendors, and representative from developers
... number of representative from developers = 1/3 of the number of vendors
Chunming: I propose we only need consensus from vendors
everyone: no, we need input from the developers
Angel: proposed: 2/3 vendors + reasonable amount of developers
RESOLUTION: decide when a proposal is ready to ship to WG - 2/3 vendors + reasonable amount of developers
<scribe> ACTION: Angel to draft a charter of the CG [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
Anqing: vendors include browser vendors
angel: we don't need to consider FO because it's just a CG proposal
RESOLUTION: 2 co-chairs at the creation of the CG, and we can add chair when we are clear about the tasks
<scribe> ACTION: Angel will propose a draft charter by 1 Oct and ask for review [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
RESOLUTION: first teleconference in Mid Oct
Angel: timeline for each TF?
Qingqian: too early to decide
chaals: teleconf in English or in Chinese?
Angel: one round in Chinese, one round in English
Qingqian: let's run it for a while and improve as time pass by
<chaals> +1 to Qingqian
Angel: we spent 3 months on the WhitePaper
RESOLUTION: stop working on the WhitePaper, create a FAQ wiki in the repo instead
<scribe> ACTION: Chaals to find the TAG review comments [recorded in https://www.w3.org/2019/09/20-Chinese-Web-en-irc]
https://www.w3.org/community/miniapps/
Join the MiniApps CG! ^^
<xfq> https://w3c.github.io/mini-app-white-paper/comparison.html
Hax: can we keep updating the comparison document?
Wanming: sure, but need support from the vendors
Hax: great, it's a great help to the developers
Wanming: we can add data of those proposals and specs Alex proposed
Angel: feedback for TPAC 2019?
Zhiqiang: we made good progress on 3D Element
Xiaoqian: we should create a new CG for bullet chat
Angel: are you satisfy with the progress as we are in the second year of Chinese IG?
... my own thinking is it's very important to communicate with the other members before the session
... to reduce objection and doubt from the foreign companies
<xfq> scribenick: xfq
angel: talk with the relavant people before the meeting is also helpful
chunming: re breakout session
... we need to be careful about the wording "this is unique requirement from China"
... it can be used in other parts of the world too
... we can also talk about our proposal (next step) during our breakout sessions
zhiqiang: there were lots of discussions in the HTML 3D element breakout session
xiaoqian: potential next Chinese IG F2F topic: AR/VR
... propose early next year, after Spring Festival
... would be good to hold it before AC 2020
qingqian: face tracking scenarios
bobby: any interest in CSS from Chinese companies
... I think attending CSSWG meetings is a good opportunity for learning
chaals: you should talk face tracking with PING
... it has privacy implications
... talk to PING about what can be done, and what can not
hax: re CSSWG
... 360 has people interested in (and following) work in CSSWG
... although most people use libraries and frameworks
... there are people *working on* those libraries and frameworks, and need to learn new CSS features
xiaoqian: some people thinks our white paper as standards
... do we need to clarify?
bobby: some journalists do not know our work
... and wrote articles with somewhat hostility
angel: maybe we can write blog posts
... this is the first F2F for us in TPAC
... hope we produce more stuff next year
... maybe a longer F2F
... thanks for all of your hard work!
... there wasn't many Chinese people in TPAC a few years ago
... in the future there may not be a need for a Chinese IG
... we can work in W3C working groups when the Chinese community is mature enough
... also thanks a lot for support internationally
... including people attending this meeting
bobby: LG worked on Android Wear a few years ago
... proposed CSS Round Display
... it's can be used in iPhone X now
... hope we can incubate our technical proposals in a similar way