<meter>必须显式声明min、max、value三个纯数字属性，否则因无范围基准导致不渲染或语义错误；其low/high/optimum仅作语义提示，颜色支持不一致；与<progress>核心区别在于数据是否具有稳定上下界及可变性。

标签不是“画刻度条”的工具，它只负责告诉浏览器：“这个数值落在哪个预设范围内”，视觉表现是次要的、不可靠的。用错场景或漏关键属性，轻则不显示，重则语义混乱、读屏器误读。

为什么 meter 什么都没渲染出来

常见现象是写了 <meter value="75"></meter> 却看不到条形，甚至 getBoundingClientRect().height 返回 0。 根本原因不是 CSS 没写，而是缺了 min 和 max： - min 默认为 0，但仅限显式声明后才参与计算； - max **没有默认值**，不写就等于没范围，浏览器无法确定比例基准； - Chrome 可能 fallback 成 min="0" max="1"，导致 value="75" 被当成 7500% 渲染溢出； - Firefox 直接不渲染条形，只留空白节点。

务必显式写出三个数字属性：min、max、value，且都必须是纯数字（不能带单位、百分号或空格）：

• value="75" ✅；value="75%" ❌；value="0.75" ❌（除非 max="1"）
• min="0" ✅；min="-20" ✅（支持负值）；min="zero" ❌
• max="100" ✅；max="1e2" ❌（部分浏览器解析失败）

meter 的 low/high/optimum 为什么没颜色

这些属性不是“开关”，而是语义提示——浏览器只在满足全部条件时才可能触发颜色变化： - low 和 high 必须严格落在 [min, max] 内，且 low < high； - optimum 可以等于 min 或 max（比如噪音越低越好，optimum="min"）； - Chrome 会据此划分三段色区（红/黄/绿），但 Firefox 当前完全不响应这些属性； - Safari 实现逻辑不同，同一组值在 Chrome 显黄，在 Safari 可能偏橙。

别指望靠它们控制业务状态色。真要区分“偏低/正常/偏高”，得自己加 class 或用 ARIA：

html-to-pptx

将多页 HTML 演示文稿转换为美化的 PPTX 文件，便于分享和分发。

下载

• 用 meter[value<30] 做简单 CSS 选择（注意兼容性，IE/Safari 不支持）
• JS 更新时同步设置 dataset.status = "low"，再配 CSS 规则
• 避免动态改 min/max：DOM 更新后部分浏览器不重绘样式，建议整个替换元素

meter 和 progress 到底该选谁

区别不在长得像不像，而在数据性质和语义意图： - <progress value="65" max="100"></progress> 表示“任务已完成 65%”，value 只增不减，无 min； - <meter value="65" min="0" max="100"></meter> 表示“当前 CPU 占用率 65%”，value 可升可降，必须有 min 和 max。

典型误用：

• 把文件上传进度写成 meter ❌（该用 progress）
• 把倒计时剩余秒数塞进 meter ❌（非标量测量，无固定上下界）
• 把用户等级（Lv.12）硬套 meter ❌（无明确 min/max，语义断裂）

真正难的不是写对标签，而是判断值有没有公认边界

的核心约束不是技术实现，而是建模前提：你得先确认这个数值存在公认的、稳定的上下界，并且业务上需要传达“偏低/偏高/理想”这类隐含判断。 比如磁盘使用率（0–100%）、投票支持率（0–100%）、体温（-20–50℃）可以； 但温度本身（无上下界）、加载耗时（毫秒值浮动大）、用户积分（持续增长）就不适合。 一旦想不清这点，加再多 CSS、伪元素、ARIA，也救不回语义错位——而屏幕阅读器和搜索引擎正是靠这个语义做判断的。