不是有效html标签，浏览器不识别，无语义、样式或行为支持；其功能应由实现，并须包裹在中，配合或aria-label确保可访问性。

<search></search> 是当前最直接、最标准的语义化包装方式，但它不能单独用——必须配合 <form></form> 和 input[type="search"] 才能形成完整、可访问、可提交的搜索区域。

为什么不能只用 <search></search> 包裹一个 <div> <p><code><search></search> 不是装饰容器，它的语义是“提供搜索或过滤功能的交互区域”。如果里面没有表单控件（比如 <input type="search">、<select></select> 或 <button></button>），屏幕阅读器和搜索引擎会忽略它，甚至部分浏览器尚未实现其原生行为支持。

• 仅写 <search><div>搜索框</div></search>：无语义价值，等同于没写
• 正确结构必须含可操作控件，例如 <input type="search" name="q"> 或带 <button type="submit"></button> 的表单
• 若用 <search></search> 但浏览器不支持（如旧版 Firefox），降级策略是加 role="search" ——但注意不要同时写 <search role="search"></search>，属冗余

<search></search> 和 role="search" 能否混用

不能。W3C 明确要求：当元素已有原生语义标签（如 <search></search>、<nav></nav>、<main></main>）时，禁止再添加对应 ARIA role。这会导致辅助技术重复播报或逻辑冲突。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• ✅ 正确：<search><form><input type="search" name="q"></form></search>
• ❌ 错误：<search role="search">...</search> 或 <form role="search">...</form>
• ⚠️ 降级写法（仅在需兼容极老环境时）：<form role="search">...</form>，此时绝不可套 <search></search>

搜索框该放在 <header></header> 还是 <main></main> 里

99% 的站内全局搜索框应放在 <header></header> 内，而不是 <main></main>。这是由内容功能决定的，不是样式位置问题。

• <header></header> 表示页面或区块的“头部”，天然适合放 logo、主导航、全局搜索——它们都是用户进入页面后最先接触的导航性工具
• <main></main> 只能有一个，且必须包裹用户真正想看的**主体内容**（如文章正文、商品列表）。把搜索框塞进去，等于告诉搜索引擎“这是核心内容”，反而稀释权重
• 例外场景：某页本身就是搜索结果页，顶部的筛选控件可用 <search></search> 包裹并置于 <main></main> 内部，但此时它属于“对结果的二次过滤”，不是全局入口

如何确保 <search></search> 区域真正可访问

光有标签不够，还得补全可访问链路：焦点管理、label 关联、键盘操作支持缺一不可。

• 必须为 <input type="search"> 提供显式 <label for="id"></label> 或用 aria-label；placeholder 不算 label，输入时就消失，不满足 WCAG 2.1
• 若用 <button type="submit"></button>，确保它和 input 在同一 form 内，否则键盘用户按 Enter 无法触发
• 监听 Escape 键清空输入是加分项，但非强制；若移除了默认清除按钮（如 WebKit 中隐藏 ::-webkit-search-cancel-button），就必须提供替代清空方式
• 高对比度模式下，清除按钮图标可能变透明，需用 color-scheme: light dark 或显式设置 SVG 图标 fill 颜色

真正容易被忽略的是：语义标签只是起点，<search></search> 的价值只有在配合正确的表单结构、可访问属性和用户交互路径时才会生效。写对标签只是第一步，后续的 focus 流、键盘支持、错误反馈，才是让搜索框“活起来”的关键。