为什么将HTML派生为静态语言没有意义

2020-06-22 22:23:31

通常有人会提出这样的建议:HTML不应该发展成今天这样的变异应用程序运行时。文档的表示关注点与应用程序呈现不同。javascript堆栈应该是完全独立的。我强烈认为我们应该创建一个轻量级的HTML fork,它同样是以文档为中心的,并且不允许所有这些javascript的胡言乱语。一些不允许愚蠢的自定义用户界面或行为跟踪的东西。只有文本、图像、视频和链接。绘制算法将非常简单,文档加载将闪电般的快,我们相信不会有广告恶意软件。

我决定写这篇博文,而不是直接回复,这样下次我就可以再看一遍。这里有不正确的事实假设。文档的表现关注点与应用程序呈现不同;呈现是不正确的;有很多重叠,静态文档和交互式应用程序之间有一个连续体,用例一直都在这个连续体中。不允许愚蠢的自定义用户界面或行为跟踪的东西。仅仅文字、图像、视频和链接是矛盾的;嵌入的图像、视频和链接允许大量的跟踪和自定义UI。一个更大的问题是,定义HTML的静态分支很容易,但说服Web开发人员使用它才是真正的问题所在,而这是非常困难的,而且没有人知道如何做到这一点。当然,如果您确实找到了说服Web开发人员避免您不喜欢的功能的方法,那么定义一个特定的HTML静态子集就没有多大价值了。顺便说一下,我刚刚撒了部分谎。定义HTML的静态分支很容易,但我敢肯定,每个认为现代Web已经脱轨的人都有一个略微不同的应该允许的功能列表,所以让你的整个支持者就允许的功能的具体列表达成一致将是非常困难的。(例如,表单是否在该子集中?心满意足吗?录像?动画GIF?CSS:悬停?CSS媒体查询?对于这些问题,不同的人会给出不同的答案。)。有些人认为定义HTML的静态子集将使Web开发人员和用户受益,因为我们可以为该子集构建更高效的浏览器(或浏览器模式)。作为一名前Mozilla杰出工程师,我对此表示怀疑。即使像窗口大小更改这样的基本操作也需要增量重新布局的能力。任何类型的编辑或表单都需要支持DOM更改,递增加载文档的呈现也是如此。你可以走几条捷径,但在相同的内容上,你不会轻易击败现有浏览器的性能,特别是要记住,那些浏览器已经实现了令人难以置信的优化。我看到定义的静态HTML子集唯一可能的好处是,对于选择加入该子集的文档,浏览器可以将所有这些文档放入单个沙箱子进程中,而不是将它们拆分到每个站点的不同沙箱进程中,前提是这些文档对彼此的安全风险可以忽略不计。我不认为这是静态HTML子集倡导者最关心的问题。