<Chunming_> scribenick:Chunming_

https://github.com/w3c/chinese-ig/issues/154

Bullet Chatting Proposal (joint session with TTWG)

<xfq> https://w3c.github.io/danmaku/index_en.html

Song: [TTML与弹幕的区别]
... 1. 从定义上，字幕(subtitle/caption)是一个时间，人物说的台词和画面解释

<yigu> link to "TTML与弹幕的区别"?

Song: 弹幕是用户发表意见和分享观点，是用户在参与内容过程中实时产生的，并没有一个事先存在的文件来保存它们

<xfq> Differences between TTML and subtitles/captions https://docs.qq.com/doc/DUmRaamhZZHBxRkpY

<yigu> Thanks!

Song: 2. 从表现形式(presentation)上，字幕是一行或多行内容，一般显示在固定位置
... 弹幕在整个区域现实，数量上比字幕大很多，并支持一些交互（例如鼠标控制弹幕停止或继续，以及对某一个弹幕消息的回复）

<huangzhihao> 弹幕除了文字以外还支持emoji、图片、超链等扩展

<xfq> nigel: WebVTT currently doesn't let text to overlap, but TTML allows it

<xfq> ... it is not a technical limit, it's just an editorial choice, the subtitles/captions authors choose not to overlap them

Song: 不是技术上的限制。
... 3. TTML 关注字幕内容格式，弹幕希望提出一个技术实现方式（API，或规范video元素，而不是规范video元素所引用的视频文件格式）

atai: 从目前情况看，你们已经实现了弹幕，现有规范和需求实现之间的差距在哪里？什么需要被实现在新的 弹幕API中？

Song: 现有大量中国和日本的公司都提供弹幕的功能，每个公司都有自己不同的解决方案，这是一个共性需求，但缺少标准简单的实现方案
... 我们并不打算标准化整个框架，但一些共性的点（例如避免多个弹幕消息的重叠和碰撞）应当考虑在这个标准方式中

Glenn: 你也可以定义javascript库和数据格式，所以开发者可以告诉浏览器如何呈现这些内容。你们考虑这种方法？

Song: 没有。但有些公司这样实现。

Glenn: 做JS库可以是一个开始来获得不同实现厂商的共识，在JS库可以定义一些标准的弹幕消息格式

Song: (continue) 回答“标准化需求”的问题，我们希望着重考虑 HTML 元素来扩展支持弹幕的呈现方式

nigel: @@2

Glenn: 有TTML和WebVTT，有需求来自弹幕，我们也会考虑这些新的显示需求
... 很希望了解TTML和WebVTT支持弹幕的具体技术需求，找到新的技术特性，来拓展TTML和WebVTT的呈现

nigel: 是的。

Lilin: 很难用现有的技术实现弹幕，现有使用CSS/DOM，如果能够定义API，可以更简便地将弹幕功能实现处理
... 支持动画、字体、样式

atar: 我感觉你们已经有技术方案去实现，只是希望实现这些技术方案的互操作

<lilin> 目前对于没有专门元素的时候，大部分的时候都是基于CSS3 + DOM + Javascript来实现。但是当前开发者实现弹幕比较麻烦，需要计算弹幕的位置，考虑弹幕与视频的同步，弹幕的速度与动画，以及不同字号的弹幕文字要避免碰撞。所以如果能标准化一个专门来实现弹幕的元素或者其他方式将很有用。

<lilin> from developper of bullet chatting

<lilin> https://w3c.github.io/danmaku/

Song: (next question) 弹幕是否需要类似TTML、WebVTT这样的文本格式，这个API是要解决布局问题？同步问题？客户端-服务器的API问题？
... 我们认为，如果用API，这些可以不标准化；但如果是HTML元素去表达这些，就需要标准化（包括位置、布局、弹幕显示时间、内容样式等）

nigel: 当发出弹幕时，客户端只发送内容，还是要发送内容以外的很多控制选项？

Michael_Li: 由于渲染是在客户端做的，服务器端只需要发送有限的信息，时间和内容，具体显示在客户端控制

Song: (last question) 是否能够在TTML WebVTT基础上通过扩展来支持弹幕？
... 我们认为，TTML侧重格式；弹幕的动态性（内容动态生成）。例如niconico 和 bilibili 都使用弹幕在直播场景
... 在这种情况下，弹幕需要实时的记录用户评论的内容
... 对于点播模式，仍然有清晰的时间线概念，弹幕的实现需要将用户发出弹幕的时间记录下来，并共享给其他用户（当其他用户播放到指定时间时）

Michael Li: （Demo）

scribe: 弹幕的滚动显示，用户可以在comment里面增加一些artwork
... 这些comments是在客户端控制的，可以做出一些复杂的效果（大量重复、动画显示、kalaok）

@@3: 即便有一个新的file format，你还是需要Javascript去实现这些控制能力

<xfq> description by niconico: https://rentry.co/bgc5h

Michael_Li: 我们演示了这些需求（作为用例），我们想了解什么能够被标准化。
... 并不一定把所有这些效果标准化

<xfq> niconico example

Eric_Carlson: 可以通过标准化，减少一些JS的work

PLH/nigel: 这个与无障碍场景也有关联

nigel: 下一步如何工作？

xfq: 希望在Chinese IG、日本公司与TTWG之间建立一个沟通渠道

Song: (demo) 竞赛夺冠的瞬间，用弹幕渲染气氛

xiaoqian: 建议能够设立一个 CG，让相关方能够继续讨论

(休息10分钟,会议14:40继续)

中文排版需求

<Zhiqiang> http://w3c.github.io/clreq/

Bobby: 董福兴，中文排版需求编辑
... CSS Writing Mode Level 3 （书写模式），很快要推进到 PR
... 这个工作可以追溯到2011年，对于CJK、蒙古文非常重要，对竖排（直排）、古籍出版很重要
... 蒙古文是从左往右的竖排
... 用了10年时间
... 当时三个editor，来自CSS/微软/Annetana
... 在此前，还有日文排版需求，2006-2007年启动
... 日文、英文双语
... 再回溯到1984-1985， MAC诞生，在MAC里面加入日文字形，但日文排版遇到麻烦
... JIS X-4051:2004 日文语文书的组板方式（之前是1993年），日本工业标准
... 这个文档给印刷使用。当时以这个行业标准做参考，给出日本排版需求（书写方式，Ruby，...）
... 就是后来的JLReq（日语排版需求）
... 90年代早期，中文古籍的数字化，也有类似日语注音Ruby的需求
... 恰好各个浏览器厂商都开始大力支持CSS/HTML实现，HTML5 2014年发布
... 数字出版领域，希望使用开放格式，就是epub
... 率先将一些新特性放入 epub3 （电子书）
... 但电子书的很多实现厂商也使用浏览器内核做内容渲染
... 例如：全角分号，横排原则在中间；竖排时，日文要把分号横过来（点在左），繁体中文竖排要求不变在中间，有些标准要求靠右排
... 所以，我们参考JLREQ，开始了中文排版需求（CLREQ）工作
... 2013年TPAC在深圳，启动了这个工作
... https://w3c.github.io/clreq/
... 举一个例子：避头点（一些标点符号不能出现在一行的行首）
... 英文符号习惯连接在前一个字符字尾；而日文、中文标点在左下角，放在行首视觉上很怪。但不同人有不同观点，比如严格排列整齐（不作调整）
... 日文在 4051规范中有一套做法；但繁体中文则需要更放松的规则
... 另一个例子：Ruby 注音符号。
... 日文和中文不同；繁体注音最多3个字符，简体中文最多可以有5-6个字符。
... 如果支持的不好，需要收集需求
... 下一步，古籍排版？还是面向新的需求？希望大家提出案例和需求。

Zhiqiang: CLREQ有新的需求？

Bobby: 事实上我们是将中文排版的要求列出来，让浏览器厂商、出版厂商理解
... 目前繁体需求基本都表达出来了，简体还需要更多的输入

MiniApp

qingqian: 小程序在TPAC上做了breakout session
... TAG表达了关注，如何让一个开放的浏览器系统去访问MiniApp
... Google提到的：Web Packaging与MiniApp的package方案是否有共同点
... 另一个进展是Judy Zhu在AC上介绍了MiniApp工作

zhiqiang: 在讨论中，W3C中也有一些技术在做，对于重叠的部分我们的考虑是什么后面需要讨论

<angel> https://www.w3.org/community/miniapps/

qingqian: 我们建议：
... 梳理一些明确可以开展的技术工作方向
... 为了更好和w3c已有工作融合，建议分为两大类：（1）miniapp特有的，可以在CG和未来的WG里讨论和孵化，产出技术设计、用例、实现
... (2) 针对与现有W3C工作有交叉的部分，做针对性分析，提交给相关的WG，做讨论
... 这种方式进展可能慢，如果不能满足厂商速度要求，可能需要一些其他考虑

zhiqiang: +1

qingqian: 需要讨论一下具体的工作模式，以manifest为例，需要各个厂商考虑如果将W3C已有的manifest引入来做，要怎么做
... 需要各个厂商的技术决策专家直接参与讨论
... 又如packaging，可能还需要定义一些公共可接受的方案，如何创建，包格式，如何解析
... 一个runtime下载一个包，如何解析和理解
... 对于这类从0到1的标准项，我们采用怎样一个工作模式？确保讨论需求，提出标准，实现，并能提供给大家

zhiqiang: 有些可以直接开展的工作（manifest,packaging, URI...），主要是定
... 把问题具体化，能否提供开源参考实现

qingqian: breakout时，TAG有问题反馈，提出小程序需要有可公开访问的标识（基于URI）

xiaoqian: 整个Web的基础是基于origins的，如果没有这个基础，就很难重用web上的其他机制

hax: 现在各个厂商的小程序分享，是不公开的，各自实现的

zhiqiang: 定位到小程序是一个公共需求

qingqian: 百度一部分小程序是通过URI标识的，origin是平台的
... 多个小程序共享了一个origin
... 让小程序可被URI访问

zhiqiang: 这个和小程序上线审核是否有关系？

qingqian: 小程序标识是ok的，审核应该是另一个维度的事情

zhiqiang: 目前的实践，小程序需要经过审核才能上线访问

qingqian: 这里是两个阶段，上线（审核，平台提供了这个机制）；用户访问（用户通过平台访问到小程序）

zhiqiang: 大量小程序的访问不是通过URL

qingqian: native app不会用这种方式。我们需要一种公开访问的标识。

hax: 用户不需要直接看到这个URL，这时个后台机制。

chunming: 分享的场景可能需要这种URI/URL的方式

<wanming> angel: wave~

zhiqiang: 例如点评，可能在一个移动设备上有多个小程序平台，到底应该启动哪个？

hax: URI是有alias机制，它应该会可以重定向或别的方式去定位

xiaoqian: 即便同一个domain内，也可能有不同的url

hax: 可能还有不同的版本

qingqian: 类似给定URL，选择哪个浏览器打开

Bowen: 小程序是放在自己的平台上吗？

hax: 现在都不这么做，如果做需要有类似签名机制

qingqian: 小程序的所有者通过webpacking做签名，主要是考虑信任和安全问题
... 小程序的所有者需要能够认证小程序是我开发的

zhiqiang: 现有的小程序都有签名，是统一的需求，不是统一的实现方式

qingqian: 这种互通是对开发者和平台有好处的

hax: 对开发者越一致越好

xiaoqian: 大家是否认为URI是一个需求？

[现场没有人提出不同意见]

小程序白皮书：https://w3c.github.io/mini-app-white-paper/

发布为interest group note

xiaoqian: 百度可以作为URI的召集方

zhiqiang: manifest？

[现场没有人提出不同意见]

qingqian: widget?

[现场没有人提出不同意见]

华为作为manifest的召集方

小米作为widget的召集方

qingqian: Charles帮助成立了miniapp ecosystem CG
... 后续的讨论可以放入这个CG进行运转

<xfq> https://www.w3.org/community/miniapps/

zhiqiang: 应用生命周期(life cycle)与事件
... application event
... page event

angel: 建议在CG中讨论

zhiqiang: 策略上，先做一个小程序的最小子集
... URL定位，小程序打包，生命周期基本事件
... 其他高级扩展可以慢慢加

anqing: 很明确的在W3C中有的，要融合。

zhiqiang: 如何有个小程序最小子集，各家是否有意向开源？

qingqian: 有些project可以在开源上做一个共享项目

Charles: signature 签名是否在最小子集中？

qingqian: 签名是平台相关功能。Webpackaging是否满足需求，需要再看。如果能支持，可以一起迭代。

angel: 建议考虑两轮
... 中文交流可以在每次CG讨论前
... 建议CG为monthly call
... CG可以根据任务再划分task force

Charles: WICG有些做法可以参考
... 工作模式：在线，在github创建文档，然后再线上讨论

angel: 建议同步考虑WG，CG没有足够的IPR commitment
... 这样才能确保各家使用的时候 后顾无忧
... 第一步，就12个月，能做出什么？
... 后面再不断迭代，放入新的特性
... 第一阶段的WG章程可以基于最小集

xiaoqian: 建议有些基础，再推进WG

Juejia: 从CG到WG是否有时间限制？
... 并在过程中充分吸纳国际厂商的意见
... task force的leader需要注意这一点

angel: +1

Charles: 大家打算在哪里工作？放在wicg？or放在CG？or放在现在的white paper CG？

qingqian: 建议在white paper repo改名

（现场没有不同意见）

xiaoqian: 统一说法，MiniApp （不加s，M、A大写，没有空格）

（现场没有不同意见）

<xfq> chunming: miniapp的目标是什么

<xfq> ... 是否把miniapp在不同平台的互操作和访问作为一个目标

<xfq> ... 不要把miniapp和web隔离开来

<xfq> ... 可以把这个确定下来，并且写出来

<xfq> ... 昨天听了project fugu的分享

<xfq> ... 我们不需要刻意强调哪些是mini app独有的，哪些是web有的

<xfq> ... 这样过于封闭

<xfq> ... 更好的是要强调全球共同的需求

+1

<xfq> scribenick: xfq

<Chunming_> xiaoqian: CG文档是英文还是中文为主？

<Chunming_> angel: 建议英文，有助于CG交流

<Chunming_> qingqian:+1

<Chunming_> zhiqiang:+1

<Chunming_> (现场没有不同意见)

<Chunming_> wanming: 我们都知道标准的迭代需要四个浏览器厂商支持，以后是否有可能国内小程序厂商独立开发API，也可以成为vendor

<Chunming_> qingqian:好问题。产出的spec和实现，小程序厂商都是实现着，如果有两个或三个小程序厂商支持，就可以认为标准可实现

<Chunming_> xiaoqian:如何界定小程序厂商的“独立性”

<Chunming_> zhiqiang:通过引擎的技术路线来确定。例如不同的引擎，应视为两个不同的独立厂商

<Chunming_> ... 这里有误解，不是说有两个实现就已经成为标准了，问题还是要解决的

<Chunming_> anqing:还有正式反对

<Chunming_> Charles: 界定是不是独立参考实现，主要针对所标准化的东西

<Zakim> chaals, you wanted to talk about implementations needed

<Chunming_> wanming: 我们与谷歌小米有沟通，对比了PWA和MiniApp，希望在这方面有共同的合作

<Chunming_> qingqian:Intel会做miniapp平台实现吗？

<Chunming_> wanming:会有意向在desktop上实现

<Chunming_> xiaoqian: 如何处理objection？

<Chunming_> angel: 原则上，如果没有正式反对意见，2/3通过

<Chunming_> xiaoqian: 建议按厂商投票，加开发者席位

<Chunming_> qingqian: 希望引入开发者一起参与决策

<Chunming_> ... 但前提是能够充分参与的开发者

<Chunming_> angel: 两阶段，vendor投票选择后，听取开发者意见(review)

<Chunming_> xiaoqian: 提议满足 2/3 参与厂商统一，且听取开发者意见

<Chunming_> ... 作为同意CG提交到其他WG的决策条件

<Chunming_> huchunming:是否要考虑 formal objection?

<Chunming_> xiaoqian: 不建议

<Chunming_> angel: 不考虑

<chaals> [I would suggest simple majority of developers - 50%+1 ]

<chaals> [as well as 2/3 of vendors]

<Chunming_> (现场没有不同意见）

<angel> ACTION: angel to draft the charter of the Mini APP CG

<Chunming_> 决议：2/3厂商同意，有听取开发者意见环节，不考虑FO

<Chunming_> 讨论：CG

<Chunming_> xiaoqian: 关于CG的chair，建议设置2-3个co-chair

<Chunming_> charles: 提议angel

<Chunming_> zhiqiang: 可以先两个，Angel+国际厂商。后面再看调整（如快应用联盟）。

<Chunming_> angel: 提议在2019年10月第二周举行CG的第一次电话会。

<Chunming_> qingqian:建议技术决策的人能够参加直接的讨论

<Chunming_> angel: 例行的会议是English

<Chunming_> xiaoqian: 建议白皮书保持，针对提出问题组织一个回应（FAQ）

<chaals> [+1 to xiaoqian on FAQ, maintain white paper…]

<angel> https://www.w3.org/community/miniapps/

https://w3c.github.io/mini-app-white-paper/comparison.html

<yigu> Alex's questions: https://lists.w3.org/Archives/Public/public-chinese-web/2019Sep/0001.html

TPAC feedback

<Chunming_> angel: 本次大家参加TPAC的整体反馈如何？

<Chunming_> ... 除了小程序、Media，还有WebML, 3D元素（breakout）、WebRTC（breakout)等TF

<Chunming_> xiaoqian: 弹幕也需要设置一个CG

<Chunming_> angel: 我们利用这个机会做复盘

<Chunming_> ... 我只参加了小程序break，我的体会是前面的沟通是非常重要的

<Chunming_> ... 这样后面整体会比较顺利

<Chunming_> ... 事前的沟通可以帮助加深理解，更容易被接受

<Chunming_> zhiqiang: breakout本来是挑战和推进的过程

<Chunming_> chunming: 要明确breakout希望达到的产出

<Chunming_> xiaoqian: zhiqiang的breakout是个好例子，总是需要面对同类厂商的疑问

<Chunming_> ... 另，我提议下一个IG topic可以考虑做 WebVR&AR

<Chunming_> ... 国内已经开始做国标了

<Chunming_> lilin: +1

<Chunming_> ... 可以和5G有结合

<Chunming_> xiaoqian: 建议放在春节后，3-4月。希望在AC前有些共识。

<Chunming_> qingqian: 在百度，也做一些Face Tracking API.需要和ImmersiveWeb探讨交流

<Chunming_> bobby: 大家是否参与CSS WG

<Chunming_> ... 应当有人长期进入，CSS是相当值得观摩和参与，很开放

<Chunming_> ... 如果有人参与，就可以将那边的进展带进来

<Chunming_> Chaales: 人脸识别需要考虑到和隐私的结合

<Chunming_> ... 可以与privacy working group有一些交流

<Chunming_> ... 我们需要用例说明它的必要性，但要正面面对可能带来的隐私问题

<Chunming_> +1

<Chunming_> Hax: 关于CSSWG，360这边有同事参与了F2F

<Chunming_> ... 呼吁中国厂商有更多的工程师参与

<Chunming_> ... 还是有负责底层的工程师需要关注 CSS进展，他们不一定了解这个沟通渠道

<Chunming_> xiaoqian: 国内新闻以为我们发的白皮书是标准，是否需要澄清？

<Chunming_> angel: 小组的共识，可以写成文字，审阅通过后，可通过渠道（包括w3c blog,中文网站）发布

<xiaoqian> https://www.w3.org/2019/09/20-Chinese-Web-en-minutes.html#ActionSummary

<Chunming_> angel: 很高兴看到前半段会，有国际厂商和工作组参与讨论。提前做好准备。

<Chunming_> ... 今年有6个中国会员提出的breakout，相比于我们自己已经在进步，感谢大家的支持和贡献。

<Chunming_> xiaoqian: 也要感谢Chaales、Jeff，帮助我们做了很多沟通工作。

<Chunming_> [掌声]

<Chunming_> bobby: LG的Round Display的成功故事，鼓励大家做更多贡献

<Chunming_> [散会，预祝返程顺利]

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/PR/CR/
Succeeded: s/AC上也有一个环节报告//
Succeeded: s/几只/机制/
Succeeded: s/vender/vendor/G
Present: Angel Anqing LiLin Zhiqiang Qingqian Xueyuan Fuqiao suzuki koizuka Michael_Li Chunming_ wanming hax Bowen lizheming yuyin shouqun chaals QingAn Atsushi Glenn Nigel plh naomi xiaoqian Yajun_Chen Eric_Carlson bobby Yanni yigu
Found ScribeNick: Chunming_
Found ScribeNick: xfq
Inferring Scribes: Chunming_, xfq
Scribes: Chunming_, xfq
ScribeNicks: Chunming_, xfq

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: angel

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)