文档【免费下载链接】htmlHTML Standard项目地址https://gitcode.com/gh_mirrors/ht/html点击查看免费下载本文以 WHATWG HTML Standard 官方仓库gh_mirrors/ht/html中的 FAQ.md 为骨架系统讲解现代 HTML 标准的开发模式Living Standard、HTML 与 XML 序列化的语法边界、DOCTYPE 与字符编码等实战细节以及 WHATWG 与 W3C 的分工协作机制。读完本文你将能回答HTML5 到底什么时候完成页面是否有效该怎么判断text/html与application/xhtmlxml有何区别为什么标准坚持不提供版本快照等高频问题并能在 source标准源码共 16 万余行中定位对应规范的原始定义。HTML 标准是什么一个没有版本号的 Living StandardHTML 的定义与HTML5的含义按 FAQ 的定义HTML 是 WHATWG 社区正在推进的核心基础标准。它不是某一版的修订而是一个持续维护的规范取代了 HTML4、XHTML1、DOM Level 2 HTML 以及此前所有 HTML 规格既弥补了旧规格的诸多缺陷又把 HTML 增强到足以覆盖 Web 应用的需求。除了定义 HTML 标记语言本身它还定义了构成 Web 运行时基础的许多核心要求。关于HTML5这个词FAQ 给出了一个重要澄清WHATWG 往前只维护HTML这一份文档不再纠结版本号。人们在 WHATWG 语境下说HTML5时通常指的是最新的 HTML 工作而非某个特定版本。标准正文的 HTML vs XML syntax 一节也印证了这一点本规范定义了两种具体语法——HTML 语法建议大多数作者使用兼容大多数旧浏览器以text/htmlMIME 类型传输和 XML 语法以application/xhtmlxml等 XML 媒体类型传输由 XML 处理器解析。XML 语法过去被称作XHTML但本规范刻意不再使用该术语。为什么没有稳定快照、没有版本FAQ 从三个角度论证不提供稳定快照的合理性实现都跟随最新标准实际中所有实现都以最新标准为准所谓已完成的快照反而成为过时信息。快照是已知错误的集合跟随快照意味着实现已知的错误。这曾在 W3C 真实发生过——错误在编辑草案中被修复但未深度参与的实现者却去实现了含 bug 的过时快照导致浏览器之间出现严重差异。旧文档由单一实现统一覆盖浏览器并不按 HTML、HTML2、HTML3.2、HTML4、HTML4.01 等分版本实现而是只有一套同时覆盖所有历史版本的实现——这正是 HTML Standard 所定义的如何编写一个能处理所有历史版本 HTML及全部最新特性的浏览器。标准与 WHATWG 的目标之一是让几百年后的考古学家仍能写一个浏览器来看任意年代的 HTML 内容。不做版本划分不仅不妨碍这一点反而使其更容易。FAQ 还解释了两个衍生问题2022的旧闻在 Living Standard 模式之前WHATWG 曾计划把标准送入 W3C 流程。当时 W3C Recommendation 的门槛极高例如两个完整且可互操作的实现达到 100% 测试覆盖。2008 年编辑估算还需 14 年即 2022 年才能达到理由是参考了 HTML4 和 CSS2/2.1 这类大型规范的工作量。后来大家意识到瀑布式开发不适合标准制定于是改为持续开发、边加测试边用实现验证——2022 这个年份便不再有意义。页面何时会失效FAQ 明确旧页面是否有效并不重要。有效性validityWHATWG 更常称之为文档一致性 document conformance是一种质量保障工具用于帮助作者避免笔误之类的错误。它是给你写新页面时提供最新建议用的——对照上周的规则做校验毫无意义因为本周已经修正了那些规则中的错误。标准的稳定性、追踪方式与阅读形态关于稳定性FAQ 说明整个标准大体稳定新技术的加入会等待设计本身趋于稳定且按 WHATWG Working Mode 的要求必须获得两个或以上实现者的支持才会被纳入。追踪标准变更的渠道包括htmlstandard的 Twitter 推送仓库的 GitHub commits 日志直接使用任意 Git 客户端检出 source 最新版本用 diff 工具对比修订。标准提供三种阅读形态单页版体量巨大、多页版、以及面向开发者的 Developers Edition。W3C 曾发布过的分叉版本已停止维护现均重定向到 HTML Standard。判断某个特性能否在生产中使用FAQ 推荐的资料源包括 caniuse.com、developer.mozilla.org以及 html5doctor.com、diveintohtml5.info 等站点若你发现更好的资源可以向 FAQ 提交 PR 补充名单。设计理由是否被记录FAQ 承认设计理由部分有记录通常散落在 GitHub issue 讨论、提交日志、邮件列表与聊天归档中规格正文偶尔也会解释但不可能处处展开。少数被专门记录的设计决策可参见 WHATWG 的 Rationale 页面以及为什么不用命名空间Why no namespaces为什么没有 script implements为什么不复用 legend 作为小型标题元素等专题讨论。HTML 语法核心问题序列化、DOCTYPE、命名空间与字符编码HTML 序列化与 XML 序列化的区分FAQ 给出了两个关键定义HTML 序列化HTML serialization指 HTML 规范定义的文档语法灵感来自早期 HTML 的 SGML 语法、部分 XML 元素如 void 元素允许尾斜杠、xmlns属性以及 Web 上真实部署的内容。任何媒体类型被判定为text/html的文档都被视为 HTML 序列化必须用 HTML 解析器解析。XML 序列化XML serialization指 XML 1.0 与 Namespaces in XML 1.0 定义的语法。以application/xhtmlxml、application/xml等 XML 媒体类型交付的资源是 XML 文档根元素为 HTML 命名空间下html的 XML 文档常被称为XHTML文档。MIME 类型text/html与 XML 媒体类型的强制约束FAQ 的规则非常硬性HTML 序列化必须以text/html媒体类型提供XML 序列化必须以 XML 媒体类型如application/xhtmlxml提供且规范明确要求XHTML文档不得以text/html交付——这与 XHTML1 时代不同。用错误的text/html类型交付 XML 序列化文档会导致它按 HTML 解析规则被当作tag soup处理只有使用 XML 媒体类型才能保证浏览器按 XML 处理。这正是 source 中HTML vs XML syntax一节反复强调的重点HTML 与 XML 的处理机制不同即使是很小的语法错误也会让 XML 文档无法完整渲染而这些错误在 HTML 语法中会被宽容忽略。DOCTYPE现代 HTML 文档的写法与 legacy-compat 变体FAQ 给出了两类 DOCTYPE!DOCTYPE html!DOCTYPE html SYSTEM about:legacy-compat在text/html文档中!DOCTYPE html是推荐的写法。XML 媒体类型文档不强制要求 DOCTYPE但如果你想用例如用于 polyglot 文档或声明实体也可以。第二条 legacy-compat 变体仅面向无法输出上述短 DOCTYPE 的旧式 HTML 生成工具与旧浏览器的兼容性无关。source 的 The DOCTYPE 一节给出了更精确的语法定义DOCTYPE 必须按序包含 ASCII 大小写不敏感的!DOCTYPE、至少一个 ASCII 空白、ASCII 大小写不敏感的html、可选的 DOCTYPE legacy string以及。legacy string 必须为空白 大小写不敏感的SYSTEM 空白 成对的引号双引号或单引号包裹的字面字符串about:legacy-compat即!DOCTYPE html SYSTEM about:legacy-compat或单引号版本除引号内部分外大小写不敏感。源码中还特别注释了 DOCTYPE 是虽然基本无用但必需的序言——省略时浏览器倾向于使用与某些规范不兼容的不同渲染模式加上 DOCTYPE 才能确保浏览器尽力遵循相关规范。FAQ 还总结了这些 DOCTYPE 被选中的六条标准在所有当前及相关的旧浏览器中触发标准模式standards mode是良构的 XML现存标记生成器至少能输出其中一种刻意不含语言版本标识使 DOCTYPE 在 HTML 未来所有修订中持续可用第一个写法简短易记鼓励使用legacy-compat 写法刻意不吸引人且自我说明用途抑制滥用。大小写方面除about:legacy-compat字符串外text/html下 DOCTYPE 大小写不敏感XML 媒体类型下则大小写敏感且只能是上述两种变体因此推荐统一使用上面的小写写法。XML 媒体类型文档中的 DOCTYPE 何时合理FAQ 给出三种场景文档是 polyglot同一文本既可当 HTML 也可当 XML 处理需要声明文档内实体引用注意多数浏览器只读内部子集、不获取外部实体这与 HTML 不兼容故不适合 polyglot使用自定义 DTD 做基于 DTD 的校验但需留意 DTD 本身的缺陷。HTML4 及更早文档如何解析统一解析器FAQ 明确所有text/html文档包括不带 DOCTYPE 或带 HTML2.0/3.2/HTML4/XHTML1 DOCTYPE 的都由 HTML 规范定义的同一个解析器算法解析。这与浏览器迄今的实际行为一致并降低了代码复杂度从而有利于安全性、可维护性和减少 bug。HTML 语法因此不需要按版本区分解析器——带 HTML4 DOCTYPE 的文档同样按 HTML 规范描述的方式解析。校验器validator则被允许为早期 HTML 级别保留不同代码路径。void 元素尾斜杠/与之争FAQ 的回答直接了当HTML 中的 void 元素如br、img、input不需要尾斜杠写br即可与 HTML4 一致。但由于 XHTML1 的广泛影响仍有大量页面使用br /因此 HTML 语法允许void 元素带尾斜杠以方便从 XHTML1 迁回 HTML。source 给出了权威的 void 元素清单area、base、br、col、embed、hr、img、input、link、meta、source、track、wbr另有basefont、bgsound、frame、param、keygen被解析器按 void 处理但属于不合规元素。void 元素只有开始标签不得指定结束标签。值得注意的特殊情况HTML 规范还引入了在math元素内嵌 MathML 的能力——在math元素内部尾斜杠的行为与 XML 一致即闭合元素但这只限于该上下文对普通 HTML 元素无效。能否用 XML 解析器处理我的 HTML 文档FAQ 的忠告是必须极其小心才可能成功而且几乎不值得。更好的做法是直接使用 HTML-to-XML 解析器正常写 HTML 的同时仍能接入 XML 流水线工具。HTML 与 XHTML 的完整差异清单可参考 WHATWG wiki 的 HTML vs. XHTML 专题。命名空间HTML 没有命名空间语法但有 MathML/SVGFAQ 与源码共同给出了完整图景XML 语法中必须声明命名空间html xmlnshttp://www.w3.org/1999/xhtml在text/html中xmlns属性目前允许出现在任何 HTML 元素上但只能取值http://www.w3.org/1999/xhtml且它不产生任何效果——仅为从 XHTML1 迁移而开放因为 HTML 本身不支持命名空间HTML 以 DOM 来定义解析text/html时所有 HTML 元素自动进入 HTML 命名空间http://www.w3.org/1999/xhtml作者无需也无法在标记中声明HTML 语法还提供内嵌 MathML 与 SVG 元素的通道放入容器元素math或svg内的元素由解析器分别自动归入 MathML 命名空间与 SVG 命名空间命名空间语法同样不是必需的但xmlns属性若取值正确也可使用。结论HTML 虽不允许 XML 命名空间语法但在 DOM 层面以合理兼容的方式支持了 MathML、SVG 内嵌与受约束的xmlns属性。字符编码UTF-8 是唯一合规范编码FAQ 规定无论text/html还是 XML 媒体类型交付UTF-8 是唯一符合规范的字符编码。对于 HTML强烈推荐用 HTTPContent-Type头指定编码无法配置服务器时再使用meta元素meta charsetUTF-8三条硬性限制必须遵守编码名必须与实际序列化文件所用的编码一致编码声明不得以字符引用character reference或转义形式序列化用于此目的的meta元素必须出现在文件开头附近——FAQ 表述为前 512 字节内且最佳实践是作为head的第一个子元素而现行 source 已把该要求收紧表述为编码声明必须完整序列化在文件前 1024 字节内源码 同时说明用户代理只对前 1024 字节做编码预扫描作者应把声明放在足够靠前的位置。为兼容旧工具也允许传统写法不适用于 XML 语法文档meta http-equivContent-Type contenttext/html; charsetUTF-8XML 媒体类型文档遵循 XML 的编码规则meta元素不参与编码判定应使用 HTTPContent-Type头或 XML 声明?xml version1.0 encodingUTF-8?不过未显式声明编码的文档按 UTF-8 处理因此合规范文档并不强制要求 XML 声明。HTML DOM 与 XML DOM 的最佳实践FAQ 给出了两条务实建议用于兼容两种 DOM大小写敏感性尽量避免直接测试element.tagName与node.nodeName或先toLowerCase()再比较命名空间创建元素时使用命名空间感知的document.createElementNS(ns, elementName)。标准真的合法化了 tag soup吗FAQ 专门辟谣没有。这是混淆了对文档的一致性要求与对用户代理的处理要求造成的误解。由于支持已有内容这一根本设计原则规范必须定义如何处理所有HTML——无论文档是否合规范——因此精确定义了从错误标记大量被称为 tag soup 的内容中恢复的算法例如针对标签嵌套错误的处理保证能产出结构良好的 DOM 树。这是实现浏览器互操作、避免浏览器互相逆向解析行为的关键。但作者的一致性要求与处理要求是分开的浏览器必须处理错误内容不等于错误标记就合规。典型例子用户代理必须支持处理marquee元素但作者不得在合规范文档中使用marquee。两套规则完全正交。HTML 功能提案与设计权衡为什么好主意没有被采纳FAQ 收录了多个高频功能提案及其否决或替代方案其中体现的决策方法值得所有 Web 开发者理解。为什么不支持任何元素都可加hrefFAQ 的回答很实在规范允许a包裹块级内容但不支持把href放到任意元素上。原因包括浏览器厂商报告实现成本极高厂商决定实现什么向不打算实现的方向提要求没有意义与现有浏览器不向后兼容用a元素加一点脚本就能实现同等功能对input、button等交互元素来说href会干扰其固有功能。唯一的好处只是作者少打几个字不足以抵消上述成本。要把表格行变成链接FAQ 给出的替代方案是tr onclicklocation this.getElementsByTagName(a)[0] ... /tr列表标题figure/figcaption与定义列表给列表加标题可以用figure与figcaptionfigure figcaptionApples/figcaption ul liGranny Smith/li liEvil Apple of Knowledge/li liApple, Inc/li /ul /figure也可以用定义列表给一组列表分组标注dl dtDry:/dt dd ul li1c flour/li li1/4c sugar/li li1tsp baking soda/li /ul /dd dtWet:/dt dd ul li1 egg /li li1/2c milk/li li1tsp vanilla extract/li /ul /dd /dlFAQ 明确这些方案优于 HTML3 草案中提议的lh元素主要是因为li附近的解析问题非常棘手。发明新元素不止一条路FAQ 指出除自定义元素外HTML 其实提供了大量扩展机制自定义元素custom elements用 source 中描述的机制构建功能完备的自有 DOM 元素合法自定义元素名必须带连字符这一要求确保了前瞻兼容未来不会有含连字符的 HTML/SVG/MathML 元素名与之冲突。class属性扩展在语义最贴切的现有元素上叠加 classMicroformats 即采用此法。data-*属性存放脚本处理的扩展数据浏览器保证永不触碰。source 对该机制给出完整定义任何 HTML 元素都可带任意数量、任意取值的data-*属性用户代理不得从这些属性推导任何实现行为规范也不得为它们定义有意义的取值。DOM 侧通过element.dataset返回DOMStringMap访问连字符名自动转为驼峰——data-foo-bar对应element.dataset.fooBar。标准还给出了一个贴近实战的例子用data-has-payment-request记录PaymentRequest特性检测结果供 CSS 差异化渲染结算页。对库作者标准建议把库名放进属性名如data-doquery-range、data-jjo-range避免冲突并可提供 API 让调用方自定义前缀。meta name content页面级元数据名字需在 wiki 的 MetaExtensions 页注册。rel机制给链接标注特定含义名字需在 RelExtensions 页注册。script type自定义类型嵌入原始数据供脚本处理。embed插件Flash 即以此方式工作。JS 原型扩展脚本库广泛使用。microdataitem与itemprop嵌入供其他应用与站点共享的嵌套键值对。提案流程向标准提议新元素/属性若社区与用户代理厂商认可其价值即可加入语言。dl中的分组用div包住dt/ddHTML 允许在dl中使用div作为分组元素见 source 中dl元素的定义以及 whatwg/html issue #1937该特性即由此引入。为什么不再增加命名字符引用FAQ 给出的结论是编辑器与浏览器引擎实现者的共识是扩充命名字符引用列表对生态不值。理由有三层向后兼容性差新增写法只是同一件事的新写法不会增加新能力数字字符引用或未转义码点已能表达且旧浏览器会显示错误收益可被预处理语言替代编译到 HTML 的 Markdown、wiki 语法、JSX、服务端模板等可自行实现该能力浏览器侧新增只惠及手写原始 HTML 的作者影响面远小于通用平台特性最关键的HTML 解析器对安全性极其敏感whatwg/html issue #919 有详细讨论。解析器任何改动都可能在标记生产者与消费者未全部升级前造成不一致进而引发安全漏洞。因此解析器改动必须为生态带来极高的价值才值得承担风险——命名字符引用显然达不到这个门槛。给平台加任何特性都有成本FAQ 列出每个 Web 平台特性的完整成本清单实现每个浏览器都要写代码、测试写用例验证、QA定期回归、代码维护重构时涉及面更大、教程作者要学习/回应反馈、认知负担作者文档、额外特性抑制探索、页面维护接手页面的人要理解该特性、规范写作与维护、bug 修复从修复到发布再到文档更新的全链条、代码体积浏览器二进制与内存占用都增加。这解释了 WHATWG 对特性准入为何如此审慎。使用 HTML被保留的语义元素与常见困惑为什么b、i、small这类表象元素还在FAQ 的解释是务实的保留它们源于广泛使用以及它们覆盖了更具体元素照顾不到的用例。i虽然斜体的常见用例可由em强调、cite引用标题、dfn定义、var变量覆盖但分类学名称、科技术语、外语惯用语、内心想法、船名等用例没有合适专用元素。b加粗的常见用例可由strong、h1–h6、th覆盖但文档摘要中的关键词、评测中的产品名等则没有。有人主张这些情况应改用span class 样式表但b/i在不支持样式表或不渲染视觉的环境中如屏幕阅读器提供了合理的回退外观也提示文本与周边内容有所区别。本质上是i与b传达不同但非特定的语义具体含义由读者结合上下文判定。small则定义给通常以小字排版的内容版权声明、免责声明、法律文本。对它们是表象元素PRESENTATIONAL的质疑FAQ 的回答值得注意font这类元素的问题不在于表象本身而在于媒体依赖只适用于视觉浏览器不适用于语音浏览器。b、i、small虽然历史上是表象的但在 HTML5 中被定义为媒体无关——例如small对应电台广告结尾那段语速很快的话。为什么cite只用来标记标题FAQ 坦言历史实践无法提供答案——cite几乎总是被当作斜体用更细心的作者用它标记人名和标题也有人专门用它标记引用。于是只能问如果保留这个元素最有用的用途是什么结论是用于标题titles的排版控制标题常被斜体化该语义与旧版本含义接近也契合至少一种常见用法。而人名与标题通常排版方式不同让一个元素同时覆盖两者会造成混乱的排版。标记人名已经有 hCard 微格式、microdata 的 vCard 词汇、span class 等多种方式。section、article等结构化元素的使用提示FAQ 给出三条操作性建议一个直观的判定法你会如何画出页面大纲/目录目录中的每一项都应该是section/article/aside/nav如果它不在目录里、又没有标题那很可能不该用这些元素。仍然可以使用div当 CSS 无法满足你的需求、需要一个样式钩子时div就是正确元素。section通常应以包含节标题的标题元素开头这不是硬性规则但如果加标题反而别扭你多半需要div而非section。结构上节与文章可以互相嵌套可以有新闻节、社论节、体育节每节包含多篇文章每篇又可有小节每节可有评论用article标记评论大得足以再分section……依此类推。WHATWG 与 W3C分工、权威与协作流程两个群组会合并吗FAQ 明确不会。两组目标不同——WHATWG 负责制定标准W3C HTML WG 的目标是把 WHATWG 的 HTML Review Drafts评审稿背书为 W3C Recommendation。仓库 review-drafts 目录中保存了从 2018-07 到 2026-07 共 17 份评审稿.wattsi格式正是该流程的实际产物。双方流程由 2019 年的 WHATWG-W3C 谅解备忘录MOU约定。WHATWG 侧编辑通过 GitHub issue 追踪器接受来自所有参与者和组织的反馈包括 W3C、Ecma 等其他标准机构且编辑在决定技术走向时不会看论据来源。争议时谁有权威合并权WHATWG 编辑按 WHATWG Working Mode 决定哪些内容并入 Living Standard。社区包括 W3C HTML WG 成员若对编辑决策有异议可向 WHATWG Steering Group 发起 issue 讨论workstream policy 中的上诉机制。W3C 侧W3C HTML WG 参与者可走 MOU 中的冲突处理程序向 W3C 内部表达关切最坏情况下该群组可选择不把 WHATWG HTML Standard 的最新内容背书为 W3C Recommendation。HTML 的历史资料FAQ 推荐了三处历史文档现代 Web 平台特性史2003 年起、W3C HTML WG wiki 上的 HTML 时间线1997–2008以及 HTML Standard 正文中的历史章节。那些曾经的规范去了哪里Web Forms 2.0已并入现在的 HTML Standard。Web Controls 1.0被时代超越而废弃其问题空间如今主要由 ARIA 与 Web Components 覆盖。DOM ParsingWHATWG 主动放弃——W3C 把这份规范维护得更好WHATWG 不想在市场造成混乱当另一组织发布了覆盖同一技术的规范时只有在我们自己的版本技术上更优的情况下才会继续发布。在仓库中进一步研读HTML Standard 的源码形态想验证本文所有论断可以直接在当前仓库研读原始材料source标准的 wattsi 专有格式源文件163,457 行仓库根目录注释明确声明此文件不是 HTML而是一种专有语言后处理为 HTML。DOCTYPE 语法见 The DOCTYPE 一节void 元素清单与元素分类见 Elements 一节编码声明的前 1024 字节要求见 source自定义数据属性与dataset见 sourceHTML vs XML 语法总述见 source。review-drafts2018-07 至 2026-07 共 17 份 W3C 评审稿快照。README.md仓库入口说明构建与贡献方式.github/CONTRIBUTING.md 详述如何从source构建 HTML 输出以本地预览改动。Makefile默认目标指向 CONTRIBUTING.md 中的构建说明可作为查看标准渲染管线的起点。styles.css、html-dfn.js、link-fixup.js、var-click-highlighting.js、dev/search.js标准的样式与浏览器侧脚本工具demos 目录则收录了 canvas、Worker、模块系统等配套示例可作为理解运行时特性如多线程 Worker、Crypto 模块的补充材料。FAQ 全文本身就是一份标准设计哲学的浓缩读本它展示的不是琐碎的答疑而是一套以互操作性、向后兼容、生态成本为硬约束的决策方法论。理解 Living Standard 无版本快照的缘由、HTML/XML 序列化的边界、!DOCTYPE html背后的六条选择标准以及作者一致性要求与用户代理处理要求的正交关系是深入使用与贡献 HTML 标准的起点。赞分享文档【免费下载链接】htmlHTML Standard项目地址https://gitcode.com/gh_mirrors/ht/html点击查看免费下载相关推荐standard代码风格RAP2-delos团队协作编码规范standard代码风格RAP2 delos团队协作编码规范 代码规范配置基础 RAP2 delos项目采用TSLint作为TypeScript代码检查工具后端开发工具API设计Dioxus应用无障碍测试确保符合WCAG标准Dioxus应用无障碍测试确保符合WCAG标准 Dioxus作为全栈GUI库支持开发跨平台应用程序。为确保所有用户都能顺畅使用Dioxus应用进行无障碍测前端跨平台UI组件桌面应用移动开发上海交通大学飞跃手册使用技巧3分钟找到你的目标专业案例上海交通大学飞跃手册使用技巧3分钟找到你的目标专业案例 上海交通大学飞跃手册是一款专为交大学子打造的留学申请经验库汇集了各学院学长学姐的真实申请案例与心得。文档知识库教育创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考