有一天,突然之间,我开始听到关于吐司的笑话。我不知道上下文是什么。我以为一些朋友只是开始讲吐司笑话,这并不罕见。但事实证明这是一件大事。这让我开始思考,如果连我这种有点工作性质的人也跟不上这种潮流,那么那些真正工作的人肯定更加难以应对。
无论如何。谢天谢地,Jeremy 对此进行了很好的总结
首先,这一切都始于 “有意实施” 的宣布。这听起来像是 Google 打算……实施。事实上,“有意实施”实际上意味着“有意在标记后面对此进行一些操作”。这种语言绝对令人困惑,这是 希望得到解决的问题。
其次,Chrome 不会发布一个
toast
元素。相反,这是 一个对当前称为std-toast
的自定义元素的提议。我认为,如果实验证明成功,最终的元素名称并非一定会称为toast
。
围绕它的戏剧性,因此也是所有笑话和诸如此类事情的原因,是它感觉像是突然出现,并且 Chrome 在标准化流程中强行推行一项功能,或者也许是略过了这个流程。Terence 的幽默文章 更深入地探讨了这一点。
我不确定 Google 是否真的在这里做了一些不道德的事情。它是在标记后面,所以我想这点的目的是探索和研究。对我来说,感觉非常类似于 kv:storage,它是一种“原生模块”,就像一个“原生自定义元素”。
但是我们应该对这类事情格外警惕。如果任何浏览器都开始肆意妄为,直接发布一些东西,那么网页标准就完了。开发人员的生活会变得更加艰难,网页也会变得更糟。利害关系重大。而且这不会在一夜之间发生,而是会像这样,以微不足道的小事开始。保持蓝色贝雷帽。
关于这个元素本身,我总是很惊讶地看到哪些东西最终会成为新的 HTML 元素。在我看来,吐司只是定位的 <dialog>
,但我没有参与任何研究或其他活动。它们很流行,足以让 Bootstrap 拥有它们
查看笔
Bootstrap 吐司 作者:Chris Coyier (@chriscoyier)
在 CodePen 上。
我会猜想类似下拉菜单或选项卡这样的东西应该是“原生”Web 组件的最强竞争者。
我个人认为下拉菜单目前可以通过
details
最好地实现;否则实现起来很烦人。吐司非常小,并且可以采取 n 个操作(通常为 1 或 0)。它们是非必需的通知;并且往往从一个已知位置(例如左下角、右上角、底部居中)出现。想想
alert
,但是非阻塞的。我个人认为他们只是选择了最容易编写的东西。
至于下拉菜单(尤其是下拉菜单),我认为 github 的
details-menu-element
目前是最好的(目前 unpkg 处于停机状态。请认真考虑在您自己的依赖项中托管 github)…选项卡列表在大多数情况下也不适合;但我看到它们在具有许多项目的以用户为中心的分类内容列表(例如 Tachiyomi 等图书馆应用程序)中具有合法用例,在这些列表中您可能在内容之前知道容器名称。
而我在这里仍然像个白痴一样想要容器查询…
感觉 Google 的开发人员只是沟通不佳,但这暗示了浏览器开发和 Web 标准可能存在一个邪恶的方向。现在我们又回到了双浏览器世界(某种程度上),这可不是什么好兆头。但我很好奇,微软是否对 Chromium 的采用意味着现在有更多的声音来指导项目的方向?这种整合在多大程度上对事物有所帮助?