AI 摘要：本文讲述了 CSS zoom 属性如何从 IE 5.5 的非标准功能开始，被开发者滥用、误解、依赖，进而导致兼容性困境。随着 CSS transform 出现，zoom 一度被各浏览器忽略或不一致实现。但由于其在布局层面的独特作用，开发者持续呼声使其最终被纳入 W3C 规范，并在 Interop 2025 得到统一支持。这段历程反映了 Web 标准在兼顾创新与兼容中如何形成共识。

1. 非标准的起点
• 2000 年 IE 5.5 引入 zoom，允许元素放大或缩小，但缺乏正式规范。
• 各浏览器厂商竞相差异化实现，造成碎片化问题，开发者不得不写兼容代码。

2. 替代与取舍
• Mozilla 坚持标准化，未支持 zoom，转而推动 CSS transform。
• Safari 同时实现 transform 与 zoom，导致实现差异与兼容问题。
• zoom 因缺乏标准，处于既流行又边缘的尴尬位置。

3. 使用误区与“伪流行”
• 后续研究发现 zoom 使用率虚高，原因多是用 zoom:1 修复 IE 的 layout bug。
• 通过 HTTP Archive 数据分析，排除 zoom:1 后，实际真实使用率下降约 94%。
• 意味着 zoom 的高排名不过是兼容遗留问题，而非开发者真正需求。

4. 开发者诉求与再度回归
• 部分高流量 Web 应用（如 Excel Web、Gmail 移动端）需要 zoom 的布局影响特性。
• 2023 年 CSS Working Group 提出重新定义 zoom，简化并规范化语义。
• 2025 年进入 Interop 计划，获得主要浏览器支持，终于成为标准化功能。

5. 经验与启示
• Web 的共识虽慢，但能孕育开放与长期可持续的方案。
• 避免依赖专有技术，因短期便利可能导致长期维护成本与兼容困境。
• Web 标准的推进常与社区反馈、开发者需求紧密相关。

AI 摘要：本文批判性地回顾了 HTTP 多个版本发展之后，Web 表单（forms）在处理和数据编码方式上依旧混乱与落后。作者剖析了现有的两种表单数据编码方式（application/x-www-form-urlencoded 和 multipart/form-data）存在哪些规范不统一、实现分歧和技术缺陷，以及标准缺失导致开发体验极差；尽管 HTTP 协议多次进化，表单数据交互方式却数十年未有本质改进。文章最后指出，业界对更优的数据编码格式需求迫切，当前的局面已难以令人满意。

1. HTTP 1.1 及标准库开发的挑战
• HTTP 1.1 并非设计良好，RFCs 更像现状描述参考而非真正规范文档
• 实现 HTTP 协议过程中遇到种种格式和约定的古怪乃至异常细节，增加开发复杂度
• 常见如 chunked transfers 的十六进制长度、状态行中的强制空格等非直观规则

2. 表单数据编码现状与问题
• application/x-www-form-urlencoded
• 历史悠久但缺乏清晰权威的完整规范，依赖 URI 查询参数语法（RFC 3986）
• 编码方式不唯一：对于特殊字符、非 ASCII 字符及数组字段，各实现可能不同
• 对文件与大体量（非 ASCII）数据极为低效（尺寸膨胀、难处理），仅适合简单字段
• 标准文件来源分散且部分已废弃（如 RFC 1866）
• multipart/form-data
• 基于 MIME，规范为 RFC 7578
• 通过分隔符（boundary）串联各部分；分隔符任意但需保证不与正文冲突，增加复杂度
• 无内容长度（Content-Length）头，需流式查找分界符，解析困难导致代码容易出错
• 各字段内容 Content-Type 可以随意宣称，可信度低
• 同样缺乏对数组、对象等复杂数据结构的直接支持，序列化无统一方案
• 不适合前端与后端所有技术栈无缝协作，且导致报文冗余、解析低效

3. 表单标准规范缺失与业界影响
• RFC 文档对主流表单格式覆盖不全，甚至可实现 HTTP 服务器时完全不支持表单却依旧合规
• 主流浏览器始终只支持上面两种，阻碍更现代、结构化的数据格式如 JSON 的广泛采用
• 早年曾有 JSON、XForms 作为新方案提出，但均未流行或长远落地

4. 现实与展望
• 浏览器与后端互操作受限，文件与字段混合上传尤为无解
• 新协议如 tus，仅可用于纯文件上传场景；JSON 提案因多方面原因未标准化
• 表单机制停滞，严重滞后于网络协议和数据交换发展的需求