CSS美化Range滑块，Webkit与Moz-range详解

本文深入解析了CSS样式化HTML range滑块在不同浏览器内核（WebKit、Gecko、Blink/Edge）中的核心难点与实战方案：由于range控件被Shadow DOM封装，常规CSS对height、background等属性无效，必须通过appearance: none禁用默认外观，并精准使用各内核专属伪元素（如::-webkit-slider-thumb、::-moz-range-thumb）进行定制；同时揭示了盒模型差异（border-box vs content-box）、垂直居中机制不一致、跨浏览器“已填充轨道”缺失等隐藏陷阱，并指出纯CSS无法实现真正统一的进度效果——必须结合JavaScript动态计算百分比并更新覆盖层，辅以input事件监听、touch-action优化及真机验证，最终强调：样式统一不是堆砌前缀，而是理解限制、合理分工（CSS负责结构与基础样式，JS补足逻辑与兼容），在真实设备上做防御性开发。

为什么直接写 input[type="range"] 的 height 或 background 没用？

因为浏览器对 input[type="range"] 的轨道（track）和滑块（thumb）默认使用 Shadow DOM 封装，常规 CSS 选择器无法穿透。你写的 height 只作用于 input 元素自身这个“外壳”，而真正显示的轨道和滑块是内部匿名节点，必须靠伪元素精准命中。

不加 appearance: none（及各前缀）就尝试改 ::-webkit-slider-thumb，结果是：完全无效。WebKit 内核下，伪元素只在 -webkit-appearance: none 启用后才被识别；Firefox 同理，-moz-appearance: none 是前提。

• -webkit-appearance: none 和 -moz-appearance: none 必须同时写，不能只写一个
• 标准属性 appearance: none 要放在最后，覆盖前缀规则
• Chrome/Safari 用 ::-webkit-slider-runnable-track 和 ::-webkit-slider-thumb
• Firefox 用 ::-moz-range-track 和 ::-moz-range-thumb，注意它没有 progress 伪类可直接控制已填充部分

::-webkit-slider-thumb 和 ::-moz-range-thumb 的尺寸行为为什么总对不齐？

根本差异在盒模型：Chrome/Safari 下 thumb 默认是 border-box，Firefox 下是 content-box。你设 width: 20px; height: 20px;，在 Firefox 中若加了 border 或 padding，实际占用空间会超出 20px，导致上下偏移或遮挡轨道。

更隐蔽的问题是垂直居中：WebKit 下 thumb 垂直居中依赖 margin-top: -Xpx 手动微调（因为轨道高度与 thumb 高度不同），而 Firefox 下 thumb 默认就贴在轨道中线，加 margin-top 反而错位。

• 统一做法：给 thumb 设 box-sizing: border-box，并在所有浏览器中显式声明
• 垂直定位统一用 transform: translateY(-50%) + top: 50%（需父容器 position: relative）比 margin-top 更可靠
• 不要依赖 height 控制 thumb 大小——用 width + height + border-radius 明确定义形状

怎么让“已滑动区域”在 Chrome、Firefox、Edge 里都显示一致？

原生 input[type="range"] 没有跨浏览器通用的“已填充轨道”伪类。::-webkit-slider-runnable-track 是整条轨道，::-moz-range-track 也是整条，Edge 的 ::-ms-fill-lower 虽然能控制已填充部分，但其他两个内核不支持。

所以真要实现带进度色的滑块，必须放弃纯 CSS 方案：保留原生 input，用 JS 读取 value、计算百分比，再动态更新一个覆盖层（比如