作为陷阱的<noscript>元素

# 那个元素是一个陷阱 来源：https://hacktivis.me/articles/no-noscript-element Web 中为数不多的陷阱之一是 `<noscript>` 元素无法提供正确的行为。 定义：`<noscript>` 元素在 JavaScript 完全关闭或完全不支持时提供备选内容。 来源： - HTML4 § 18.3.1 `<noscript>元素 (NOSCRIPT element)` (https://www.w3.org/TR/html4/interact/scripts.html#h-18.3.1) —— 其中提到忽略非 JavaScript 内容（W3C 以 Tcl 为例，我更倾向于指出 JScript 和 VBScript，值得庆幸的是它们都已消失） - WHATWG HTML（多页版）§ `<noscript>元素 (the noscript element)` (https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element) 要实现正确行为，关键在于编写一个通用文本元素，通过你自己的脚本使用 DOM API 进行更新/删除。你也可以让脚本变得如此可选，以至于无需提供失败消息，但当页面实际需要脚本才能正常使用时，这并非正确方法。 需要注意的是，WHATWG HTML 中包含了一条类似于后一种方法的建议： > `<noscript>` 元素是一种粗暴的工具。有时脚本可能已启用，但由于某种原因页面脚本可能失败。因此，通常最好避免使用 `<noscript>`，而是设计脚本使页面从无脚本状态动态转变为有脚本状态，\[...\] 问题在于，JavaScript 可能以多种方式加载失败。以下是部分情况（非完全清单）： - 域名/URL 被拦截，例如广告拦截器/杀毒软件或企业防火墙 - 浏览器/用户被拦截，例如主机端防火墙（在 IP/TCP/HTTP/... 任意封装层级），可能出于合法、过度严格或意外原因 - 基本连接问题，例如使用移动数据浏览是常态，HTTPS 配置仍会定期出现过期证书，BGP/DNS/... 仍会失败 - 不支持的 API 甚至语言语法，可能是浏览器不支持前沿特性或不可移植特性 - 网站备份恢复不当或不完整 - 网站更新部署不当，例如 HTML 在 JavaScript 之前更新，甚至部署不完整 - 托管基础设施部分宕机或过载 - 托管方的限制，例如速率限制或总带宽限制 我定期遇到上述大部分情况，大约每周几次到每月几次，而且我浏览的往往是简单网站。这还不算脚本自身处理错误的各种失败方式。