很久以前 Roger Johansson 就在他的 blog 上做了一个 用样式控制表单元素 的测试 , 告诉我们企图用样式控制表单元素是一件不可能的事情using CSS to style form controls to look exactly the same across browsers and platforms is impossible
甚至 css2.1 规范中也没有明确这方面的规定 , 而是打算将它 fix in future
CSS 2 . 1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.
所以如果想要让表单元素在各个浏览器下完全一致 , 最好的解决方法莫过于完全不理会操作系统的样式 , 用自定义的 ui 风格 , 就像 bing 或 Google 的 Jazz UI 那样 然而 , 这会导致界面和用户的系统格格不入 , 目前 google 主要还是针对浏览器做了些特殊处理 , 如 webkit 下用 gradient 使得按钮看上去好些 mac 下 webkit 的按钮不好控制 本文将就输入框高度的问题进行调研 , 寻找更好的解决方法 输入框高度 首先 , 这个调研的一个主要原因是 , 搜索结果页打算进入标准模式 , 这会导致盒模型的变化 , 造成输入框高度和原来不一样 , 所以为了和线上效果保持一致 , 我们需要找到一个最佳的解决方案 有同学可能会不解 , 有那么难么 ? 设置一个 height 不就解决了么 ? <input type= "text" style= "height:28px" /> 然而 , 经测试发现这里面的细节问题还是还挺多 , 由于资源有限 , 这里只测试了主要的浏览器和平台 , 包括目前主要用到的 5 个浏览器 · IE6(xp) · IE7(xp) · IE8(win7) · Firefox 3.5(xp) · Firefox 3.5(win7) · Firefox 3.5(mac 10.6.2) · Firefox 3.5(ubuntu 10.4) · Chrome 5(xp) · Chrome 5(win7) · Chrome 5(mac 10.6.2) · Chrome 5(ubuntu 10.4) 通过设定 height 的方式 我们的目标是和目前搜索框大小保持一致 , 既 28px 首先测试的是最简单的 height, 先看目前线上的方案 ( 简单起见就直接写到 style 中了 ) <input type= "text" style= "font: 16px arial; height: 1.78em; padding-top:2px" /> 从样式上推导 , 由于盒模型问题 , 在 IE 下的大小将是 1.78 * 16 = 28px, 而 Firefox 等浏览器应该是 1.78 * 16 + 2px + border-width * 2 = 30 + ? px 测试结果是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 21 + 2 + 1 + 2 + 2 = 28 IE7(xp) 21 + 2 + 1 + 2 + 2 = 28 IE8(win7) 21 + 2 + 1 + 2 + 2 = 28 Firefox 3.5(xp) 21 + 2 + 1 + 2 + 2 = 28 Firefox 3.5(win7) 23 + 2 + 1 + 1 + 1 = 28 Firefox 3.5(mac 10.6.2) 19 + 2 + 1 + 3 + 3 = 28 Firefox 3.5(ubuntu 10.04) 19 + 2 + 1 + 3 + 3 = 28 Chrome 5(xp) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(win7) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(mac 10.6.2) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(ubuntu 10.04) 21 + 2 + 1 + 2 + 2 = 28 效果相当理想 , 所有浏览器都是 28px, 看来即使是 Firefox 和 Chrom 在 quirks 模式下的 input 都没有遵循盒模型 , 所以线上的输入框高度在各个浏览器下很完美地保持一致 然而如果是在 standards 模式下 , 结果则是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 28 + 2 + 1 + 2 + 2 = 35 IE7(xp) 28 + 2 + 1 + 2 + 2 = 35 IE8(win7) 28 + 2 + 1 + 2 + 2 = 35 Firefox 3.5(xp) 28 + 2 + 1 + 2 + 2 = 35 Firefox 3.5(win7) 28 + 2 + 1 + 1 + 1 = 32 Firefox 3.5(mac 10.6.2) 28 + 2 + 1 + 3 + 3 = 37 Firefox 3.5(ubuntu 10.04) 28 + 2 + 1 + 3 + 3 = 37 Chrome 5(xp) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(win7) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(mac 10.6.2) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(ubuntu 10.04) 28 + 2 + 1 + 2 + 2 = 35 就仅仅加了一句 <!DOCTYPE html> , 却导致浏览器差距变得如此大 , 仔细观察发现 , 主要问题在 Firefox 上 它的 border 在 win7 下是 1 像素 , xp 下是 2 像素 , mac 下是 3 像素 , 令人很头疼 , 于是打算换一种方案试试 padding 的方式 由于 Firefox 的 border 问题 , 设定 height 是不可能保证高度一致的 , 除非判断再去判断操作系统类型 , 但那样做太麻烦了 , 而且说不定 mobile 版又不一样 那是否可以不通过设置 height 来控制 ? 在目前的大搜索首页也是 standards 模式 , 它是采用 padding 的方式来实现 28px 的高度的 <input type= "text" style= "font: 16px arial; padding:3px" /> 这种写法的测试结果是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 18 + 3 + 3 + 2 + 2 = 28 IE7(xp) 18 + 3 + 3 + 2 + 2 = 28 IE8(win7) 18 + 3 + 3 + 2 + 2 = 28 Firefox 3.5(xp) 19 + 3 + 3 + 2 + 2 = 29 Firefox 3.5(win7) 19 + 3 + 3 + 1 + 1 = 27 Firefox 3.5(mac 10.6.2) 20 + 3 + 3 + 3 + 3 = 32 Firefox 3.5(ubuntu 10.04) 19 + 3 + 3 + 3 + 3 = 31 Chrome 5(xp) 19 + 3 + 3 + 2 + 2 = 29 Chrome 5(win7) 19 + 3 + 3 + 2 + 2 = 29 Chrome 5(mac 10.6.2) 18 + 3 + 3 + 2 + 2 = 28 Chrome 5(ubuntu 10.04) 19 + 3 + 3 + 2 + 2 = 29 在不设定输入框高度的情况下 , 浏览器会自行指定一个 , 而且都有差距 , mac 上的 Firefox 更是高出了 4 像素 , 但总的来说 , 效果虽然不完美 , 但还是可以接受 , 大部分情况下都只差一个像素 然而这种方法带来了很多不确定性 , 内容区的高度是随着字体大小而变的 , 假设 font-size 是 14px, 浏览器的高度又保持一致了 浏览器 height IE6(xp) 16 IE7(xp) 16 IE8(win7) 16 Firefox 3.5(xp) 16 Firefox 3.5(win7) 16 Firefox 3.5(mac 10.6.2) 16 Firefox 3.5(ubuntu 10.04) 16 Chrome 5(xp) 16 Chrome 5(win7) 16 Chrome 5(mac 10.6.2) 16 Chrome 5(ubuntu 10.04) 16 是否还有更好的方案呢 ? box-sizing height 和 padding 都无法完美控制输入框高度 , 而 border 的大小又不能改 , 难道就真的没办法了么 ? 不禁怀念 quirks 模式下的方便 , 设定一个高度就完美了 , 要是能既进 standards 模式 , 又能用到旧盒模型就好了 , 很自然地就想到了一个从来没用过的 css 属性 box-sizing, 以前一直没想好这属性到底能用在哪里 , 终于这下派上用场了 , 使用它我们就可以解决 Firefox 下 3 种 border 的区别 , 让 Firefox 自己去算内容区的高度 然而由于 IE6/7 不支持这个属性 , 所以需要写 hack, 由于 IE 下的默认 border 值是 2, padding 是 1, 所以 height 需要减 6 像素 , 也就是 -moz-box-sizing : border-box ; -webkit-box-sizing : border-box ; box-sizing : border-box ; height : 28px ; * height : 22px ; 这样 , 就能保证绝大部分的浏览器下效果一致了 , box-sizing 属性的支持情况如下表所示 , 来自 mozilla 支持的访问非常广 , Browser Lowest Version Support of Internet Explorer 8.0 box-sizing Firefox (Gecko) 1.0 (1.0) -moz-box-sizing Opera 7.0 box-sizing Safari (WebKit) 3.0 (522) -webkit-box-sizing 不过 , 事情还没有结束 , 刚才假定了 IE 下默认 padding 是 1 像素 , 然而目前很多 css reset 都会将 input 的 padding 设为 0, 于是 , IE 下的差别将不是 6 像素 , 而是 4 像素 , 所以为了避免受到影响 , 建议将 padding 设为 0 padding-top : 0 ; padding-bottom : 0 ; height : 28px ; * height : 24px ; 浏览器在 quirks 下的实现方法 回过头来看 Firefox 和 Chrome 在 quirks 模式下使用了非标准的盒模型 , 看样子是有意去做的 , 它是如何实现的呢 ? 于是在 webkit 源码中寻找 , 一开始以为它是在源码中对 quirks 下的 input 做了特殊处理 , 但没看找到又什么特别的地方 , 而在看到计算 box 高度的时候 int RenderBox::calcContentBoxHeight( int height) const { if (style()->boxSizing() == BORDER_BOX) height -= (borderTop() + borderBottom() + paddingTop() + paddingBottom()); return max( 0 , height); } 忽然想到 , 会不会是通过浏览器默认样式来实现的呢 ? 将这种特殊的逻辑直接写在代码中确实太恶心了 , 既然支持 box-sizing 属性 , 直接将它写在 quirks 的默认样式不就完美解决了么 果然 , 在 Firefox 的 res/quirk.css 中发现了这句 /* * Quirk: Use border-box box sizing for text inputs, password inputs, and * textareas. (b=184478 on why we use content-box sizing in standards mode) */ /* Note that all other <input>s already use border-box sizing, so we're ok with this selector */ input :not ([ type = image ]), textarea { -moz-box-sizing: border -box; } 在 webkit 源码中的 WebCore/css/quirks.css 发现了这句 /* This will apply only to text fields, since all other inputs already use border box sizing */ input :not ([ type = image ]), textarea { -webkit-box-sizing: border -box; } 原来浏览器就是这么解决的 , 那么在标准模式下用它将是一种比较好的方案 one more thing 不过这种写法在 Firefox 3.5 以下的版本会有个问题 , 那就是输入框内容将无法垂直居中 , 以英文为例 , 3.5 中和顶部的差距是 5 像素 , 而 3.6 是 7 像素 , 目前还没想到解决方案 幸好在 Firefox 3.6 中解决了这个问题 , 而且 3.5 会默认升级到 3.6, 所以这个问题也就不需要考虑了 结论 从这个例子可以痛苦地体验 , 如果没有统一的规范 , 要兼容不同浏览器是如此的困难 , 而且这还仅仅是一个很不完全的测试 , 好在浏览器还是尽可能做到了最大兼容 , 比如 , 假设 windows 下默认主题和经典主题有区别 , 就意味着所有 windows 下的测试都要乘 2.
甚至 css2.1 规范中也没有明确这方面的规定 , 而是打算将它 fix in future
CSS 2 . 1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.
所以如果想要让表单元素在各个浏览器下完全一致 , 最好的解决方法莫过于完全不理会操作系统的样式 , 用自定义的 ui 风格 , 就像 bing 或 Google 的 Jazz UI 那样 然而 , 这会导致界面和用户的系统格格不入 , 目前 google 主要还是针对浏览器做了些特殊处理 , 如 webkit 下用 gradient 使得按钮看上去好些 mac 下 webkit 的按钮不好控制 本文将就输入框高度的问题进行调研 , 寻找更好的解决方法 输入框高度 首先 , 这个调研的一个主要原因是 , 搜索结果页打算进入标准模式 , 这会导致盒模型的变化 , 造成输入框高度和原来不一样 , 所以为了和线上效果保持一致 , 我们需要找到一个最佳的解决方案 有同学可能会不解 , 有那么难么 ? 设置一个 height 不就解决了么 ? <input type= "text" style= "height:28px" /> 然而 , 经测试发现这里面的细节问题还是还挺多 , 由于资源有限 , 这里只测试了主要的浏览器和平台 , 包括目前主要用到的 5 个浏览器 · IE6(xp) · IE7(xp) · IE8(win7) · Firefox 3.5(xp) · Firefox 3.5(win7) · Firefox 3.5(mac 10.6.2) · Firefox 3.5(ubuntu 10.4) · Chrome 5(xp) · Chrome 5(win7) · Chrome 5(mac 10.6.2) · Chrome 5(ubuntu 10.4) 通过设定 height 的方式 我们的目标是和目前搜索框大小保持一致 , 既 28px 首先测试的是最简单的 height, 先看目前线上的方案 ( 简单起见就直接写到 style 中了 ) <input type= "text" style= "font: 16px arial; height: 1.78em; padding-top:2px" /> 从样式上推导 , 由于盒模型问题 , 在 IE 下的大小将是 1.78 * 16 = 28px, 而 Firefox 等浏览器应该是 1.78 * 16 + 2px + border-width * 2 = 30 + ? px 测试结果是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 21 + 2 + 1 + 2 + 2 = 28 IE7(xp) 21 + 2 + 1 + 2 + 2 = 28 IE8(win7) 21 + 2 + 1 + 2 + 2 = 28 Firefox 3.5(xp) 21 + 2 + 1 + 2 + 2 = 28 Firefox 3.5(win7) 23 + 2 + 1 + 1 + 1 = 28 Firefox 3.5(mac 10.6.2) 19 + 2 + 1 + 3 + 3 = 28 Firefox 3.5(ubuntu 10.04) 19 + 2 + 1 + 3 + 3 = 28 Chrome 5(xp) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(win7) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(mac 10.6.2) 21 + 2 + 1 + 2 + 2 = 28 Chrome 5(ubuntu 10.04) 21 + 2 + 1 + 2 + 2 = 28 效果相当理想 , 所有浏览器都是 28px, 看来即使是 Firefox 和 Chrom 在 quirks 模式下的 input 都没有遵循盒模型 , 所以线上的输入框高度在各个浏览器下很完美地保持一致 然而如果是在 standards 模式下 , 结果则是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 28 + 2 + 1 + 2 + 2 = 35 IE7(xp) 28 + 2 + 1 + 2 + 2 = 35 IE8(win7) 28 + 2 + 1 + 2 + 2 = 35 Firefox 3.5(xp) 28 + 2 + 1 + 2 + 2 = 35 Firefox 3.5(win7) 28 + 2 + 1 + 1 + 1 = 32 Firefox 3.5(mac 10.6.2) 28 + 2 + 1 + 3 + 3 = 37 Firefox 3.5(ubuntu 10.04) 28 + 2 + 1 + 3 + 3 = 37 Chrome 5(xp) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(win7) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(mac 10.6.2) 28 + 2 + 1 + 2 + 2 = 35 Chrome 5(ubuntu 10.04) 28 + 2 + 1 + 2 + 2 = 35 就仅仅加了一句 <!DOCTYPE html> , 却导致浏览器差距变得如此大 , 仔细观察发现 , 主要问题在 Firefox 上 它的 border 在 win7 下是 1 像素 , xp 下是 2 像素 , mac 下是 3 像素 , 令人很头疼 , 于是打算换一种方案试试 padding 的方式 由于 Firefox 的 border 问题 , 设定 height 是不可能保证高度一致的 , 除非判断再去判断操作系统类型 , 但那样做太麻烦了 , 而且说不定 mobile 版又不一样 那是否可以不通过设置 height 来控制 ? 在目前的大搜索首页也是 standards 模式 , 它是采用 padding 的方式来实现 28px 的高度的 <input type= "text" style= "font: 16px arial; padding:3px" /> 这种写法的测试结果是 浏览器 height + padding-top + padding-bottom + border-top-width + border-bottom-width IE6(xp) 18 + 3 + 3 + 2 + 2 = 28 IE7(xp) 18 + 3 + 3 + 2 + 2 = 28 IE8(win7) 18 + 3 + 3 + 2 + 2 = 28 Firefox 3.5(xp) 19 + 3 + 3 + 2 + 2 = 29 Firefox 3.5(win7) 19 + 3 + 3 + 1 + 1 = 27 Firefox 3.5(mac 10.6.2) 20 + 3 + 3 + 3 + 3 = 32 Firefox 3.5(ubuntu 10.04) 19 + 3 + 3 + 3 + 3 = 31 Chrome 5(xp) 19 + 3 + 3 + 2 + 2 = 29 Chrome 5(win7) 19 + 3 + 3 + 2 + 2 = 29 Chrome 5(mac 10.6.2) 18 + 3 + 3 + 2 + 2 = 28 Chrome 5(ubuntu 10.04) 19 + 3 + 3 + 2 + 2 = 29 在不设定输入框高度的情况下 , 浏览器会自行指定一个 , 而且都有差距 , mac 上的 Firefox 更是高出了 4 像素 , 但总的来说 , 效果虽然不完美 , 但还是可以接受 , 大部分情况下都只差一个像素 然而这种方法带来了很多不确定性 , 内容区的高度是随着字体大小而变的 , 假设 font-size 是 14px, 浏览器的高度又保持一致了 浏览器 height IE6(xp) 16 IE7(xp) 16 IE8(win7) 16 Firefox 3.5(xp) 16 Firefox 3.5(win7) 16 Firefox 3.5(mac 10.6.2) 16 Firefox 3.5(ubuntu 10.04) 16 Chrome 5(xp) 16 Chrome 5(win7) 16 Chrome 5(mac 10.6.2) 16 Chrome 5(ubuntu 10.04) 16 是否还有更好的方案呢 ? box-sizing height 和 padding 都无法完美控制输入框高度 , 而 border 的大小又不能改 , 难道就真的没办法了么 ? 不禁怀念 quirks 模式下的方便 , 设定一个高度就完美了 , 要是能既进 standards 模式 , 又能用到旧盒模型就好了 , 很自然地就想到了一个从来没用过的 css 属性 box-sizing, 以前一直没想好这属性到底能用在哪里 , 终于这下派上用场了 , 使用它我们就可以解决 Firefox 下 3 种 border 的区别 , 让 Firefox 自己去算内容区的高度 然而由于 IE6/7 不支持这个属性 , 所以需要写 hack, 由于 IE 下的默认 border 值是 2, padding 是 1, 所以 height 需要减 6 像素 , 也就是 -moz-box-sizing : border-box ; -webkit-box-sizing : border-box ; box-sizing : border-box ; height : 28px ; * height : 22px ; 这样 , 就能保证绝大部分的浏览器下效果一致了 , box-sizing 属性的支持情况如下表所示 , 来自 mozilla 支持的访问非常广 , Browser Lowest Version Support of Internet Explorer 8.0 box-sizing Firefox (Gecko) 1.0 (1.0) -moz-box-sizing Opera 7.0 box-sizing Safari (WebKit) 3.0 (522) -webkit-box-sizing 不过 , 事情还没有结束 , 刚才假定了 IE 下默认 padding 是 1 像素 , 然而目前很多 css reset 都会将 input 的 padding 设为 0, 于是 , IE 下的差别将不是 6 像素 , 而是 4 像素 , 所以为了避免受到影响 , 建议将 padding 设为 0 padding-top : 0 ; padding-bottom : 0 ; height : 28px ; * height : 24px ; 浏览器在 quirks 下的实现方法 回过头来看 Firefox 和 Chrome 在 quirks 模式下使用了非标准的盒模型 , 看样子是有意去做的 , 它是如何实现的呢 ? 于是在 webkit 源码中寻找 , 一开始以为它是在源码中对 quirks 下的 input 做了特殊处理 , 但没看找到又什么特别的地方 , 而在看到计算 box 高度的时候 int RenderBox::calcContentBoxHeight( int height) const { if (style()->boxSizing() == BORDER_BOX) height -= (borderTop() + borderBottom() + paddingTop() + paddingBottom()); return max( 0 , height); } 忽然想到 , 会不会是通过浏览器默认样式来实现的呢 ? 将这种特殊的逻辑直接写在代码中确实太恶心了 , 既然支持 box-sizing 属性 , 直接将它写在 quirks 的默认样式不就完美解决了么 果然 , 在 Firefox 的 res/quirk.css 中发现了这句 /* * Quirk: Use border-box box sizing for text inputs, password inputs, and * textareas. (b=184478 on why we use content-box sizing in standards mode) */ /* Note that all other <input>s already use border-box sizing, so we're ok with this selector */ input :not ([ type = image ]), textarea { -moz-box-sizing: border -box; } 在 webkit 源码中的 WebCore/css/quirks.css 发现了这句 /* This will apply only to text fields, since all other inputs already use border box sizing */ input :not ([ type = image ]), textarea { -webkit-box-sizing: border -box; } 原来浏览器就是这么解决的 , 那么在标准模式下用它将是一种比较好的方案 one more thing 不过这种写法在 Firefox 3.5 以下的版本会有个问题 , 那就是输入框内容将无法垂直居中 , 以英文为例 , 3.5 中和顶部的差距是 5 像素 , 而 3.6 是 7 像素 , 目前还没想到解决方案 幸好在 Firefox 3.6 中解决了这个问题 , 而且 3.5 会默认升级到 3.6, 所以这个问题也就不需要考虑了 结论 从这个例子可以痛苦地体验 , 如果没有统一的规范 , 要兼容不同浏览器是如此的困难 , 而且这还仅仅是一个很不完全的测试 , 好在浏览器还是尽可能做到了最大兼容 , 比如 , 假设 windows 下默认主题和经典主题有区别 , 就意味着所有 windows 下的测试都要乘 2.
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
暂无评论...
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
2024年11月23日
2024年11月23日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]