无javascript实现html弹窗的核心思路是利用css选择器或html原生特性控制元素显示与隐藏；2. 可采用:target伪类通过url哈希控制弹窗状态，但会改变浏览器地址；3. 使用checkbox hack结合label和兄弟选择器实现开关逻辑，结构稍复杂但不改变url；4.
HTML弹窗，或者说我们常说的对话框，不一定非得依赖JavaScript才能实现。很多时候，我们利用CSS的强大能力，或者HTML原生的一些特性，就能做出相当不错的无JS弹窗效果。核心思路无非是利用CSS选择器来控制元素的显示与隐藏，或者借用浏览器自身对某些标签的默认行为。
解决方案
要实现无JavaScript的HTML弹窗，我们可以从几个不同的角度入手，每种方法都有它的巧妙之处和适用场景。
1. CSS :target 伪类方案
立即学习“前端免费学习笔记（深入）”；
这个方案利用了URL的哈希（#）部分。当URL中的哈希值与页面中某个元素的ID匹配时，该元素就成为了:target。我们可以利用这个特性来控制弹窗的显示。
打开弹窗
2. Checkbox Hack 方案
这个方法听起来有点“黑科技”，但确实非常实用。它利用了HTML表单元素的checkbox和label，结合CSS的兄弟选择器（~或+），来控制其他元素的显示。
3. HTML
虽然它们通常用于折叠内容，但稍微变通一下，也能模拟出一种“弹窗”或“内容展开”的效果。它不是一个真正的模态框，但对于展示额外信息非常方便。
点击查看更多信息
这是`
`展开的内容这个内容区域可以用来展示一些非模态的额外信息。
点击标题或外部即可收起。
4. 原生 标签（配合open属性）
HTML5引入了原生的标签，专门用于创建对话框。虽然它的完整功能通常需要JavaScript来控制（比如showModal()方法），但我们可以通过直接设置open属性来使其在页面加载时就显示，从而实现一个无JS的初始弹窗。
注意： 尽管open属性可以无JS显示，但要实现其模态（modal）行为（比如按ESC键关闭、点击外部关闭等），或者动态显示隐藏，通常还是需要JavaScript。这里展示的是其最基本的无JS显示能力。
5. CSS :hover 或 :focus 结合定位方案
这种方案更适合做一些简单的悬浮提示、下拉菜单或者轻量级的信息展示，而不是严格意义上的模态弹窗。它利用父元素的:hover或子元素的:focus来控制隐藏元素的显示。
鼠标悬停或Tab聚焦这是通过CSS `:hover` 或 `:focus` 显示的内容。
当鼠标移开或失去焦点时，它会消失。
无JavaScript弹窗方案的适用场景和局限性是什么？
说实话，无JS弹窗方案最适合那些功能需求比较简单，或者对交互性要求不高的场景。我个人觉得，它们在实现一些“轻量级”的提示、公告，或者作为一种非侵入性的信息展示方式时，表现得相当出色。
比如，一个简单的“您已成功提交”的反馈弹窗，或者一个静态的图片预览（lightbox），用:target或者Checkbox Hack就足够了。它们的好处在于加载快，不需要额外的脚本文件，对于那些对性能有极致要求，或者需要支持老旧浏览器环境（某些CSS特性除外）的项目来说，是很有吸引力的。另外，对于内容管理系统（CMS）中，用户可能没有权限添加JS代码，但可以编辑HTML和CSS的场景，这些方案就显得尤为珍贵。
但局限性也挺明显的。最让我头疼的，就是它们的交互能力非常有限。你想让弹窗在用户点击弹窗外部时自动关闭？或者按ESC键就能关闭？无JS方案就很难优雅地实现这些。:target方案会改变URL哈希，这有时候会让人觉得有点奇怪。Checkbox Hack虽然不改URL，但HTML结构会稍微复杂一些，而且语义上不如那么清晰。:hover或:focus，它们更像是提示框或下拉菜单，而非阻断用户操作的模态对话框。
总的来说，如果你需要一个“真”模态、高交互性、有良好无障碍支持的弹窗，并且对现代浏览器兼容性有要求，那JavaScript驱动的方案几乎是不可避免的。无JS方案更像是一种巧妙的替代品，适用于那些特定、有限的需求。
如何确保无JS弹窗的可访问性（Accessibility）？
谈到无障碍性，这块确实是无JS弹窗方案的一个痛点，也是我每次使用时都会多考虑几步的地方。毕竟，我们希望所有用户，包括使用屏幕阅读器或者只用键盘操作的用户，都能顺畅地使用我们的网站。
首先，语义化HTML是基础。比如使用标签，它本身就带有一定的无障碍语义。虽然我们这里是无JS使用它，但其原生属性已经为屏幕阅读器提供了一些上下文。
其次，键盘可操作性非常关键。确保打开弹窗的元素（比如按钮或链接）可以通过Tab键聚焦。对于Checkbox Hack，label元素与input的关联是天然的，点击label就能触发checkbox状态改变，这本身就是一种良好的键盘和鼠标交互。但更进一步，当弹窗打开后，焦点应该如何管理？无JS很难实现“焦点陷阱”（Focus Trap），即当弹窗打开时，焦点只能在弹窗内部元素之间循环，而不能跳到弹窗外部。这会导致屏幕阅读器用户可能会在弹窗打开时，依然能导航到其背后的内容，造成混淆。
再者，提供清晰的视觉和文本提示。告诉用户如何关闭弹窗。例如，在弹窗内部放置一个“关闭”按钮（或链接），并且确保它可以通过键盘聚焦并激活。对于:target方案，点击弹窗外部的链接或者直接点击浏览器后退按钮，也能关闭弹窗，这需要用户知道。
最后，ARIA属性。虽然无JS方案不能动态添加或移除ARIA属性，但如果可能，在HTML中预置一些静态的ARIA属性，比如role="dialog"，aria-modal="true"（如果它确实是模态的），以及aria-labelledby来关联弹窗标题。即便没有JS动态管理，这些静态信息也能为辅助技术提供一些线索。不过，要完全满足WCAG（Web Content Accessibility Guidelines）中关于模态对话框的所有要求，尤其是焦点管理和状态通知，无JS方案确实显得力不从心。这让我经常思考，为了追求“无JS”而牺牲一部分用户体验和可访问性，到底值不值得。
CSS驱动的弹窗与JavaScript驱动的弹窗相比，性能上有何差异？
从性能角度来看，CSS驱动的弹窗和JavaScript驱动的弹窗，它们之间的差异还是挺有意思的。
CSS驱动的弹窗，通常在初始加载性能上占优。因为它们不需要额外的JavaScript文件被下载、解析和执行。这对于首屏加载速度（FCP, First Contentful Paint）和最大内容绘制（LCP, Largest Contentful Paint）这些指标来说，无疑是加分项。CSS动画和过渡通常由浏览器进行优化，甚至可以利用GPU进行硬件加速，这使得它们的渲染性能往往非常流畅，不容易出现卡顿。
然而，JavaScript驱动的弹窗，尤其是那些使用现代框架或库构建的，虽然可能需要额外加载JS文件，但它们在交互响应和复杂状态管理方面有着无可比拟的优势。JS可以精确控制弹窗的生命周期，比如在用户点击、滚动或满足特定条件时才加载弹窗内容，甚至可以实现懒加载。这在某种程度上减轻了初始页面的负担。
另外，JS可以对DOM进行精细操作，例如在弹窗打开时，禁用页面滚动；在弹窗关闭时，恢复滚动。这些都是纯CSS很难实现的。所以，虽然JS本身可能带来一些额外的CPU开销，但它提供的灵活性和更优的用户体验，在很多复杂场景下，反而能带来更好的“感知性能”。
我个人觉得，如果弹窗功能非常简单，只是一个静态内容的显示或隐藏，那么CSS方案无疑是更轻量、更高效的选择。但一旦涉及到复杂的逻辑、数据交互、或者需要高度定制的用户体验，那么JavaScript的介入几乎是必然的。这就像选择工具一样，没有哪个是万能的，关键在于根据具体需求来权衡利弊。
