现场纪要
安勍：现在开始CG组的讨论。
赵小平：我向各位参会的同事简单介绍一下Widget。
因为之前我是在CA组里，现在我想简单介绍一下草案。
因为之前我们写了一个简单内容，还没有真正成为一个MiniApp的spec。
https://github.com/w3c/miniapp-widget/pull/11
今天的主要内容包括Widget。下面我们引用了一些术语，这个spec的主要内容就是关于Widget在小程序里的一些规定，一些内容包括了Addressing、Packaging、Manifest和Lifecycle要求，我们对新的event进行了描述。
和原来的Widget可能有一些交互，还有一些能力的通信，还有Widget和小程序可能需要对一些数据进行访问，我们也进行了一些规范，出了一些示例。
最后是安全隐私方面的内容。 这是Widget草案大致的状态，后续主要从安全隐私方面，还需要补充一些可用性方面的内容。
现在我们主要是在CG内讨论，也希望各位参会的专家和同志可以对我们提一些相关的建议。
今天我想交流的主要就是这些，各位对我们是否有一些建议？
安勍：现在的进展是再补充上安全和隐私考虑，内容基本就完善了，是吗？
赵小平：当然，第七章会继续进行完善，但整体构架就是这样。
安勍：不知道大家是不是第一次看这个文档？大家对这部分有什么问题吗？其实这方面没有什么Issues。
最后在PR里还有一些待解决的。
赵小平：对，我们还在学习怎么从其他的标准中把数据引用过来，应该没有大的问题。
安勍：行。
感兴趣的同学可以看一下这个spec。原来小米是写了关于需求的，更多是从功能要求的角度，现在进一步写了具体的Widget spec，规范了一些交互的流程和event的设计。
因为现在还是CG讨论的阶段，还没有进入工作组走正式W3C的规范推进流程，所以现在大家有什么建议或者意见，现在提比较合适，还是有一些可修改的空间。
安勍：好的。如果更多意见的话，我们进入下一个（环节）。
下一个就是刚才Martin说的testing。
Martin：大家都知道，我们已经建立了一些方法论，来建立测试，尤其是对不同规格进行测试，现在我们上传的所有app都可以进行测试，也可以给实施的规范一些报告，我会给大家举一些例子。
https://github.com/w3c/miniapp-tests
分享一下测试的情况。也许现场有些朋友是第一次看到这个测试，它整体的情况就像这样，我们看一下具体的参数和细节有什么不同，比如有Manifest、Widget等内容，这些内容和组件相关。
内容的具体参数，像语言、CSA等等，举一些例子。这里举里很多例子，我们也会给大家这方面的实例，这样方便大家理解。
比如测试Manifest部分，包括了不同的参数，大家看一下这里的链接，这是针对这部分的具体情况和擦数。
比如全屏的成员以及一些描述，有一些价值和算法，这是比较简单的。成员们的MiniApp必须是全屏开放性的，测试一下这个menber。
看一下上一页的例子，在显示方面可以进行全屏，我们想测试小程序上的结果，这是具体的描述，这里是在Manifest显示为正，所以必须进行全屏显示。我们已经完成了这部分测试，点击到子菜单里的Manifest，看到结果是正数。
再看看显示页面，这是一个比较简单的测试。给大家看一下相应的结果，如何将它纳入其中，放到全屏的member里。这是测试情况以及描述。
这些描述都被收集在这个地方，在其他的HTML页面上看到的内容相近、相似，以及识别。文件名描述得也非常清楚。
回到前面的页面，这里非常清楚，这就是链接的出处，测试链接的具体细节，和参数进行相应的连接，这个地方已经被定义好了
这就是一个结果。
在这样的情况下，我们没有报告，因为我们还没有具体的细节参数执行，但是它可以被链接到具体的执行层面，生成相应的报告。
我们将在这个地方设置一个链接。
这里为大家展示的是我们可以加入其他信息，比如包括不同测试以及相应的链接，大家也可以看到在全屏成员中，我们建立了两个测试，一个是window的 Full screen，这部分测试也被覆盖。
在这种情况下，同样的方法，我们可以更好的了解具体的参数能够被确认，得以保持完整。
看一下我们将其囊括其中，看一些不同的数据测试已经在参数当中，这里代表了文件名和定义的单位情况，包括了两个结果。这里的信息可以直接和参数链接，这就是我的陈述。非常简单。
在推荐这部分已经显示出来了。我们也可以把它包括参数的这个地方，可以直接点击进入详细的信息，并且收集这些信息。
好的，这就是我针对测试分享的内容。看一下MiniApp Packaging和Manifest，我们想一个一个的说。第一个是我们有一些重要任务，这就要求不同的层级有不同的要求，我们想覆盖所有参数的设置。
在这种情况下，能进行实时的测试，目前我们没有跑任何执行，但可能需要有一些编译和转译的工具进行参数后续的测试。同时，对于这些参数会生成一些报告，在文章中说到了，工作小组也提到了。作为一个成功的领域，需要两个独立的MiniApps实施，所以我们必须在测试中覆盖所有不同的模块，至少有2个小程序的实施。
对测试这部分，大家有什么问题吗？
https://w3c.github.io/miniapp-tests/
安勍：谢谢Martin。分享得非常好，2.3这个内容具体指什么呢？可以再重复一下吗？
标题是“Content”，这部分是什么呢？
Martin：在这部分，我们只是纳入了一些案例，这只是一个例子。
这里只有一个例子，就是在Packaging部分进行的情况，是全球CSS的stylesheet的文件，还有它的一些组件。首先是Global CSS的 stylesheet。文件叫CSS，它可能会影响到所有的配置，这只是一个例子。
我点进去给大家看一下。
比如我们增加了style sheet，这是可以在上展示，但这里只是给了一个例子，说明如何执行这部分的测试内容，这只是一个例子
我们应该有更多例子，只要涉及CSS，涉及Market语言以及部分组件的测试以及其他部分测试组件等等。
我看一下2.1~2.4，他们可以进行分组，也可以根据需求进行调整。我们要根据大家测试的数或者具体要求进行调整，这都是可以建立的。
这只是我们说的规范和参数中的一部分，如果大家对这些有调整和小的建议，都可以提出，这都只是一些例子。
安勍：我建议目前的2.1、2.2和2.4内容都紧密相关，但是2.3让人有些迷惑，我个人建议增加一些小的备注或者是描述，就是为什么会把这个内容放在这里，这个内容和其他不同的分组话题有什么关联？
Martin：好的，谢谢您的建议！
我会按照您的建议进行相应的调整和协调。谢谢！
安勍：好的。线上和现场还有朋友有问题吗？
安勍：Martin，你们有计划表吗？比如什么时候建立测试的情况，很多参数specs正在做平行审查，可能会包括一些spec更新，有一些参数让MiniApp需要进行一些调整。
就是根据我们的反馈进行实时调整，在这方面，您有没有什么建议？最好的时间是什么？
Martin：这是很好的问题。我们应该尽早进行测试，看一下对开放平台来说是否合适，我们要重点关注可能会提到的潜力，刚才提到了一些反馈的改变或者更新，我们尽早开始。
特别要强调一些特点，这些特点可能会影响到实施部分，只要我们开始做这件事，我觉得越早越好，进行相应的验证。
最重要的是对所有MiniApp的Vendor都应该去实施，不同的特点都去实施，看一下这些特点的具体情况。我们要根据名单进行测试，只要有相应的工具可以使用，像小程序上的实施和程序化工具都应该尽快开始测试
看一下最稳定的特点，比如Manifest，可以先测试这部分，因为我们知道很多特点特别稳定，可以先开始。我们也可以测试一些不同类型的参数，因为我们知道有些参数表现已很稳健了，这是一个非常好的点。
如果大家有一对一的会议或者是参数的会议都是特别好的，因为这一点非常重要。首先对标准的实施推进，参数方面实施是非常重要的点。
我们应该花一些时间，在接下来几周进行多轮测试。其他参数像生命周期的测试，可以帮助我们更好的了解方法论具体的实现如何，接下来几周我会和大家通力合作，大家有任何建议也可以随时向我们提出。
所以，越早越好，这就是我想表达的核心意思。
安勍：谢谢。
接下来进入下一个讨论模块。UI组件库部分。有请Martin。
Martin：好的。对这部分我们进行了内部的评估，MiniApp API和之前API的比较，对于组件来说，如何建立起MiniApp的模块，可以看一些具体的信息，比如UI组建的参数，我们收集了不同的组件。
可以看它的不同测试，例如div、span、stack等等，当和标准的W3C的参数进行等量比较，同时我们也吸收了主流平台的内容，比如阿里、百度等小程序，这些都是是W3C标准化之内的，已经被执行得非常好。
在这里可以看到一些差异，但是，在这样的情况下，有系统的等效性。其他的Camera部分的组件，可以看到引入更多的情况，也可以观察到在快手以及百度的组件都可以使用Camera，还有其他的例子，比如一些细节的例子，像Select，往下可以看到更多的细节，也可以收集不同的信息。
我知道有一部分，比如tabs还没有补充，在百度是tabs相关的小程序，还有一些研究正在进展当中，比如开放UI小组正在进行这方面的研究，他们也正在研究最好的方法界定这些tabs，稍微我们会进行更新。这些内容正在进展当中，后续有信息我们会继续更新。
这里有一些其他的元素，重点分色是缺少的部分，关于WCC和小程序的空缺，我们希望继续收集。
信息更新之后，会增加到UI模块当中。比如在这里收集一些小程序贡献的地方，无论是在小程序方面，还是相关的研究工作，都会更新进来。
在模块建设上，比较有趣的几点，我们觉得“ad”在标准化上比较重要，还有payment，都可以通过小程序，还有社交网络等燃烧等等，我们都可以和很多其他W3C工作小组的成员互动。Open UI兴趣小组主要负责把信息收集起来，我们希望稍候可以听到自己的评估和想法。
除此之外，我也收集了很多其他的信息，不仅是模块信息，我还收集到很多信息，比如标准化的区隔信息，比如XTML标准以及具体部分，还有小程序的具体实施、整合、收集信息，以及在小程序上测试和文件、文本的归属问题。我们可以把这些信息放在模板上，可以收集文本，把信息插入进去。
[多媒体演示] 这里展示的是和消息不符的地方，所以我们需要进一步收集建议和意见，完善这部分内容和现有标准完全契合。除此，可以在规格上反复核实。
我会收集最小的特性信息，之后让他们整体表现和现在的标准再对标。
比如在Definition，可以有标准化的想法，在DML上，看看出如何在百度小程序、支付宝小程序上看怎么做。
我们收集了不同的规格，我觉得这些都非常重要，如何界定模板，可以从其他模板上进行整合，如何界定参数，比如不同模板的参数，以及如何在模板内部进行使用，参数上可以进行模块的界定。
除此之外，在这些规格上实现契合，都有区别。
如何在不同的规格上进行界定，这些都有类似的地方，也有和标准不同的地方。如此之外，对如何界定事件，标准化的不同可以看一下他们的属性以及不同的界面、不同的规格。
还有CSS，很多Vendor都制定了CSS，我们要进行界定，还有很多小程序都进行了兼容。这里是属性分析，以及在包装上如何进行整合和不同的资源整合、模块整合，还有其他的信息，比如如何为模块制定界面，
如何界定他们的属性。在这里都有展示。
[多媒体演示] 这里是属性，展示的是MiniApp的模块，有支付宝、百度，它们有不同之处，也有很多类似的地方。
我们要收集不同平台小程序属性不同的地方，把它们整合到一起。
并且和现在的标准完全契合，还有界面的不同等等。 我们做了一些分析，主要是寻找网站上的公共信息，因为是从中文翻译过来的，所以我有一些不太理解的地方，但是这里展示的图表信息还需要核实。
接下来和大家分享的是这一页，我在电脑上创建了不同规格和模块的不同之处，以及标准化的方法是什么样的，基于这种分析，我们可以吸收他们共性的地方，涉及一系列共同的标准。通过这些共同的标准，在UI模块当中一起找到共同的标准。最好的方法就是创建一个工作小组，并不是强制把它作为一个强制性的方法，我们也把其他小程序的开发商一些机会，看看这些模块如何开发。
我觉得，至少我们可以强调这些共同的特点以及三个小程序应用的不同方法。
我们也可以把这些放进来进行研究。可以把这些对比信息放到小程序里，我觉得非常有用，可以让社区了解到不同规格的不同之处，我可以把一些请求发给大家，等待大家的反馈，之后可以进行UI规格的一些研究。
对这部分内容，不知道大家有没有什么意见和点评？
安勍：现场有什么问题吗？
王子韬：这是非常好的信息。我们可以做更多的分析，我们要根据现有工作进行后续研究，稍候不同的Vendor可以按照阶段性的需求制定标准。我想指出的是和之前的问题一样，需要界定一些里程碑节点，让我们能够继续向前推进和发展。
我们知道去年有几个例子，我们把2.0版本放到了白皮书，也就相关性的技术开发了标准，我们需要更高的效率、做更多的努力，同时也需要制定新的标准，也需要有新的技术。
所以，我的建议是设置一个截止日期，今年年底可以有更多沟通，让行业内人士帮助我们评审，根据这些文件优化，进入下一步，可以使用W3C更多的意见和建议，界定更多关键标准。
这就是我的建议和想法！
安勍：现场和线下有其他的意见和建议吗？
我们需要使用更多标准和技术，也需要不同的Vendor帮助我们，完成它的特点、特性，这一点非常重要。
所以，我们需要更多资源进一步专注这方面的工作和努力。
高亮：Martin，我是来自华为的高亮。首先，非常感谢您给我们展示的不同Vendor的内容，非常有用。
我想说刚才你提到了自定义部分使用了完全不同的技术，实施也有很多不同的地方，比如自建部分，能不能再分享一下你的表格，比如icon部分。这个icon，我们知道在小程序里叫它conmmance，在小程序进行问题扫描的时候，我们会关注SMC icon和其他icon。
我们看到的是前沿部分，这一点对这个标准来说非常重要。
我们希望做一些工作，这样我们就需要做一些内部的研究和调研。
未来可能会对整个流程有更多洞见。
Martin：这也就是为什么我们要建立这样的表格，如果家有任何积极的反馈，欢迎大家可以及时反馈给我们，尤其是刚才说的报告，可以帮助我们了解如何实施，就像刚才说到的图标以及数据差异等等，对我们来说都是非常有价值的。
也可以进一步了解Vendor的想法，达成一致的组件和元素的特性。
这些都可以使我们获得更多收益。通过共享事件和讨论，因为参数没有达成一致，所以我们还会继续推进完成，或者跳过这部分。
对于元素的参数，可以覆盖到这个模块，更好的在市场上应用，只是有可能实现的。
安勍：谢谢Martin。
大家还有其他问题吗？
我们来到了最后一个环节。周丹，还在线吗？
周丹：之前在WG会议讨论的点，是目前logic和Manifest的交互都有差异，希望在实现层做统一
关于这个事情，首先我有个问题，但不确定相关的同学是否还在现场。这个疑虑就是为什么从开发人员的角度要关于logic和view层。想说的logic和view当初的实现是可能是基于安全性的原因，但这个内部实现是有可能变化的，比如现在厂商会做其他模式的探索，甚至可能不区分logic和view，可能它不是真正意义上的隔离。
而保证对开发者接口一致的情况下，为了提升自己小程序顶层框架的内容以及等等更优的体验，这个架构都是有可能改变的。
所以，我觉得运行层优化它的话，它的标准化进程可能跟不上技术的发展、技术的演进，这是我想说的点。
但是，我不确定W3C在这方面是否有实践经验，比如一个变化快的艺术也是通过标准一直不断进行迭代吗？这也算是抛出一个疑问，看看大家有没有想法。
关于互通的事情，我觉得如果保证了面向开发者接口层的一致性，不同的厂商即便编译性有一些区别，最终理想上也是可以运行，因为外层接口是一致的。
这是之前我想讲，由于时间关系没有讲的点。
不知道有没有人愿意回答？
高亮：您好，我是华为的高亮，我想回应一下你的观点。
实际上，当我们谈论这个问题的时候，我们要分清楚什么是外层、什么是内层，当我们谈HTML标准的时候，比如HTML的某个标签，这些标签实际上是一个边界，这个边界再打开是怎么回事，我们不管，开发者不用管，那是浏览器管的事，可能它是一个复杂的标签。浏览器怎么实现？它可能有很多的方法实现，用一些比较新的技术或者是传统的技术，开发者不用关心。
从这个视角来讲，您的观点非常正确。目前的小程序按照开发文档上的指引，比如使用的API和component就可以把一个符合标准的小程序开发出来。
但是，现在我们看到的边界点并不在这里。因为目前所有或者几乎所有的小程序实现厂商都并不只是可以直接读取开发者文档上所看到的标签。
组件、API运行的。
而是基于它们编译之后的package运行的，这里面就有很大的边界，也就是刚才提到的小程序的framework，我们必须要明确这是引擎实现层面，我们是否要关心这个framework，可能有一种观点我们只要把小程序的标签定义完成之后，它就可以在其他厂商的小程序里运行。
如果我们的标准是按照这个目标来做，那非常可惜，因为对于小程序实现者来看，他看到的并不是开发者文档上看到的文档、API，这可以通过大量的文档证实。刚才我也提到了这一点。
以微信为例，wx.方法它会转换为其他的通讯方式，刚才举的例子，icon的组件底层也并不是一个icon的组件，因为HTML规范里根本就没有这个组件，这个组件一定要转化成自定义名称的组件，并且赋予实现，这都是在framework层做的。如果标准完全不关心的话，那我们的标准只是确定了DSL的格式，包括我们当前做的Manifest等等工作都可以起到一定的作用，但不要忘记我们还做了Packaging的规范。
如果按照这个思路一直往下做，就会出现一个很特别的情况，符合A厂商做的完全符合Packaging规范的小程序文件包，或者也可以转化成一个流，实际上不能在另一个Vendor引擎上运行，这是我非常担心的情况，也是我不希望看到的情况。谢谢！
周丹：我理解你的意思了。其实现在framework之间出现的差异，是不是上层框架解决的事情？就像刚才你说的API还是有不一样，但是，目前来看这个不一样可以枚举，就像第三方的上层框架也是在抹平的事情。
之前我们讨论过W3C希望和更多的社区一起合作，在实践上抹平这些差异，这是否可以对framework的差异起到一定的抹平？
高亮：刚才你提到的差异，下午的架构师也提到了这个问题，他们有很好的插件，可以抹平Vendor之间的差异。其实Taro这样的方向，在我看来，首要解决的是开发效率上的问题。
实际上真正的开发者或者使用Taro的开发者首先关心的是用vue或者framework，这些开发者并目前喜欢用小程序的DSL。
在我看到的情况Taro或者是uniapp这样多端同步的框架，首先是业界常用的框架，解决这些框架写出来的代码变成小程序包的问题，首先要解决这个问题。
至于有十个小程序的厂商，变成A厂商、B厂商，这对同个框架的作者来讲也非常痛苦，至少我认为他们不认为这是他们的核心价值所在。他们的核心价值还是解决刚才提到的框架抹平的问题，也就是说今天下午提到的React如何在小程序里运行，这是非常有价值的。
但是，解决后面那一段相关属性，A厂商有的属性、B厂商没有，A厂商有的组件、B厂商没有，我觉得这些是比较痛苦的。所以，我认为我们可以在这方面做更进一步的工作。
周丹：我理解了。我觉得接下来如您所说，我们确实要界定好边界。哪些是Vendor自己可以自由决定的实现细节，哪些是一定会对上层造成影响的，之后我们应该要去把这个界定清楚。
我认可！
王子韬：周丹，这里是子韬。我在线下和各位老师讨论过这个问题，我认为现在离原先表了方式，现在可能有一些边界把它们定得过于小了，有些确实有标准的框架问题，已有的标准不管是历史包袱还是尊重现有的框架、架构，给我们框出了，所以我们在一个CG的会议上，我们互相再交流得更充分。
反正是CG的讨论，不管是开源的方式或者其他的方式，下午宋老师也提到过，大家可以把一些开源的运行实现问题放在CG上讨论一下，然后可以进一步在一些讨论上摸清楚我们动标准的边界，或者在W3C应该进一步讨论的业务边界是什么。
我觉得，开放讨论上，下一步要做得更开放，或者开源方式基于厂家充分表达意见的方式，做得跟开放一些。
有一些标准化方式，可以按照工作组发技术备忘录的方式进行阶段性的汇报、阶段性的呈现，征集更广泛的意见。再进一步如何和W3C做标准、已有的框架和部署，这是再下一步，最终映射到W3C标准上的工作。
我觉得可以以这种分阶段、分步把标准逐步的把业务边界定义得更清晰，方法定义得更好。
这是我对后面方法上怎么运行工作和CG的想法
周丹：好的。收到！
安勍：好的。CG单独的讨论。
陈嘉恺：各位老师好，我只是作为一个开发者的感受。虽然小程序很早就出了，但我一直没有想碰它，很简单的原因是因为我看各方的开发文档下来，很容易发现一件事所有的小程序基本都是运行在一个WebView上，也就是说刨去用户身份等super app的一些功能之外，它就是一个网页程序。
既然它就是一个网页程序，各家搞出了一大堆不同的框架，因为之前我不是做小程序开发，看起来非常眼熟，但这些看起来都是一样的东西吗？
所以给我的感受就是各家小程序在设计这些东西的时候，目标开发人员似乎不是Web开发人员，而是app的开发人员。不知道大家有没有这种感觉。
第二点，既然它是运行在WebView上，我希望它就只是Web上的都是。各家设计的框架结果是什么？有时候CSS都没有办法碰它们的样式。
我纯粹就是在写一个Web应用，我能容忍的最大限度就是各个厂商在获取用户身份或者是调取摄像头，或者调取之后，有你们自己的扩展。
其他的，一个Web应用应该是什么样子，就还是什么样子最好。
周丹：我想问一下，可能因为我没有太多的app开发经验，我不知道为什么有这些控件，开发就是面向app开发人员？因为我理解小程序设计的有一个初衷，是希望降低开发门槛，所以比较偏向小白。
虽然各大平台的差异确实给大家造成了困扰，但它的入门门槛很低、很小白，app的开发门槛毕竟要高一些，所以我不太确定为什么有这样的感觉？
陈嘉恺：在移动app出现之前，在窗体的开发环境之下，一定就有tab这个东西，广泛的一般是用在选项页面里，它可能会以不同的形式出现，可能在顶部或者是左边，后来随着形式的更改，颜色标签的颜色、背景色、圆角不圆角，但是在页面上，tabs这个东西，它们都有自己的实现方式。
周丹：我理解你的意思，但是我觉得这可能是从结果的角度上看。因为小程序毕竟是运行在NA上，它希望给一些NA的体验。
所以，它确实有一些控件就是用NA实现的，比如说Video等等，就是原生组件，这可能也是你的第二个问题的原因。因为你第二点提到了既然看起来是Web，为什么不像Web一样都能够覆盖得很好，其实就是小程序CG的目的是让它有Web的开发方式，大数据NA的开发效果。
在NA的开发效果上，其实就有一些对齐MU的工作，这也是造成各家差异的工作，就是这个对齐的工作不太一致。
我只是分析一下造成这个原因。
提问：刚才您提到了限制，即使对DSL做统计，出来实际打包的东西不一样，也没有办法保证一家的东西可以在另一家里跑起来，我理解前面是这个意思。
但是，我有一些疑问，我不确定是不是现在就确定有这个目标。因为如果说一个一家的东西一定要跑在另一个容器里，意味着它只能调用已有的API，不能调一个私有的API，或者至少说如果要调私有的API，必须有一个fallback的方法，它的标准化程度非常高。所以，我不太确定是否已经确定了有这样的目标。
高亮：我认为不一定要在这个层面统一，如果要做Packaging的规范，那这个规范要有人用，那应该是统一。
第二，还是应该由浏览器或者厂商去统一，因为或者对CSS的一些支持，都有一些私有化的手段。
当然，我并不是说这样做就会违反未来制定的规范，因为规范制定里肯定有自定义的部分或者厂商自定义的部分。
就看你生命的包是所谓符合标准的包，还是这个包虽然符合标准，但加入了自定义，不保证在另一个Vendor上就可以完整的运行，它可能会丢失某些能力。我理解应该是这样的行为。
就和我们写的网页一样，在不同浏览器厂商上运行的结果可能很相似，大家微妙的细节特征上会有不同，甚至某个厂商的浏览器就不支持网页里局部的写法，但不影响我们制定HTML5的标准。
这只是我的观点，要去做。如果不需做，只是把前端开发者的东西统一，我认为也是一种做法。如果那样做的话，我们要反向思考一下有没有必要做Packaging，甚至Manifest这样的一些定义。
因为理论上各个厂商都可以自定义自己的Manifest，但是我说的Manifest还是从framework看到的。
提问：我前面提这样的问题有这样的想法，过去Web的实践表明在一个应用里，当然可以有办法使用一些某个特定实现私有的东西，比如在CSS或者一些私有API。
但是，我个人的感觉过去的实现方式不一定是特别成功的方式，比如私有的事情，在现在的Web实现里，它更多体现了负面的东西。
由于Framework广泛的使用，导致其他厂商也要支持这个。
所以，我理解这个方式如果有一个统一的Packaging，我们承诺这个东西是可以支持一个打包好的东西，我理解打包好的东西有点类似二进制分发，我不管下面是什么样子，如果我们承诺这个东西可以在另外的地方跑，同时我们又说可以支持一些私有的扩展的话，我自己感觉从Web的历史来看，似乎不是很乐观。我只能说我感觉上是这样的。
反正至少从Web来讲，现在各个浏览器厂商的开发方式，以我的理解也不是这样子，现在不太多以这样私有的方式，而是大家都同意做这样的特性，特性以flag的方式开着，实现之后把flag去掉，它的描述方式和过去不太一样。
回到前面，我不太确定我们的目标在哪里，因为我自己理解即使没有做到打包的Packaging在另一个也可以直接运行，我仍然觉得Packaging和Manifest的标准仍然有价值。
因为我觉得它至少对于像Taro的架构来讲，它在于怎样支持上层的应用框架。我认为下面的部分仍然减少了成本。
另一方面，我认为直接使用Taro的方式手动写或者半自动的方式来做，我还是觉得Packaging或者Manifest没有达到100%理想的状况，但我仍未那些东西的标准化还是有价值的。这是我个人的一点想法
宋青见：我觉得今天讨论得很好，有一个问题，我也是一直在思考。
现在看小程序，小程序目前的这种做法很难成为标准。
我回答刚才这个问题。小程序用的方式，是Native的方式，实际上转化的并不是原来的。现在编译的方案，只是我想做的又没有能力定好Stream和Native之间的方式。
我写的方式是帮助我翻译成CSS。
从这个角度上讲，这种技术的水平很难成为标准。
如果这个能成为标准，那一样东西，所有的js都可以成为标准。
我就反思，我们做标准是在什么层次做，而且这个东西又能够达到我们的诉求。回到W3C，其实是保障了每一个人作为Website owner，要保证他的自由性。
所以W3C并不是为了迎合商业的成功。有人说从Web角度说不成功，我反而认为Web是最成功的开发模式，因为现在所有大公司基本上都集上来。
很难知道一个好的Web side知道Croming（音）。
最后商业很多东西统一起来之后，会自然发生。
包括PWA，和很多程序比，但它不如。但是很多人坚持PWA future，因为它是Web standard，其他不是。
如果想把一个小程序变成一个标准，应该参考Web的方式。我看到Web的很多东西都很短命，很多当年昙花一现的东西，你觉得它的技术周期能有多久？能像Web一样有二十年、三十年吗？甚至可能二十年、三十年之后还是Web，但其他还存在吗？
我只是有感而发，我理解现在我们讨论的东西，如果把问题界定清楚。
王子韬：我们也讨论过这样的想法，我们要在短期内符合一些商业的需求，标准小程序长的周期，未来更开放、更好的模式，就涉及到了基布走的问题
上午我们也和大家讨论以开源技术标准的方式先抛出来，再看哪些能够和Web结合，哪些东西可以抽象成真正的标准化，真正成一套W3C严谨的标准，以及有严谨标准化逻辑的标准，这是短期目标发展的思考。
长期来看，开始的时候我们定义小程序工作组，我们定义deliverables的时候也没有想清楚，包括高亮说的Packaging是运行时的东西，如果这些不要的话，是不是没有思考？我认为确实没有思考。
我认为要迈出一步，再看哪些可以成为标准。我认为大家都可以动起来，能讨论的都讨论，哪些可以严肃起来，赋予小程序的运行形态或者是开发模式更为长的周期，会有更好的未来。
安勍：最后聊的已经脱离技术本身了。微软的同事说的我们推进标准，前几年也经常遇到这样一些问题。
反过来想，说大一点，为什么Web持续三十年，回想它最开始的时候，其实只是一个看文档的工具，在线看文档，为什么能走到现在？一方面是说这么多年一直坚持的理念，就是One Web的理念。
还有一个非常重要的，也是这几年W3C决策层一直反复讨论的，就是Web是不是要及时看目前产业里发生的事情。
现在W3C存在的问题，实际上它对产业的反应是慢一拍，但这不是W3C的问题，做标准的组织都有这样的问题。
因为现在这个时代的变化速度比三十年之前，完全不是一个量级。你想让Web再活三十年，这是其中一个很直接的问题。Web是不是还要继续brozer fex？
其实这样的问题在W3C内部也有很多的讨论。
确实很多这样的讨论，这两年W3C也出现了很多讨论，可以看到中间有很多摩擦，我们也看到了for Selection、for Browser等等，这也是即将面对的问题。
当然，这个目标没错，主要是看从什么视角，不同的产业方代表的视角不太一样。
这也是W3C讨论沟通看怎么互相都可以忍受的结论出来，这可能就涉及双方都有一些特性。
相信最终选择支持我们，包括Google、微软，包括微软原来立项的时候，投票的时候是反对的，后来撤回了这个反对，我们也做了很多沟通。
最终大家认可这个目标，就是要壮大这个Web生态，肯定要尽可能兼容全世界各地发生的形态，这也是为什么W3C很多年前就做车、IoT、DID，和Browser没有什么关系，我觉得本着这样的目标，原来很多浏览器的大厂也选择同意看。
但是，我确实也同意你说的，同意做是一方面，但是最终同意最终的结果是第二步，所以过程中相信摩擦一直有，但是保持沟通。
宋青见：我只是代表个人观点，没有太强厂商的意思。其实我们也在讨论，Web是更好，标准更统一，它弥补了原来Web的一些能力不足，通过Vue和React之后，把这些进步再往前做一步。
小程序的现状就是这样，我们并不是在现状的基础上拆墙、砸墙，我们有没有可能在标准上引领一步？
当然我们可以看现在新的W3C标准，它们肯定有一定的道理、一定的好处，我们在这个基础上充分吸收一下，有一些考虑，标准就有一定引领性，很多时候是这样的期望。
如果说W3C说已经有的功能，Manifest做的只是简单的重复，意义并不大，对整个One Web意义并不大。所以是这个意思。
安勍：我很同意。目前进入工作组流程的service，肯定是经过了多次讨论，要么是从来没有，要么是基于现有的扩展，同意也是因为近期他们提供了一些意见。
有一点，一直以来很多人的观点是尽可能不要重复造轮子，我们在推标准的几个同事是认可的。
宋青见：说到这里，还有一个想法，Web这么一大块，它有历史的负担，三十年了，如果真的是说React Native，它最后说的东西就是加上CSS，不会再用很少的标签。
我觉得小程序这个东西的产物，包括它现有的技术，将来它对Web技术有个引领作用，它可以重新定义什么是Web need。现在Web再精简，对手表，对很多设备，或者对一些IoT设备，哪怕就是跑CSS，它内存就是做不到。
二十年前我们刚做电脑的时候，整个电脑也只有512，它也是在不断的臃肿。但是，我认为MiniApp有一个机会，它能够定义清楚，我觉得这也是标准上挺好的方向。
下面编译完了之后，也许是一个字集，也许只用了CSS某些属性或者大的属性，把它定义清楚，至少浏览器可以做小。因为发现MiniApp的模式，也许可以把我的merm定义清楚。
Web上还有profit的思想，还可以定义小、中、大，不同的方式实现可能是一个平衡的关系。
小程序发生在中国有一定的道理，但大家忙于自己的KPI，最后这种东西就流于一种东西，最后还是被别人捡过来，我们一看恍然大悟，原来这个东西是我们做的，但结果我们没有把它修成正果。
既然我们讨论到这一步，国外很重视，原因是这个东西商业上很成功了，而且商业上到了这个地位，但说良心话，我们的技术上还是太粗糙了，所有的方法没有条出React的水平，那些人再怎么做，目的不是技术应用，而是商业应用。所以技术上应该好好考虑，能力对One Web做很明确的贡献，这个东西就立住了。
与会者：我也挺赞同您讲的，我们理解的小程序价值，在技术上的价值可能更类似于重新定义一个真正有用的子集。
我很赞成，但是我自己也有一些疑问。
W3C制定的时候，历史上曾经有过这样的规范，我忘记是什么，可能是针对TV或者其他的子集，但逐渐都淘汰了，我不是特别清楚当时的情况。
与会者：当时有很多问题是场景设计去引领，但商业没有跟上。而小程序是反过来的，有那么大的优势，真的处在很好的位置。
关键看怎么定义，定义这个事是One Web就接受。
与会者：回顾起来，当时出的问题也不是技术上的问题。
与会者：对。整个电视就没有做起来，整个TV行业就没有做起来，因为这个行业在国外是被运营商垄断。
与会者：我觉得这是挺好的。如果我们认为这件事在技术上仍然是一个行得通的，只是因为历史上不是因为其他原因。
我们是否可以考虑？
王子韬：我觉得可以考虑。
与会者：因为我刚才提出的问题，至少我们这里有一个比较一致的意见，过去这个事情的失败。
不过我不太确定CSS group的人是怎么想的。
王子韬：拿出去讨论一下。
宋青见：我觉得这是一次很难得的，获取整个所谓的W3C大佬或者顶级的人想法，因为存在即合理，有这么大的商业模式非常难得。很多人说中国的商业模式不太容易复制，但是像高亮介绍的阿里的payment就到国外，但很多不能复制出去，到国外之后，反而最成功的方式还是Web，只是最原始的js grade的方法，商业上就出了，反而是我们倒推了。
比我们落后很多的东西，就已经在推了。国外是觉得这个方法可以借鉴，但在技术标准上要重视。我们还是要珍惜这个机会
是能对Web做很大的contribution，在西方，做正经事情都是在线上做，很好理解，人家大部分时间在跑步、休闲，中国不是这样，有很多人像我们这样开会，有电脑，但大量的人没有电脑，比如骑手。但是，中国的PC增长会上来，因为国外增长已经停滞了，越来越多的人会用PC，这是中国的现状。
不说非洲，看东南亚，大概是4%~6%。就想一想，我们做这个事情的意义。做这个事情的意义绝不是为了炫耀，因为现在已经足够用了，做这个事情应该是让更多人受益。
本来我们处在很好的站在那个点知道这个东西的来龙去脉，完全应该好好的总结、提炼、提升，造福更多的人。但是，很可惜因为我们的KPI，放弃了这个机会，说不定将来把这个东西发扬光大的人是非洲深。
所以，我想说的是既然我们讨论到这一步，要知道这个东西是干什么，要怎么样让这个东西更好的share。它长远应该是融入到Web里，让大量的设备甚至更低端的设备能基于Web，而不是Web过时了，重新拿V8出去跑一个什么东西，变成一个自有的东西，实际上它不是标准，技术上也已经非常深。这是非常好。
安勍：我同意你刚才说的，One Web的理念肯定是没有问题的，就是怎么达到路径的问题，原来的Web和新兴通到一起的时候，如果是单方面的迎合不是特别好的路径，所以为什么需要标准，就是因为有一个平台要去讨论。
这个话题可以收一收了。最后聊得有点发散。
回到我刚才说的几个CSS idea，后面可以在组内里聊聊这个话题。
我们会梳理一下，如果只是精简版的CSS反而比较好用，出一个code就好了，但新的CSS可以讨论讨论。
陈嘉恺：其实，纠结于先有规范还是技术的问题，类似于先有鸡还是先有蛋。这个问题没有必要过分纠结，整个Web行业和工业是非常像的。
有些东西不是先有标准，而是先有东西，先有实物之后再有标准。之所以有标准，是因为大家的实现都不一样，大家的结果都不互通，所以才需要一个标准进行统一互通，否则A厂做的零件，B厂根本用不了，不存不合适。
这个标准最终受益的是谁人？应该是开发者，厂商怎么考虑，用户在意吗？不在意。开发者在意吗？也不在意。我们想要的就是统一的开发方式、开发标准，用户要的是统一的体验，仅此而已。
与会者：有一个具体的问题，现在的Packaging里，理念是没有规定它一定需要是一个什么样的东西是吗？
所以，现在它只是一个格式的规定。
王子韬：对。现在更多层面上一种格式的规定，具体是统一范式Manifest，或者是统一范式的Lifecycle，这些都没有明确的规定，只是在签名方式等等做了定义。
与会者：我觉得前面的问题还是挺重要的。在现有的MiniApp工作组的厂商，在这一点上是不是有共识，将来Package是作为分发的标准，在各个厂商都可以直接跑，还是说它更类似于封装的格式，里面可以包含别的厂商所不能识别的东西。
不知道这一点是不是在working group讨论过这个问题。
王子韬：现在接到的很多需求，是否直接分发或者是互认的方式，我觉得也需要重新review一下。
之前我们得到的结论，之前平台厂商想到的方式，想到提供的统一范式，能否真正解决提出的新的问题，也需要进一步回头来看。
当时我们定的目标，现在是不是真的业界想要的目标，这又是需要进一步细化
宋青见：正好说到Packaging，我们是不是考虑研究Web的。
王子韬：其实之前bilibili和字节的同学也提过是否用流的方式打包，确实是有的。因为现在我们采用的方式，无论是块级还是小程序，都是以前的方式。现在在bilibili或者字节，流的分发方式，这种情况下怎么兼容程序也需要进一步讨论。
宋青见：因为Browser是二进制。但它缺少的是super app之间身份的互认，它考虑比较少，因为它还是更认所谓的website owner。
王子韬：这是相当于我们接到的新问题，无论是Web的反馈，还是业界同仁提出的新问题，工作组也要讨论用什么新的方式，之前讨论过一些一线的知识。
当然，充分交换意见的角度，把当时为什么这样设计讲一下。
要看一下新的需求是什么，怎么找一套路径。
安勍：好的。今天讨论已很充分了，今天的会议到此结束。
返回会议总结页面获取其他话题的会议纪要。