写完没反应最常见原因是value或max缺失、类型错误（如字符串）、超出范围或带单位；必须同时设置合法数字值，且javascript更新时须直接赋值el.value而非setattribute。

为什么<progress></progress>写完却没反应

最常见原因是 value 或 max 没传对——<progress value="70"></progress> 里的 "70" 是字符串，部分浏览器直接忽略；max="100px" 这种带单位的值会失效，导致整个进度条退化为“不确定”状态（空白或动画条）。<progress></progress> 必须同时有合法的 value 和 max，且都得是有效数字。

• 用 JS 设置时，务必写 el.value = Number(val)，别直接赋字符串
• HTML 中写 value="70" max="100" 是安全的，但别加空格、引号外符号或单位
• 省略 value 就是不确定态，不是“初始为 0”，这点常被误认为 bug

伪元素样式在 Firefox/Chrome/Safari 里为啥只生效一半

因为各引擎对内部结构的暴露方式完全不同：::-webkit-progress-value 只在 Chrome/Safari 生效，::-moz-progress-bar 是 Firefox 唯一靠谱的选择，而 Safari 对 appearance: none 依赖极强——不加这句，你写的任何背景色、圆角、渐变都会被无视。

Doc To HTML

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

下载

• 必须先写 progress { -webkit-appearance: none; appearance: none; }
• Chrome/Safari 要同时覆盖 ::-webkit-progress-bar（轨道）和 ::-webkit-progress-value（填充），漏一个就显示异常
• Firefox 不支持 border-radius 或 background-image 在 ::-moz-progress-bar 上，纯色最稳
• 所有浏览器下 <progress></progress> 默认是 display: inline，不显式设 display: block 或 flex，宽度控制必然错乱

用 Web Component 封装时，哪些逻辑必须收口

不是为了炫技，而是把易崩点集中管控：数值越界、高频更新卡顿、无障碍属性缺失。原生 <progress></progress> 不做校验也不节流，JS 直接狂塞 value 会触发连续 layout，尤其在旧安卓 WebView 里直接卡死。

• 属性读取统一用 Number(this.getAttribute('value') || 0)，避免 NaN
• 更新 DOM 前做范围 clamp：Math.min(Math.max(value, min), max)
• 用 requestAnimationFrame 包一层，确保每帧最多更新一次，别信 setTimeout 的“匀速”假象
• 自动注入 role="progressbar"、aria-valuenow、aria-valuemax，否则屏幕阅读器根本读不出进度

手写 <div> 进度条时 width 动画为啥跳变或溢出 <p>根本问题不在 CSS 写错，而在布局上下文没锁死。用 <code>width 动画时，父容器若没设 overflow: hidden，进度条撑开后会破坏整体流式布局；更隐蔽的是，如果父容器用了 padding 或 flex，width: 65% 的基准就不再是视觉宽度，而是内容区宽度。

• 容器必须加 overflow: hidden，这是底线
• 优先用 flex-basis 替代 width：.progress-fill { flex: 0 0 65%; } 更稳定
• 若坚持用 width，确保父容器 box-sizing: border-box 且无 padding 干扰
• 动画别混用 width 和 transform: scaleX()——后者虽 GPU 加速，但在某些低端 Android 上有撕裂，且会破坏无障碍尺寸计算

Web Component 方案看似重，但真正省掉的是每次都要重查伪元素兼容表、反复调试 Firefox 圆角、手动补 ARIA 属性这些重复劳动。复杂点在于节流逻辑和边界校验，而不是结构本身。